- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-bugs] Indonesian resource language for ReactOS

by Murphy, Ged (Bolton)

Zaenal Mutaqin wrote: > Indonesian resource language for ReactOS. Wow, nice work! > translated from us-EN.rc/en.rc to id-ID.rc/id.rc. You should try to keep the file naming convention the same throughout. The reason we have both en.rc and en-US.rc is historical, but incorrect now. We should be using en-US.rc for US files as US English uses different spellings than other countries. This gives us scope for other variations like en-GB and en-CA. Unfortunately, I don't know much about the Indonesian language, but it's best to stick with id-ID in case there are other variations on the Indonesian language (and to follow suit with the format the rest of our resource files need to move to) Ged. Registered Office: PO Box 1 Salford Road, Over Hulton, Bolton, BL5 1DD. Registered in England: No. 2375355 The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)eu.exide.com <mailto:postmaster@eu.exide.com> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com <www.exide.com>

18 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [weiden] 25828: - Move around definitions to make the code a bit more modular - Use an about menu instead of an button

by Murphy, Ged (Bolton)

weiden(a)svn.reactos.org wrote: > > Modified: trunk/reactos/base/applications/charmap/charmap.c > + case WM_SYSCOMMAND: > + { > + switch(wParam) > + { > + case ID_ABOUT: > DialogBox(hInstance, > MAKEINTRESOURCE(IDD_ABOUTBOX), > hDlg, > AboutDialogProc); Modified: trunk/reactos/base/applications/charmap/map.c + if (RegisterClass(&wc)) + { + wc.lpfnWndProc = LrgCellWndProc; + wc.cbWndExtra = 0; + wc.lpszClassName = szLrgCellWndClass; > Modified: trunk/reactos/base/applications/charmap/precomp.h > -INT_PTR CALLBACK AboutDialogProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam); > -LRESULT CALLBACK LrgCellWndProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam); Maybe I'm reading the diff wrong, but does this not break the build? (not been able to svn up this weekend) I'm guessing the 'case ID_ABOUT' should now call ShowAboutDlg, but what about the assignment of LrgCellWndProc? Ged. Registered Office: PO Box 1 Salford Road, Over Hulton, Bolton, BL5 1DD. Registered in England: No. 2375355 The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)eu.exide.com <mailto:postmaster@eu.exide.com> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com <www.exide.com>

18 years, 6 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [mbosma] 25812: Lester Kortenhoeven (lester(at)ko rtenhoeven(dot)de)

by Murphy, Ged (Bolton)

mbosma(a)svn.reactos.org wrote: > +WCHAR ApplicationText[700]; ... > - StrCatW(DescriptionText, Strings[IDS_VERSION]); > - StrCatW(DescriptionText, SelectedApplication->Version); > - StrCatW(DescriptionText, L"\n"); > + StrCatW(ApplicationText, Strings[IDS_VERSION]); > + StrCatW(ApplicationText, SelectedApplication->Version); > + StrCatW(ApplicationText, L"\n"); This doesn't fix anything, there is still a potential overflow issue. Quickly skimming through the app, there are numerous other issues too. Ged. Registered Office: PO Box 1 Salford Road, Over Hulton, Bolton, BL5 1DD. Registered in England: No. 2375355 The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)eu.exide.com <mailto:postmaster@eu.exide.com> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com <www.exide.com>

18 years, 7 months

1
0
0 0

Changelog for 0.3.1

by Zachary Gorden

Hi all, I'm one of the release engineers (with Colin_Finck) and we're starting to put together the changelog. We're asking any devs that want to to add what they feel might be a noteworthy accomplishment/change made to 0.3.1 in the Highlights of this Release section on the changelog. Here's the link: http://www.reactos.org/wiki/index.php/ChangeLog-0.3.1 Also, as we branch out and begin cataloging the changes in more detail, you're all welcome to add in or clarify things. However, we do reserve the right to make edits to your contributions either for formatting, clarity, or general readability issues. Thank you for your attention, we now return to your regular programming. Z98

18 years, 7 months

3
4
0 0

Re: [ros-dev] [ros-diffs] [greatlrd] 25794: patch from Physicus, implement TOOLTIPS_NotifyFormat, it now retrurn the type of the string if it unicode or ansi. before it did not return any type at all. it did a heap crash from downloader mangers when

by Steven Edwards

On 2/14/07, Saveliy Tretiakov <saveliyt(a)gmail.com> wrote: > Ged Murphy пишет: > > IIRC, Julliard stated that if test cases were submitted along with the > > patch, he would accept code. > > No, not always. My rpc code with testcases was not accepted, because it > was from reactos. I think Alexandre has loosened his restrictions a bit. If I recall correctly you had a widl patch, he might be interested in some of them now as he is having to do a bit of work on that code. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

18 years, 7 months

5
7
0 0

WIDL

by Jacques Mony

Hi, I've read somewhere on a Wine list archive that WIDL was supposed to be imported into RosBE, back in... 2005? Can someone tell me what happened and if there is a reason why it's not present at the moment. Thanks, -- Jacques Mony

18 years, 7 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [greatlrd] 25794: patch from Physicus, implement TOOLTIPS_NotifyFormat, it now retrurn the type of the string if it unicode or ansi. before it did not return any type at all. it did a heap crash from downloader mangers when it try figout what type of sting the toolstips use. it is tested in 0.3.1 and not whole implemnent is tested yet. it should be right for all case.

by Ged Murphy

greatlrd(a)svn.reactos.org wrote: > URL: http://svn.reactos.org/svn/reactos?rev=25794&view=rev > Log: > patch from Physicus, Did anyone actually bother to read Thomas' last email about keeping our comctl32 in line with Wines?

18 years, 7 months

5
5
0 0

Re: [ros-dev] about commit 25758 is wrong

by magnus＠itkonsult-olsen.com

Thomas : ZwQueryDefaultLocale is located in ntoskrnl and it is call on NtQueryDefaultLocale check by my self let us take a look at NtUserGetKeyboardLayoutName 1. it return a keyboard name the keyboard name is the current active Keyboard LCID to optain it we can use ZwQueryDefaultLocale (check reactos code in ntoskrnl how it works) so let us use ZwQueryDefaultLocale to optain the current activate keyboard with follow call ZwQueryDefaultLocale(FALSE, &LocaleId); what happen then let us take a look at ZwQueryDefaultLocale if (UserProfile) *DefaultLocaleId = PsDefaultThreadLocaleId; else *DefaultLocaleId = PsDefaultSystemLocaleId; return DefaultLocaleId; etiher we get current threed local or local system keyboard LCID with this call depns on it is current user or not. depns what we whant. so it is a correct impement to use it. now we can check other thing as well please check how it works in ntoskrnl in ex/local.c then we can talk how it works.

18 years, 7 months

4
6
0 0

Re: [ros-dev] [ros-diffs] [tretiakov] 25758: Add multiple keyboard layout support. Implemented NtUserLoadKeyboardLayoutEx, NtUserActivateKeyboardLayout, NtUserGetKeyboardLayoutList, NtUserGetKeyboardLayoutName.

by Aleksey Bragin

On Feb 9, 2007, at 11:48 PM, tretiakov(a)svn.reactos.org wrote: > Author: tretiakov > Date: Fri Feb 9 23:48:37 2007 > New Revision: 25758 > > URL: http://svn.reactos.org/svn/reactos?rev=25758&view=rev > Log: > Add multiple keyboard layout support. Implemented > NtUserLoadKeyboardLayoutEx, NtUserActivateKeyboardLayout, > NtUserGetKeyboardLayoutList, NtUserGetKeyboardLayoutName. > > > -NtUserLoadKeyboardLayoutEx 6 > +NtUserLoadKeyboardLayoutEx 2 Magnus says that this change is incorrect (and respective change of the prototype is incorrect too, because, he says, we had a Win2003- compatible prototype). Can you comment on this please? WBR, Aleksey Bragin.

18 years, 7 months

4
6
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 25768: Property sheet: - Set focus to defpushbutton or to first WC_EDIT child window if present, like it works on windows. - update wine diff This fixes the regression in 2nd stage setup when no keyboard focus was present.

by Thomas Weidenmueller

tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Sun Feb 11 01:02:45 2007 > New Revision: 25768 > > URL: http://svn.reactos.org/svn/reactos?rev=25768&view=rev > Log: > Property sheet: > - Set focus to defpushbutton or to first WC_EDIT child window if present, like it works on windows. > - update wine diff > This fixes the regression in 2nd stage setup when no keyboard focus was present. > > Modified: > trunk/reactos/dll/win32/comctl32/comctl32_ros.diff > trunk/reactos/dll/win32/comctl32/propsheet.c Why is it so difficult to keep differences with wine code as minimal as possible? Who's supposed to merge all these things in case conflicts appear in the future? Why not submit the patches to wine? - Thomas

18 years, 7 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [greatlrd] 25763: reverting 25758 : for follow reason 1. it cause regress of loading keyboard layout from the regsiter when reatcos booting. 2. it does not follow windows implement 3. it does not using ntoskrnl for it is ntoskrnl that handling the keyboard not the win32k. 4. it does not using right protoype for some syscall 5. some syscall does not working like windows. it mess it up instead. 6. Do not implement own design on public api and syscall

by Aleksey Bragin

REVERT WARS ARE NOT ALLOWED in the repository. Fix the code together with its author or wait my approval for reverting. Your SVN account has been temporarily suspended now for periodical violation of the established revert-rules (major part of which were proposed actually by Magnus). Aleksey Bragin. On Feb 10, 2007, at 5:52 PM, greatlrd(a)svn.reactos.org wrote: > Author: greatlrd > Date: Sat Feb 10 17:52:46 2007 > New Revision: 25763 > > URL: http://svn.reactos.org/svn/reactos?rev=25763&view=rev > Log: > reverting 25758 : for follow reason > 1. it cause regress of loading keyboard layout from the regsiter > when reatcos booting. > 2. it does not follow windows implement > 3. it does not using ntoskrnl for it is ntoskrnl that handling the > keyboard not the win32k. > 4. it does not using right protoype for some syscall > 5. some syscall does not working like windows. it mess it up instead. > 6. Do not implement own design on public api and syscall

18 years, 7 months

2
1
0 0

Re: [ros-dev] about commit 25758 is wrong

by magnus＠itkonsult-olsen.com

Hi some example ZwQueryDefaultLocale is located in ntoskrnl it call on NtQueryDefaultLocale it is to get current keyboard name file ntoskrnl/ex/locale.c in that file it exists all api to get and set the a keyboard. a keyboard are being loading either from user mode or kmode. in kmode it is loading by ntoskrnl or win32k depns on the case which keyboard that is active are set by ntoskrnl not win32k to get defult or current keyboard is the ntoskrnl jobb not win32k so on. so do not change my implement of NtUserGetKeyboardLayoutName it is correct test in Windows and in ReactOS. we need using same api as windows and same prototype. even undocument thing. but what I provide is a start to use it. but not complete what I did give about NtUser* so change it to 7 param and use the protoype I gave u. use the x2 and x6 I put in, so we can change it to same as windows when we got more informations how it works. I do not have time to dig after any more doc about it. one more thing use the Zw* api when u call on ntoskrnl from win32k. and the keyboard work are split betwin user32.dll, win32k.sys, ntoskrnl. they doing diffeting thing, but theý are linked toghther like user32.dll -> win32k.sys -> ntoskrnl.exe | | --------------- | \ / Keyboard drv both talk with the keyboard drv and can loading it depns on the case all setting are done by ntoskrnl and win32k is relay those msg when it is need it to ntoskrnl

18 years, 7 months

3
2
0 0

about commit 25758 is wrong

by magnus＠itkonsult-olsen.com

Hi The commit 25758 are complete wrong, more I looking at more foualt I found we are not longer windows comptable with the keyboard with this commit. it mean win32k syscall does not longer working as it should do in windows. and it also fuckup loading process of the keyboard. example ntoskrnl is setting which defualt keyboard that should be in use and so on. in current change it does ignore ntoskrnl setting. and when ntoskrnl trying set it will mess up the keyboard loading. the protype for NtUserLoadKeyboardLayoutEx look like this what I can figout HKL STDCALL NtUserLoadKeyboardLayoutEx( IN HANDLE Handle, x2, x3, x4, IN HWINSTA pProcessWindowStation, x6, IN INT Flags); But x2 and x6 are not in use. I have not figout x3,x4 yet

18 years, 7 months

3
3
0 0

Re: [ros-dev] [ros-diffs] [tretiakov] 25758: Add multiple keyboard layout support. Implemented NtUserLoadKeyboardLayoutEx, NtUserActivateKeyboardLayout, NtUserGetKeyboardLayoutList, NtUserGetKeyboardLayoutName.

by Thomas Weidenmueller

> + if(!*phModule) DPRINT1( "Failed to load %wZ\n", &FullLayoutPath ); > + else DPRINT( "Loaded Keyboard Layout: %wZ\n", &FullLayoutPath ); Code like this might expand incorrectly, which is why it's highly recommended to use {...} - Thomas

18 years, 7 months

2
1
0 0

COM development with MingW for ReactOS

by Jacques Mony

Hi, I recently decided to give a hand on the project. So I joined the IRC channel and asked for ideas of applications I could make for ReactOS, in order to make it more "complete". Alex Ionescu suggested, among other ideas, an implementation of MMC. So, I decided to jump on the idea. However, I have minimal knowledge of COM programming in C and minimal knowledge of C++. Although, I have good knowledge of assembly (x86), C in general, as well as VB6. So, I decided to look at how MMC works. I quickly realized that I would need to implement some interfaces (like IUnknown, for a simple one). MingW doesn't seem to handle COM development very well. However, I read in some places that it could support COM development when doing pure C programming. I like the idea since I do know C much better than C++... so I read the following tutorial: http://www.codeproject.com/com/com_in_c1.asp That was interesting until I tried to do that with MingW. No succes. So, I'd like to know if someone managed to do that yet (ie a COM "component", which implements interfaces). Thanks, -- Jacques Mony

18 years, 7 months

1
0
0 0

Tree Cleanup

by Alex Ionescu

Hi all, After talking to some developers about the recent state of the ReactOS tree, compiler times and disk space, I've analyzed our tree and found the following preliminary round of changes that should be made to stay in line with our policy that ReactOS provides what Windows does, at the core level. Any extra functionality or applications not provided by Windows have always been supposed to go into rosapps, as well as test applications. For testing/regression testing, I actually recommend the creation of a ros-tests repository, which will contain the tests in rosapps plus the ones I've mentionned below. This isn't just about disk space or compiling speed, but also to keep our tree clean and conformant. Here's the list: \base\applications\devmgmt should go into a new folder called "mscutils" along with similar MSC clones. \base\applications\getfirefox should be removed. \base\applications\devmgr should be removed. \base\applications\downloader should be moved to rosapps. \base\applications\gettype should be moved to rosapps. \base\applications\ibrowser should be removed. \base\applications\imagesoft shoudl be moved to rosapps. \base\applications\network\roshttpd should be moved to rosapps. \base\applications\reporterror should be removed. \base\applications\screenshot should be moved to rosapps. \base\applications\servman should go into a new folder called "mscutils" along with similar MSC clones. \base\applications\shutdown should go to \cmdutils. \base\applications\sm should be removed. \base\applications\testsets should go to rosapps. \base\applications\utils should go to rosapps. \base\applications\winefiel should to rosapps. \base\services\dhcpd should go to rosapps. \drivers\base\debugout should be removed. \drivers\base\green should go to rosapps. \drivers\base\ramdrv should go to rosapps. \drivers\base\test should go to rosapps. \drivers\filesystems\ext2 should go to rosapps. \drivers\filesystems\minix should go to rosapps. \drivers\filesystems\template should go to rosapps. \drivers\multimedia\avtest should go to rosapps. \drivers\network\tditest should go to rosapps. \regtests should go to rosapps. As well, there has been talk that \tools should become part of RosBE as -O3, heavily optimized binaries on Windows. They should stay in the default reactos trunk download, but building them shouldn't be done on Windows unless the binaries can't be found or the option has been forced. This will make bug reporting and testing safer since we'll know the tools are the same ones the developers are using (at least on Windows, where we can manage this better). I am very much pushing for this change to happen, as it will make our life easier for a variety of reasons: - MSVC or GCC 4.2 -O3 tools decrease build times. A highly optimized rbuild binary does dependency checking almost twice as fast as a regular -Os binary. - Decrease build times since the tools don't have to be rebuilt/cleaned each time. - Decrease storage space for developers that want to locally delete the entire tree. - Reduce the number of potential problems that outside testers might have to due to improper building of their tools. The tools Microsoft releases in the DDK are the same ones they use internally, so any bugs appear on both versions, and it makes diagnosing a lot easier. Unfortunately binaries can't be provided for Linux, but since /tools would stay in the reactos directory, Linux builders would be completely unaffected (except they wouldn't have the added advantages). As far as I know, Aleksey, Christoph and Johannes are willing to back this up and do the necessary changes for the /tools; I'll handle fixing the .xml files and doing the tree moves. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 7 months

5
5
0 0

regression on 2nd stage setup

by Timo Kreuzer

GreatLord told me about a regression that might be caused by one of my patches. In fact it was two patches working together: 1.) 25410, win32k: Make NtUserSetFocus accept NULL window. This patch is correct. Win XP behaves the same way. 2.) 25412, user32.dll: remove focus from window, when it gets disabled I have tested this and compared results to XP, I am sure it works the same on XP. On XP when you disable a control you will hear a sound when trying to use tab / arrow keys after that. Focus is not moved to another control. The regression coming from those patches is that on 2nd stage setup keyboard focus is removed from the Back/Next buttons. I found one problem in comctl32: When using PropSheet_SetWizButtons() the appropriate button will be set as defpushbutton, but not recieve focus. This can be corrected with a small patch, wich would solve most of the regression. But it introduces another bug: On 2nd stage AckPage (2nd page) the focus should be set to username edit control. But it would be set to Next button, even if SetFocus(<usernameeditcontrol>) was called after calling PropSheet_SetWizButtons() So I compiled syssetup as an exe to work on XP and tried to find out how it works on XP. On XP syssetup behaves the way that I think it should. More testing gave me the following result: The propsheet sets the focus automatically to the first editcontrol (maybe other controls, too, didn't test) that was defined in the resource. It is independed from the control ID and position of the control. Only thing that is important is the position at wich the control was defined in the rc file. So my question: How dows windows know the position of the control inside the resource? Do we have something like that implemented in ROS? Any help appreaceated. Another minor thing: XP displays no focus rect (dotted rect on buttons that have focus) until a tab / arrow key was used. Then it stays. It's only a visual enhancement, but it woud be nice to also have this. Does anyone know how win does this? BTW: Should I patch comctl32 to fix that regression, or send a patch to wine? I also have another patch for the updown control that behaves incorrect with wine code. And another thing: I first tried to execute syssetup.dll on XP with rundll32 (rundll32.exe syssetup.dll,InstallWizard), but it said it could not find InstallWizard. Can someone tell me why it does not work? Greetings, Timo

18 years, 7 months

1
0
0 0

My ReactOS PR Efforts

by Alex Ionescu

Hi all, I just wanted to keep you update of the various ReactOS presentations, lectures and exhibitions that I will be part of to help push ReactOS out to more people. Three weeks ago I was at CUSEC, where I demoed ReactOS in front of about 60 people, all software engineering students, mostly. They were very impressed and I exchanged contact information with 5-6 of them, who hope to join development eventually (probably this summer). On Friday, I'm flying over to LA at SCALE 5x (South California Linux Expo 2007) where Arty will be exhibiting ReactOS and I will be a speaker to give a lecture on ReactOS and Open Source involvement. A couple of weeks later, on the 27th, I'm flying over to University of Waterloo to meet the students in their CS club and other interested students in Software Engineering/CS to talk about ReactOS, my work, and also on using ReactOS as an educational tool, possibly to replace their current NachOS-based curriculum. In April, on the 11th, I will be flying to Porto Alegre in Brezil, at the 8th International Free Software Forum, where I will be a lecturer. Again, I will talk about ReactOS -- although I haven't found a specific topic yet, since I don't want to re-hash the SOCAL presentation. I have also been invited to demo ReactOS at a DemoCamp in all of Montreal, as far as I remember this date is in April as well. The other date I am aware of is FOSSCON 2007, which will be on the 22nd of September in San Diego (IIRC). Again, I will probably present about ReactOS -- definite topic to be determined. I have also mentionned ReactOS profusely in some personal interviews which will appear in some Montreal and even worldwide newspapers, as well as various online sources such as Slyck. My blog entry has recently motivated a donor to donate 1000$ US to the foundation; I am working with him to arrange a proper receipt. I hope that throughout the year, I'll be able to announce more events. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 7 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 25726: Make LoadCursorIconImage() find shared icons, even if they don't have the desired width/height. Now expl orer doesn't leak icons / bitmaps anymore. fixes bug 1554 See issue #1554 for more details.

by Murphy, Ged (Bolton)

tkreuzer(a)svn.reactos.org wrote: > + FreeResource(hResource); FreeResource is deprecated

18 years, 7 months

2
1
0 0

Wmi declarations in wmilib stub

by Felipe Villarroel

>From winddk.h: #define NTKERNELAPI DECLSPEC_IMPORT NTKERNELAPI NTSTATUS NTAPI WmiCompleteRequest( IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp, IN NTSTATUS Status, IN ULONG BufferUsed, IN CCHAR PriorityBoost); In wmilib.c: NTSTATUS NTAPI WmiCompleteRequest(IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp, IN NTSTATUS Status, IN ULONG BufferUsed, IN CCHAR PriorityBoost) winddk.h should be modified? This difference (in the three functions) breaks build (also the windows ddk define this as NTSTATUS only). (If i redefine the functions in wmilib.c i get a strange bug in gcc: [CC] drivers\wmi\wmilib.c drivers\wmi\wmilib.c: In function 'WmiSystemControl': drivers\wmi\wmilib.c:62: internal compiler error: in rest_of_handle_final, at final.c:3942 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. mingw32-make: *** [obj-i386\drivers\wmi\wmilib.o] Error 1 Best regards, Logan_V8

18 years, 7 months

1
0
0 0

Security problem in NtGdiCreateCompatibleDC?

by Timo Kreuzer

Please have a look at that code: NtGdiCreateCompatibleDC @ 192: ... hNewDC = DC_AllocDC <http://www.reactos.org/generated/doxygen/de/dcc/dc_8h.html#a12>(&OrigDC->DriverName <http://www.reactos.org/generated/doxygen/d9/de9/struct__DC.html#o8>); if (NULL == hNewDC) { DC_UnlockDc(OrigDC); if (NULL != DisplayDC) { NtGdiDeleteObjectApp <http://www.reactos.org/generated/doxygen/d7/de8/subsystems_2win32_2win32k_2…>(DisplayDC); } return NULL; } NewDC = DC_LockDc( hNewDC ); ... I am not completely sure (GreatLord said it was fine) but i think it might not be. Let's think of a condition when process x, thread 0 does try call NtGdiCreateCompatibleDC and Allocates the DC. Wouldn't there be the chance of thread 1 to get a lock on the DC (by guessing it's handle) just after it was created and make DC_LockDC return NULL? GDIOBJ_LockObj checks if the ProcessID is the same as PsGetCurrentProcessId() , but not more. So I think a second thread might do a timed attack and get a lock on the just created DC.

18 years, 7 months

1
0
0 0

problems building with gcc 4.1.2 (RosBE 0.3.4)

by Felipe Villarroel

Hi, today i tried to compile ReactOS with gcc 4.1.2 under RosBE 0.3.4 (previously i used both gcc 3.4.5 and gcc 4.1.2, with a previous svn revision). Before trying to switch compilers i have successfully built an iso image with gcc 3.4.5. So, i issued a make clean in the gcc 3.4.5 enviroment. Then i changed to gcc 4.1.2 and issued a make bootcd (with current SVN). In the building process i got this error message: [CC] lib\intrlck\i386\compareexchange.c [AR] obj-i386\lib\intrlck\intrlck.a [LD] output-i386\dll\ntdll\ntdll.dll [RSYM] output-i386\dll\ntdll\ntdll.dll [LD] output-i386\dll\win32\kernel32\kernel32.dll obj-i386\dll\win32\kernel32\misc\dllmain.o: In function `InterlockedCompareExchange@12': d:/reactos/current/include/psdk/intrin.h:110: undefined reference to `__sync_val_compare_and_swap_4' obj-i386\dll\win32\kernel32\misc\dllmain.o: In function `InterlockedIncrement@4': d:/reactos/current/include/psdk/intrin.h:139: undefined reference to `__sync_fetch_and_add_4' obj-i386\dll\win32\kernel32\misc\dllmain.o: In function `InterlockedDecrement@4': d:/reactos/current/include/psdk/intrin.h:139: undefined reference to `__sync_fetch_and_add_4' obj-i386\dll\win32\kernel32\misc\dllmain.o: In function `InterlockedExchangeAdd@8': d:/reactos/current/include/psdk/intrin.h:139: undefined reference to `__sync_fetch_and_add_4' collect2: ld returned 1 exit status mingw32-make: *** [output-i386\dll\win32\kernel32\kernel32.dll] Error 1 I'm using ReactOS Build Environment 0.3.4-4.1.2-20061229-prerelease-patched. Probably i could comment the gcc version checking in intrin.h to get this to compile, but that isn't nice/right :P. As far as i know __sync_* functions are supplied by the compiler and they should be present in gcc 4.1.2. Is this right? Anyone got an idea why this doesn't work? Thanks in advance for your help, Best regards, Logan_V8 d:\reactos\current>echo __GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__ > p.txt d:\reactos\current>cpp < p.txt cc1.exe: warning: is shorter than expected # 1 "<stdin>" # 1 "<built-in>" # 1 "<command line>" # 1 "<stdin>" 4 * 10000 + 1 * 100 + 2

18 years, 7 months

1
1
0 0

Re: [ros-dev] [ros-diffs] [fireball] 25667: - Comment out clearing of KeLoaderBlock (introduced by 25629), because it looks like someone is still calling IopLoadServiceModule() even after that point. 2nd stage boots with this change.

by Alex Ionescu

fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Thu Feb 1 01:30:59 2007 > New Revision: 25667 > > URL: http://svn.reactos.org/svn/reactos?rev=25667&view=rev > Log: > - Comment out clearing of KeLoaderBlock (introduced by 25629), because it looks like someone is still calling IopLoadServiceModule() even after that point. 2nd stage boots with this change. > This does not fix the freeze/slowdown/issue I am seeing with the NT scheduler disabled. I still can't boot to desktop. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 7 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [fireball] 25667: - Comment out clearing of KeLoaderBlock (introduced by 25629), because it looks like someone is still calling IopLoadServiceModule() even after that point. 2nd stage boots with this change.

by Alex Ionescu

fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Thu Feb 1 01:30:59 2007 > New Revision: 25667 > > URL: http://svn.reactos.org/svn/reactos?rev=25667&view=rev > Log: > - Comment out clearing of KeLoaderBlock (introduced by 25629), because it looks like someone is still calling IopLoadServiceModule() even after that point. 2nd stage boots with this change. > > I still get a hang after pressing "Next" on the last 2nd stage setup wizard page. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 7 months

2
3
0 0

How it went: running Burn under ReactOS

by Alexander Rødseth

Hi, A few weeks ago, I received an e-mail asking me to test Burn, my old drawing-program for Dos, on ReactOS. However, I've lost that e-mail somehow, so I'm hoping this mailinglist is the right place to send my reply, as a substitute. The original e-mail was from someone affiliated with ReactOS. I used ReactOS 0.3-RELEASE (Build 20060827-r23747), running under Qemu. A screenshot of how it went is included. ("Bad command or filename", even though the command was valid). Burn works perfectly well under DosBox. Hope this was of any help whatsoever, and thanks for your contributions to the world of open source. Best regards, Alexander Rødseth

18 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev