- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [mnordell] 29702: Don't try to open a harddisk for reading when checking for it to create the PhysicalDriveN links. Instead, request FILE_READ_ATTRIBUTES. This silences a hack-warning in IopParseDevice, that now possibly can be removed.
by Alex Ionescu 23 Oct '07

23 Oct '07

Windows uses the FILE_READ_DATA flag here, not FILE_READ_ATTRIBUTES. Silencing a warning does not mean fixing it -- all this is doing is hiding the bug (which is somewhere in vfat) in a place that's quite exposed. Because it's now gone, it'll probably happen in some mysterious application 2 years from now and nobody will know why. -- Best regards, Alex Ionescu On 20-Oct-07, at 3:36 AM, mnordell(a)svn.reactos.org wrote: > Author: mnordell > Date: Sat Oct 20 11:36:17 2007 > New Revision: 29702 > > URL: http://svn.reactos.org/svn/reactos?rev=29702&view=rev > Log: > Don't try to open a harddisk for reading when checking for it to > create the PhysicalDriveN links. Instead, request > FILE_READ_ATTRIBUTES. This silences a hack-warning in > IopParseDevice, that now possibly can be removed. > > Modified: > trunk/reactos/ntoskrnl/fstub/disksup.c > trunk/reactos/ntoskrnl/io/iomgr/file.c > > Modified: trunk/reactos/ntoskrnl/fstub/disksup.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ > fstub/disksup.c?rev=29702&r1=29701&r2=29702&view=diff > ====================================================================== > ======== > --- trunk/reactos/ntoskrnl/fstub/disksup.c (original) > +++ trunk/reactos/ntoskrnl/fstub/disksup.c Sat Oct 20 11:36:17 2007 > @@ -481,7 +481,7 @@ > NULL); > > Status = ZwOpenFile(&FileHandle, > - FILE_READ_DATA | SYNCHRONIZE, > + FILE_READ_ATTRIBUTES | SYNCHRONIZE, > &ObjectAttributes, > &StatusBlock, > FILE_SHARE_READ, > > Modified: trunk/reactos/ntoskrnl/io/iomgr/file.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/ > iomgr/file.c?rev=29702&r1=29701&r2=29702&view=diff > ====================================================================== > ======== > --- trunk/reactos/ntoskrnl/io/iomgr/file.c (original) > +++ trunk/reactos/ntoskrnl/io/iomgr/file.c Sat Oct 20 11:36:17 2007 > @@ -404,6 +404,9 @@ > > /* FIXME: Small hack still exists, have to check why... > * This is triggered multiple times by usetup and then once > per boot. > + * TMN: NOTE: It might have been fixed now, by changing the > requested > + * openmode in xHalIoAssignDriveLetters from FILE_READ_DATA to > + * FILE_READ_ATTRIBUTES. If verified, this hack should be > removed. > */ > if (!(DirectOpen) && > !(RemainingName->Length) && > >

1 0

Re: [ros-dev] [ros-diffs] [mnordell] 29826: First small attempt at implementing process memory quota. Currently disabled without explicit code modification (enabled by macro) to not modify behaviour of trunk.
by Alex Ionescu 23 Oct '07

23 Oct '07

Couple of comments: 1) Why implement new, complex features in the kernel instead of fixing current bugs? I know it's fun to start hacking on new code, but priorities should be to implement stuff that's required not to break other apps/add functionality, not internal features which will take ages to implement (the Ps functions for quota are "easy", it's the Mm part that's bad). I had already written all these functions, but deleted them, because nobody needed them, and the Mm part was too complex to do. 2) Why are you bothering with PspPoolQuotaIndexFromPoolType? In case you haven't noticed, there's something called pool masks which make the operation very easy without requiring a function call (such as POOL_TYPE_MASK or BASE_POOL_MASK, forgot how it's called). 3) INT is not an acceptable kernel type. 4) We don't use "static" in the kernel. 5) Instead of duplicating code, perhaps consider calling a main worker function such as PspChargeQuota? 6) Consider using an enum instead of magic numbers inside the quota entries, I believe it's called PS_QUOTA_TYPE. 7) The quota routines require interlocks, otherwise they will not be thread safe. 8) They also require a global spinlock in the "give back" case. 9) Committing code that won't even build, even with the define on, isn't very appropriate. Trunk isn't a playground. If someone wants to actually test this, they won't be able to build it because of things like "refuse". SVN should contain code that builds at any time. It's not hard to write /* TODO */.. Just my 2 cents -- Best regards, Alex Ionescu On 23-Oct-07, at 6:05 AM, mnordell(a)svn.reactos.org wrote: > Author: mnordell > Date: Tue Oct 23 14:05:40 2007 > New Revision: 29826 > > URL: http://svn.reactos.org/svn/reactos?rev=29826&view=rev > Log: > First small attempt at implementing process memory quota. Currently > disabled without explicit code modification (enabled by macro) to > not modify behaviour of trunk. > > Modified: > trunk/reactos/ntoskrnl/ps/quota.c > > Modified: trunk/reactos/ntoskrnl/ps/quota.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/ > quota.c?rev=29826&r1=29825&r2=29826&view=diff > ====================================================================== > ======== > --- trunk/reactos/ntoskrnl/ps/quota.c (original) > +++ trunk/reactos/ntoskrnl/ps/quota.c Tue Oct 23 14:05:40 2007 > @@ -15,6 +15,12 @@ > > EPROCESS_QUOTA_BLOCK PspDefaultQuotaBlock; > > + > +/* Define this macro to enable quota code testing. Once quota code > is */ > +/* stable and verified, remove this macro and checks for it. */ > +/*#define PS_QUOTA_ENABLE_QUOTA_CODE*/ > + > + > /* FUNCTIONS > ***************************************************************/ > > VOID > @@ -66,9 +72,29 @@ > { > /* Don't do anything for the system process */ > if (Process == PsInitialSystemProcess) return STATUS_SUCCESS; > - > + > +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE > + if (Process) > + { > + /* TODO: Check with Process->QuotaBlock if this can be > satisfied, */ > + /* assuming this indeed is the place to check it. */ > + /* Probably something like: > + if (Process->QuotaUsage[2] + Amount > > + Process->QuotaBlock->QuotaEntry[2].Limit) > + { > + refuse > + } > + */ > + Process->QuotaUsage[2] += Amount; > + if (Process->QuotaPeak[2] < Process->QuotaUsage[2]) > + { > + Process->QuotaPeak[2] = Process->QuotaUsage[2]; > + } > + } > +#else > /* Otherwise, not implemented */ > UNIMPLEMENTED; > +#endif > return STATUS_SUCCESS; > } > > @@ -115,6 +141,38 @@ > return PsChargeProcessPoolQuota(Process, PagedPool, Amount); > } > > +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE > +/* > + * Internal helper function. > + * Returns the index of the Quota* member in EPROCESS for > + * a specified pool type, or -1 on failure. > + */ > +static > +INT > +PspPoolQuotaIndexFromPoolType(POOL_TYPE PoolType) > +{ > + switch (PoolType) > + { > + case NonPagedPool: > + case NonPagedPoolMustSucceed: > + case NonPagedPoolCacheAligned: > + case NonPagedPoolCacheAlignedMustS: > + case NonPagedPoolSession: > + case NonPagedPoolMustSucceedSession: > + case NonPagedPoolCacheAlignedSession: > + case NonPagedPoolCacheAlignedMustSSession: > + return 1; > + case PagedPool: > + case PagedPoolCacheAligned: > + case PagedPoolSession: > + case PagedPoolCacheAlignedSession: > + return 0; > + default: > + return -1; > + } > +} > +#endif > + > /* > * @implemented > */ > @@ -124,10 +182,32 @@ > IN POOL_TYPE PoolType, > IN ULONG Amount) > { > + INT PoolIndex; > /* Don't do anything for the system process */ > if (Process == PsInitialSystemProcess) return STATUS_SUCCESS; > > - UNIMPLEMENTED; > +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE > + PoolIndex = PspPoolQuotaIndexFromPoolType(PoolType); > + if (Process && PoolIndex != -1) > + { > + /* TODO: Check with Process->QuotaBlock if this can be > satisfied, */ > + /* assuming this indeed is the place to check it. */ > + /* Probably something like: > + if (Process->QuotaUsage[PoolIndex] + Amount > > + Process->QuotaBlock->QuotaEntry[PoolIndex].Limit) > + { > + refuse > + } > + */ > + Process->QuotaUsage[PoolIndex] += Amount; > + if (Process->QuotaPeak[PoolIndex] < Process->QuotaUsage > [PoolIndex]) > + { > + Process->QuotaPeak[PoolIndex] = Process->QuotaUsage > [PoolIndex]; > + } > + } > +#else > + UNIMPLEMENTED; > +#endif > return STATUS_SUCCESS; > } > > @@ -140,10 +220,26 @@ > IN POOL_TYPE PoolType, > IN ULONG_PTR Amount) > { > + INT PoolIndex; > /* Don't do anything for the system process */ > if (Process == PsInitialSystemProcess) return; > > - UNIMPLEMENTED; > +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE > + PoolIndex = PspPoolQuotaIndexFromPoolType(PoolType); > + if (Process && PoolIndex != -1) > + { > + if (Process->QuotaUsage[PoolIndex] < Amount) > + { > + DPRINT1("WARNING: Process->QuotaUsage sanity check > failed.\n"); > + } > + else > + { > + Process->QuotaUsage[PoolIndex] -= Amount; > + } > + } > +#else > + UNIMPLEMENTED; > +#endif > } > > /* > @@ -157,7 +253,11 @@ > /* Don't do anything for the system process */ > if (Process == PsInitialSystemProcess) return; > > - UNIMPLEMENTED; > +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE > + PsReturnPoolQuota(Process, NonPagedPool, Amount); > +#else > + UNIMPLEMENTED; > +#endif > } > > /* > @@ -171,7 +271,11 @@ > /* Don't do anything for the system process */ > if (Process == PsInitialSystemProcess) return; > > - UNIMPLEMENTED; > +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE > + PsReturnPoolQuota(Process, PagedPool, Amount); > +#else > + UNIMPLEMENTED; > +#endif > } > > NTSTATUS > @@ -182,8 +286,22 @@ > /* Don't do anything for the system process */ > if (Process == PsInitialSystemProcess) return STATUS_SUCCESS; > > +#ifdef PS_QUOTA_ENABLE_QUOTA_CODE > + if (Process) > + { > + if (Process->QuotaUsage[2] < Amount) > + { > + DPRINT1("WARNING: Process PageFileQuotaUsage sanity > check failed.\n"); > + } > + else > + { > + Process->QuotaUsage[2] -= Amount; > + } > + } > +#else > /* Otherwise, not implemented */ > UNIMPLEMENTED; > +#endif > return STATUS_SUCCESS; > } > > >

1 0

[ros-diffs] [greatlrd] 29788: rename dc.h to win32kdc.h rename driver.h to win32kdriver.h
by James Tabor 22 Oct '07

22 Oct '07

Hi! Good job! But this is all kinds of type of wrong! There are internal calls for win32k dc.c and dcutils.c in there. What you should have done was move the DC object structure to ntgdihdl.h. So, please revert or but back dc.h and then move the DC object to ntgdihld.h where it belongs. Thanks, James

2 3

[RE:] ReactOS 0.3.4 Hardware Support
by James Tabor 22 Oct '07

22 Oct '07

Hi! What was the revision for the floppy driver that made it inoperative? You told me on IRC. I did not take my notes to work. > Hello, > > I think that 0.3.4 should have most hardware regressions (floppy and > vga) fixed. I know I'm not the one to say this but, we are already > closer to this goal than we were with 0.3.3. Fixing the floppy > regression should only involve finding the spot in which floppy is not > reporting correctly to ntoskrnl. I did some tests on this issue and it > fails on line 596-598 of ntoskrnl\io\iomgr\volume.c and floppy was never > mounted as the status reported was STATUS_IO_DEVICE_ERROR from line > 1017-1021 in drivers\storage\floppy\floppy.c. I don't know much about > the vga regression but I'd think that it may only require a few days > work to find and fix the issue. We already have SATA support included > with trunk (uniata.sys) and SCSI is also working now. > > -aicommander > Thanks, James

4 5

Re: [ros-dev] [ros-diffs] [fireball] 29714: Dmitry Chapyshev <lentind@yandex.ru> - Fully implement tapiui.dll, compatible with Windows. - Icons come from SUSE's yast2-industrial; 203,202.ico and 301,302.bmp are done by me based on Tango.
by Ged 21 Oct '07

21 Oct '07

These resources have been lifted straight out of the Windows dll. Absolutley no attempt has been made to change anything. IMO, this should be removed until someone manually implements it. Ged. fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Sat Oct 20 21:16:30 2007 > New Revision: 29714 > > URL: http://svn.reactos.org/svn/reactos?rev=29714&view=rev > Log: > Dmitry Chapyshev <lentind(a)yandex.ru> > - Fully implement tapiui.dll, compatible with Windows. > - Icons come from SUSE's yast2-industrial; 203,202.ico and 301,302.bmp are done by me based on Tango > > >

1 0

ReactOS 0.3.4 Hardware Support
by Cam 20 Oct '07

20 Oct '07

Hello, I think that 0.3.4 should have most hardware regressions (floppy and vga) fixed. I know I'm not the one to say this but, we are already closer to this goal than we were with 0.3.3. Fixing the floppy regression should only involve finding the spot in which floppy is not reporting correctly to ntoskrnl. I did some tests on this issue and it fails on line 596-598 of ntoskrnl\io\iomgr\volume.c and floppy was never mounted as the status reported was STATUS_IO_DEVICE_ERROR from line 1017-1021 in drivers\storage\floppy\floppy.c. I don't know much about the vga regression but I'd think that it may only require a few days work to find and fix the issue. We already have SATA support included with trunk (uniata.sys) and SCSI is also working now. -aicommander

2 1

Porting ReactOS to the L4 micro-kernel
by Henning Schild 20 Oct '07

20 Oct '07

Hi there, i am thinking of porting ros to the L4 micro-kernel as topic for my diploma thesis. The operating systems group in Dresden already ported Linux to L4 (http://os.inf.tu-dresden.de/L4/LinuxOnL4/) and proofed that L4 offers all that is needed to run an operating system in userspace on top of it. The goal of the work would be to be able to run windows applications next to miro-kernel applications. And to compare the performance with that of pure ros, L4Linux/wine and windows. A comparison between the port and L4Linux could also be part of the work. (mapping processes to L4 tasks, memory management, interrupt-handling and so on) I am not very experienced in C or assembler programming but am motivated to learn. But before i start working on that topic i have some questions on the portability of ros. In svn and on the ros website i found that there is a ppc port of ros. And on irc someone told me that there is ongoing work on a ros usermode port. I also read about a xen port. But i did not yet find working copies of the any of that ports. I built ros for i386 on my machine and was able to boot it in vmware. I also tried building the latest svn version with ROS_ARCH=powerpc but that did not succeed. 1. Did anyone ever finish a port to another arch? 2. How portable is ros in general? Meaning how much code would have to be changed. I hope there are abstractions and only 10-15% of the kernel would have to be changed. 3. Do you believe that one person new to ros can finish that kind of work in 6 months? I know that might be hard to answer but how long did any of you need to learn ros in detail? 4. If there are working ports, how long did it take to implement them? If there are not, what are the reasons they where never finished? I am thinking of lots of assembler and i386 hacks. 5. Finally, what do think of the idea itself? I hope you take the time to answer my questions. I am still on the way to determine whether i really want to do that and whether i can do this in 6 months. regards, Henning Schild

11 13

[ros-diffs] [janderwald] 29678: Author: Evan Teran <evan.teran at gmail.com> - Fix typo in GlobalAlloc parameters.
by James Tabor 19 Oct '07

19 Oct '07

Hi! This + hargv=GlobalAlloc(0, size); should be + hargv=GlobalAlloc(GMEM_FIXED, size); No need to rush it! Fix it, in the next update. Thanks, James Ref: http://msdn2.microsoft.com/en-us/library/aa366574.aspx

1 0

Cannot compile, error with WRC
by carlo.bramix 19 Oct '07

19 Oct '07

Hello, after updating to r29681, I cannot compile ROS. The error is: [WRC] obj-i386\base\applications\cacls\cacls.coff output-i386\tools\wrc\wrc.exe: unknown option -- W output-i386\tools\wrc\wrc.exe: unknown option -- n output-i386\tools\wrc\wrc.exe: unknown option -- W output-i386\tools\wrc\wrc.exe: unknown option -- p Error: Too many output files. mingw32-make: *** [obj-i386\base\applications\cacls\cacls.coff] Error 2 Sincerely, Carlo Bramini

2 1

Re: [ros-dev] Targeting multiple Windows versions
by Aleksey Bragin 19 Oct '07

19 Oct '07

Hi Marc, the patch / bug IS valid, Magnus made a mistake and closed it. I wanted to do the same, but it's rather timeconsuming, so I appreciate you took the first steps. Still, some modules may require setting some specific version - that's allright, we can leave some exceptions for now, but otherwise, version number should be set globally, not in every .rbuild file (which is so wrong). WBR, Aleksey Bragin. On Oct 19, 2007, at 2:53 AM, Marc Piulachs wrote: > Hi, > > On the reactos frontpage I see that the project aims to reimplement > WindowsXP , that is NT 5.2 , but currently most of the modules > define their > own target version ranging from NT4 to NT 5.3 (2003) .On recent > shell32 > commits I have even seen someone introducing Vista-only APIs. > > I think an effort has to be done to fix that situation ,IMHO targeting > multiple windows versions is fine but not a mix of them so I > recently posted > a bug report on mozilla to have it present at least. > http://www.reactos.org/bugzilla/show_bug.cgi?id=2745 but It has > been marked > as invalid and I can't understand the reason given, I may be wrong > about > that but I'd like to know what I'm missing here, can anyone clarify? > > /Marc

1 0

Re: [ros-dev] [ros-diffs] [mnordell] 29653: Patch from aicommander. Actually copy uniata.sys from the installation media, and disable VGA resolution selection as VGA is broken.
by Aleksey Bragin 18 Oct '07

18 Oct '07

Shouldn't it be finally fixed, instead? I don't know who broke it. Was it Magnus with the "No PNP videocard" commit? WBR, Aleksey Bragin. On Oct 18, 2007, at 8:01 AM, mnordell(a)svn.reactos.org wrote: > Author: mnordell > Date: Thu Oct 18 08:01:53 2007 > New Revision: 29653 > > URL: http://svn.reactos.org/svn/reactos?rev=29653&view=rev > Log: > Patch from aicommander. Actually copy uniata.sys from the > installation media, and disable VGA resolution selection as VGA is > broken. > [Display] > ;<id> = <user friendly name>,<spare>,<service key > name>,<hight>,<width>,<bpp> > -vga = "VGA Display (640x480x4)",,Vga,640,480,4 > +;vga = "VGA Display (640x480x4)",,Vga,640,480,4

1 0

Re: [ros-dev] ReactOS on VirtualBox
by Mike Leahy 17 Oct '07

17 Oct '07

It's in the User FAQ - third-last question, at the end of the answer it says: "Other virtual machines/x86 emulators should be able to run ReactOS as well, and ReactOS is known to run in at least Bochs, VMWare, VirtualPC and QEMU. If you know of other virtual machines that support it, please send an e-mail to the ros-dev mailing list." I didn't see any mention of it in the recent archives of the mailing list, so I thought I'd mention it. Sorry if I misunderstood. Perhaps I'll try out the other emulation tools, though I've found VirtualBox in general to be very easy to use. Regards, Mike Zachary Gorden wrote: >First, which FAQ? > >Second, I'll talk with Colin about it. Some of the devs don't like >vbox, >but so long as we can get it to work, it's more or less up to the >release >engineers and Aleksey what vm images to release. > >Z98 >Release Engineer (secondary) >

1 0

ReactOS on VirtualBox
by Mike Leahy 17 Oct '07

17 Oct '07

Hello list, As recommended in the FAQ, I thought I'd mention that I gave ReactOS a try as a virtual machine using VirtualBox (http://www.virtualbox.org), and it seems to work okay. It wouldn't be too difficult to post a VirtualBox virtual disk image file, though it only took a couple minutes to setup from the installation CD image. I'd like to know if anyone else has given it a try though, as I had some stability problems (random freezes, etc.). I look forward to the future releases of ReactOS. Regards, Mike

2 1

Re: [ros-dev] [ros-diffs] [tkreuzer] 29617: If cmd was started from a shortcut, use the shortcut's name as window title, else use executable name, like on windows. Doesn't work on ros atm, due to bug 2743, but works on win XP. So if'ed out atm.
by Thomas Weidenmueller 16 Oct '07

16 Oct '07

This is a hack that shouldn't be there. This is csrss' responsibility. - Thomas tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Tue Oct 16 02:23:42 2007 > New Revision: 29617 > > URL: http://svn.reactos.org/svn/reactos?rev=29617&view=rev > Log: > If cmd was started from a shortcut, use the shortcut's name as window title, else use executable name, like on windows. Doesn't work on ros atm, due to bug 2743, but works on win XP. So if'ed out atm. > > Modified: > trunk/reactos/base/shell/cmd/cmd.c > > Modified: trunk/reactos/base/shell/cmd/cmd.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/cmd/cmd.c?rev=2… > ============================================================================== > --- trunk/reactos/base/shell/cmd/cmd.c (original) > +++ trunk/reactos/base/shell/cmd/cmd.c Tue Oct 16 02:23:42 2007 > @@ -1603,6 +1603,53 @@ > } > #endif > > +void > +InitTitle() > +{ > + STARTUPINFOW StartupInfo; > + LPWSTR lpFileName; > + WCHAR szTitle[MAX_PATH+1]; > + > + GetStartupInfoW(&StartupInfo); > + > + if (StartupInfo.lpTitle) > + { > + /* Are we started from a shortcut? */ > + if (StartupInfo.dwFlags & 0x800) > + { > + UINT len; > + > + /* We are started from a shortcut, use the file name only */ > + lpFileName = wcsrchr(StartupInfo.lpTitle, '\\'); > + if (lpFileName == NULL) > + { > + lpFileName = StartupInfo.lpTitle; > + } > + > + /* Drop file extension, we simply assume 3 chars extension */ > + len = wcslen(lpFileName) - 4; > + if (len > 0) > + { > + len = min(len, MAX_PATH); > + wcsncpy(szTitle, lpFileName, len); > + szTitle[len] = 0; > + SetConsoleTitleW(szTitle); > + return; > + } > + } > + > + /* Use lpTitle member of STARTUPINFO */ > + SetConsoleTitleW(StartupInfo.lpTitle); > + return; > + } > + > + /* Set executable path as window title */ > + GetModuleFileNameW(NULL, szTitle, MAX_PATH); > + SetConsoleTitleW(szTitle); > + return; > +} > + > + > /* > * set up global initializations and process parameters > * > @@ -1625,6 +1672,11 @@ > osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO); > GetVersionEx (&osvi); > > + /* FIXME: Doesn't work in ros yet, because of missing functionality of ShellExecute. > + See bug 2743. Please unif as soon as it get's fixed. */ > +#if 0 > + InitTitle(); > +#endif > /* Some people like to run ReactOS cmd.exe on Win98, it helps in the > * build process. So don't link implicitly against ntdll.dll, load it > * dynamically instead */ > >

1 0

Doubts about the header changes in r29178
by Colin Finck 15 Oct '07

15 Oct '07

Hello, Hervé added some Standard C library headers to the "include/crt" directory in r29178. Now some people noticed that these changes broke building ReactOS components with MSVC using the ReactOS headers ("Debug - ReactOS headers" or "Release - ReactOS headers" configuration). I have some general doubts about these changes. >From my knowledge, the headers added in this commit, are compiler-specific and target-independent. You can easily see that they are specific to GCC/mingw as for example "stdio.h" includes a "_mingw.h" file with mingw-specific stuff. "stdarg.h" even leads to compilation problems with non-GCC-compilers (like MSVC), because it defines a type based on the __builtin_va_list type, and this built-in type only exists for GCC. In my opinion, this commit should be reverted. This way every compiler will use its own Standard C library headers and MSVC should be able to build ReactOS components using the ReactOS Win32 headers again. Regards, Colin

2 1

DC_ATTR with DCE
by James Tabor 13 Oct '07

13 Oct '07

Hi All! (subsystems\win32\win32k\ntuser\windc.c:156) FREE DCATTR!!!! NOT DCE_WINDOW_DC!!!!! hDC-> 6010078 (subsystems\win32\win32k\objects\dc.c:2549) DC_FreeDC DC_ATTR 0x2d80000 (subsystems\win32\win32k\ntuser\windc.c:551) ENTER!!!!!! DCX_CACHE!!!!!! hDC-> 6010078 (subsystems\win32\win32k\ntuser\windc.c:272) Exit!!!!! DCX_CACHE!!!!!! hDC-> 6010078 (subsystems\win32\win32k\objects\dc.c:2549) DC_FreeDC DC_ATTR 0x1020000 (subsystems\win32\win32k\ntuser\windc.c:156) FREE DCATTR!!!! NOT DCE_WINDOW_DC!!!!! hDC-> 14010092 (subsystems\win32\win32k\objects\dc.c:2549) DC_FreeDC DC_ATTR 0x1030000 (subsystems\win32\win32k\ntuser\windc.c:551) ENTER!!!!!! DCX_CACHE!!!!!! hDC-> 14010092 (subsystems\win32\win32k\ntuser\windc.c:272) Exit!!!!! DCX_CACHE!!!!!! hDC-> 14010092 (subsystems\win32\win32k\ntuser\windc.c:551) ENTER!!!!!! DCX_CACHE!!!!!! hDC-> 14010092 (subsystems\win32\win32k\ntuser\windc.c:272) Exit!!!!! DCX_CACHE!!!!!! hDC-> 14010092 Problem, Two Window DCE with DC objects are created and used through out the whole system and the ownership was passed to NULL for both DC objects. The dcattr, allocated and ownership belongs to the original process. So when testing the dcattr in user mode, creates user exception faults. DC object one: 6010078 and object two: 14010092. The Fix: First, I free the "non owned window (DCX_CACHE) DCE DC" dcattr before the DC is placed in "inaccessible mode" so the ownership of the dcattr is not lost. All traces of ownership comes from the DC handle information. Once it is set NULL it is lost. Second, I display the "Enter" (GetDCx) and "Exit" (ReleaseDC) for non owned window DCE DC. I'm doing this so I can trace it out. and,,,.... For DCX_CACHE DCE: ENTER "Get" allocate a new dcattr for the current process. EXIT "Release" free the dcattr for that process. Windows does something similar to this. Here is the patches,,, The test is: click on the time clock at the bottom right. Click on adjust time and date. There you go.... the Gdi patch allows access to the dcattr pen for the DCE DC now. It works,,,,, Thanks, James subsystems/win32/win32k: Index: ntuser/windc.c =================================================================== --- ntuser/windc.c (revision 29544) +++ ntuser/windc.c (working copy) @@ -153,6 +153,8 @@ } else { + DPRINT1("FREE DCATTR!!!! NOT DCE_WINDOW_DC!!!!! hDC-> %x\n", pDce->hDC); + DC_FreeDcAttr(pDce->hDC, NULL); // Free the dcattr! DC_SetOwnership(pDce->hDC, NULL); // This hDC is inaccessible! } @@ -267,6 +269,9 @@ dce->DCXFlags |= DCX_DCEEMPTY; } } + DPRINT1("Exit!!!!! DCX_CACHE!!!!!! hDC-> %x \n", dce->hDC); + DC_FreeDcAttr(dce->hDC, NULL); // Free the dcattr! + DC_SetOwnership(dce->hDC, NULL); } return 1; } @@ -543,6 +548,14 @@ DceUpdateVisRgn(Dce, Window, Flags); } + if (Dce->DCXFlags & DCX_CACHE) + { + DPRINT1("ENTER!!!!!! DCX_CACHE!!!!!! hDC-> %x\n", Dce->hDC); + DC_SetOwnership( Dce->hDC, PsGetCurrentProcess()); + DC_AllocateDcAttr( Dce->hDC, NULL); + DCU_SynchDcAttrtoUser( Dce->hDC, -1); // Copy data from dc to dcattr +// Dce->pProcess = PsGetCurrentProcess(); + } return(Dce->hDC); } dll/win32/gdi32: Index: dc.c =================================================================== --- dc.c (revision 29544) +++ dc.c (working copy) @@ -320,7 +320,7 @@ STDCALL GetDCObject( HDC hDC, INT iType) { -#if 0 +//#if 0 if((iType == GDI_OBJECT_TYPE_BRUSH) || (iType == GDI_OBJECT_TYPE_EXTPEN)|| (iType == GDI_OBJECT_TYPE_PEN) || @@ -348,7 +348,7 @@ } return hGO; } -#endif +//#endif return NtGdiGetDCObject( hDC, iType ); }

1 0

Re: [ros-dev] Porting ReactOS to the L4 micro-kernel
by Aleksey Bragin 10 Oct '07

10 Oct '07

Hi, what I can tell right away, is that it's a very interesting, suitable for diploma thesis work, but it's a challenge. You should posses general knowledge about operating systems development, and more specific knowledge about NT-based kernels, L4, and Linux. The only problem may be > I am not very experienced in C or assembler programming but am > motivated to learn. But before i start working on that topic i have but that could be compensated by outstanding OS dev skills / architecture knowledge. From the side of ReactOS Development Team, I'm sure you will have support in terms of either visiting the irc-channel #reactos on freenode or asking questions in this mailing list. WBR, Aleksey Bragin. On Oct 10, 2007, at 3:08 PM, Henning Schild wrote: > Hi there, > > i am thinking of porting ros to the L4 micro-kernel as topic for my > diploma thesis. The operating systems group in Dresden already ported > Linux to L4 (http://os.inf.tu-dresden.de/L4/LinuxOnL4/) and proofed > that L4 offers all that is needed to run an operating system in > userspace on top of it. > > The goal of the work would be to be able to run windows applications > next to miro-kernel applications. And to compare the performance with > that of pure ros, L4Linux/wine and windows. A comparison between the > port and L4Linux could also be part of the work. (mapping processes to > L4 tasks, memory management, interrupt-handling and so on) > > I am not very experienced in C or assembler programming but am > motivated to learn. But before i start working on that topic i have > some questions on the portability of ros. > > In svn and on the ros website i found that there is a ppc port of ros. > And on irc someone told me that there is ongoing work on a ros > usermode > port. I also read about a xen port. But i did not yet find working > copies of the any of that ports. I built ros for i386 on my > machine and was able to boot it in vmware. I also tried building the > latest svn version with ROS_ARCH=powerpc but that did not succeed. > > 1. Did anyone ever finish a port to another arch? > 2. How portable is ros in general? Meaning how much code would have to > be changed. I hope there are abstractions and only 10-15% of the > kernel > would have to be changed. > 3. Do you believe that one person new to ros can finish that kind of > work in 6 months? I know that might be hard to answer but how long did > any of you need to learn ros in detail? > 4. If there are working ports, how long did it take to implement > them? > If there are not, what are the reasons they where never finished? I am > thinking of lots of assembler and i386 hacks. > > 5. Finally, what do think of the idea itself? > > I hope you take the time to answer my questions. I am still on the way > to determine whether i really want to do that and whether i can do > this > in 6 months. > > regards, > Henning Schild

1 0

Re: [ros-dev] [Bug 2081] Format.exe can be run while reactos is active!
by James Tabor 10 Oct '07

10 Oct '07

Why was I added to this? Ask first! I can not do it all! B^| James ReactOS.Bugzilla(a)www.reactos.org wrote: > http://www.reactos.org/bugzilla/show_bug.cgi?id=2081 > > > amine48rz <amine48rz(a)gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > AssignedTo|ros-bugs(a)reactos.org |jimtabor@adsl-64-217-116- > | |74.dsl.hstntx.swbell.net > > > >

1 0

[Fwd: Re: [Bug 1172] VIA Rhine II net driver doesn't detect miniport]
by James Tabor 09 Oct '07

09 Oct '07

Hi! ReactOS.Bugzilla(a)www.reactos.org wrote: > http://www.reactos.org/bugzilla/show_bug.cgi?id=1172 > ------- Comment #16 From hpoussin 2007-10-08 10:44:44 CET ------- > > The device has been detected by PCI bus, and (as you didn't had any popup for > it), its driver has been found and probably installed. > I fixed a bug in driver installation in r29441, maybe it will help. > If it still doesn't work, can you enable debug output in > dll/win32/setupapi/devinst.c and dll/win32/netcfgx/netcfgx.c? > Okay! Will do! Since the bug report is closed, I guess we can work on the ML. I'll post my tests results. Thanks, James

1 0

Re: [ros-dev] [ros-diffs] [gbrunmar] 29384: Added context menu on right click in treeviews
by Ged 09 Oct '07

09 Oct '07

Have any attempts been made to submit these changes to Wine? local changes will just cause us grief further down the line. Ged. gbrunmar(a)svn.reactos.org wrote: > Author: gbrunmar > Date: Wed Oct 3 23:45:39 2007 > New Revision: 29384 > > URL: http://svn.reactos.org/svn/reactos?rev=29384&view=rev > Log: > Added context menu on right click in treeviews > > Modified: > trunk/reactos/dll/win32/comctl32/comctl32_ros.diff > trunk/reactos/dll/win32/comctl32/treeview.c > > Modified: trunk/reactos/dll/win32/comctl32/comctl32_ros.diff > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/comctl32/comctl3… > ============================================================================== > --- trunk/reactos/dll/win32/comctl32/comctl32_ros.diff (original) > +++ trunk/reactos/dll/win32/comctl32/comctl32_ros.diff Wed Oct 3 23:45:39 2007 > @@ -172,3 +172,26 @@ > if (infoPtr->cdmode & CDRF_NOTIFYPOSTPAINT) > infoPtr->cdmode = > TREEVIEW_SendCustomDrawNotify(infoPtr, CDDS_POSTPAINT, hdc, rect); > +@@ -4160,6 +4158,22 @@ > + static LRESULT > + TREEVIEW_RButtonUp(const TREEVIEW_INFO *infoPtr, const POINT *pPt) > + { > ++ TVHITTESTINFO ht; > ++ > ++ ht.pt = *pPt; > ++ > ++ TREEVIEW_HitTest(infoPtr, &ht); > ++ > ++ if (ht.hItem) > ++ { > ++ /* Change to screen coordinate for WM_CONTEXTMENU */ > ++ ClientToScreen(infoPtr->hwnd, &ht.pt); > ++ > ++ /* Send a WM_CONTEXTMENU message in response to the RBUTTONUP */ > ++ SendMessageW(infoPtr->hwnd, WM_CONTEXTMENU, > ++ (WPARAM)infoPtr->hwnd, MAKELPARAM(ht.pt.x, ht.pt.y)); > ++ } > ++ > + return 0; > + } > + > > Modified: trunk/reactos/dll/win32/comctl32/treeview.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/comctl32/treevie… > ============================================================================== > --- trunk/reactos/dll/win32/comctl32/treeview.c (original) > +++ trunk/reactos/dll/win32/comctl32/treeview.c Wed Oct 3 23:45:39 2007 > @@ -4158,6 +4158,22 @@ > static LRESULT > TREEVIEW_RButtonUp(const TREEVIEW_INFO *infoPtr, const POINT *pPt) > { > + TVHITTESTINFO ht; > + > + ht.pt = *pPt; > + > + TREEVIEW_HitTest(infoPtr, &ht); > + > + if (ht.hItem) > + { > + /* Change to screen coordinate for WM_CONTEXTMENU */ > + ClientToScreen(infoPtr->hwnd, &ht.pt); > + > + /* Send a WM_CONTEXTMENU message in response to the RBUTTONUP */ > + SendMessageW(infoPtr->hwnd, WM_CONTEXTMENU, > + (WPARAM)infoPtr->hwnd, MAKELPARAM(ht.pt.x, ht.pt.y)); > + } > + > return 0; > } > > > > >

7 9

Re: [ros-dev] [ros-diffs] [gedmurphy] 29469: add wine's wordpad asthe default
by Aleksey Bragin 09 Oct '07

09 Oct '07

Ok, that's good then, no need to delete it. But moving to rosapps may be a not bad idea (still including into the build). WBR, Aleksey Bragin. On Oct 9, 2007, at 3:50 PM, Ged wrote: > Aleksey Bragin wrote: >> Is there a reason to keep the wordpad we have? Is it better, >> worse, differences mergeable, etc? > > Our wordpad code is a great framework to build a much better, MDI > implementation of Wordpad. > > I added it in the hope that any potential 'would-be' developers > could use it > as a learning project into the world of Win32. As it is no one has > yet taken > it up, which is a bit of shame. > > It can be taken out of the build and even moved to ros-apps, but it > would be > a shame to delete it completley, as someone might one day take up the > challenge. > > Ged.

4 3

Re: [ros-dev] [ros-diffs] [gedmurphy] 29469: add wine's wordpad as the default
by Aleksey Bragin 09 Oct '07

09 Oct '07

Is there a reason to keep the wordpad we have? Is it better, worse, differences mergeable, etc? WBR, Aleksey Bragin. On Oct 9, 2007, at 1:00 PM, gedmurphy(a)svn.reactos.org wrote: > Author: gedmurphy > Date: Tue Oct 9 13:00:56 2007 > New Revision: 29469 > > URL: http://svn.reactos.org/svn/reactos?rev=29469&view=rev > Log: > add wine's wordpad as the default

2 1

Re: [ros-dev] Clean-room reversing
by Aleksey Bragin 09 Oct '07

09 Oct '07

Yes. Either reverse engineer and write docs (which can be used by ReactOS developers, provided they contain no source code derived from disassembly), or reverse engineer and write test cases. The latter method is [presumably] used by Wine developers, and it provides a very good legal ground. With the best regards, Aleksey Bragin. On Oct 9, 2007, at 5:12 AM, Josh H. wrote: > Is it okay to reverse through disassembly as long as clean room > methods > are used(only writeing docs, not implementing it yourself)? > > http://www.computerworld.com/softwaretopics/software/appdev/story/ > 0,10801,65532,00.html > http://en.wikipedia.org/wiki/Clean_room_design

1 0

Clean-room reversing
by Josh H. 09 Oct '07

09 Oct '07

Is it okay to reverse through disassembly as long as clean room methods are used(only writeing docs, not implementing it yourself)? http://www.computerworld.com/softwaretopics/software/appdev/story/0,10801,6… http://en.wikipedia.org/wiki/Clean_room_design -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

1 0

Re: [ros-dev] rbuild problems/suggestions
by Marc Piulachs 08 Oct '07

08 Oct '07

Anyone wants to comment on this? _____ From: Marc Piulachs [mailto:marc.piulachs@codexchange.net] Sent: Saturday, October 06, 2007 10:24 PM To: 'ros-dev(a)reactos.org' Subject: rbuild problems/suggestions Having worked with rbuild for a few weeks I have identified some problems that would like to share. I also would like to hear the developers' opinions about all of these issues because I want to start working to solving them. A) The behavior of the "include" + "directory" tags are inconsistent when an "include" is placed inside a "directory" for example: Correct: (expected : ke/i386/boot.S) <directory name="ke"> <if property="ARCH" value="i386"> <directory name="i386"> <file first="true">boot.S</file> Incorrect: (expected : reactos/reactos.rbuild real : reactos/reactos/reactos.rbuild) <directory name="reactos"> <xi:include href="reactos/reactos.rbuild" /> </directory> should be: <directory name="reactos"> <xi:include href="reactos.rbuild" /> </directory> B) The "oldcrt" attribute is no longer used and can be removed. C) The module types "Iso" , "LiveIso" , "IsoRegTest" and "LiveIsoRegTest" are IMHO hacks introduced to be able use the makefile generation code. rbuild is C++ so with a small code refactor they can be easly removed. D) Any module is using the "EmbeddedTypeLib" module type , is really needed or can be removed? E) IMHO the "ElfExecutable" is incorrect . I posted my reasons some time ago: http://www.reactos.org/archives/public/ros-dev/2007-September/009770.html http://www.reactos.org/archives/public/ros-dev/2007-September/009771.html http://www.reactos.org/archives/public/ros-dev/2007-September/009779.html F) The module type "alias" is only used for HAL related modules and IMHO it isn't requiered because the problem it tries to solve can be easly solved using "if" tags and conditional compilation. http://www.reactos.org/archives/public/ros-dev/2007-September/009798.html There are several reasons for this change: - Currently every platform requires 3 new HAL modules. In the future if new platforms are supported for example (X86 , XBOX , PPC , AMD64 , MIPS , IA64 , ARM ... ) 3 x 7 = 21 modules .. see what I'm saying? - It simplifies backends work. No need to include logic for alias handling. - Conceptually wrong . every module represents a particular functionality when you compile the module it should just reconfigure itself to produce the appropriate image for the configured architecture .It a good idea to have a true componentized operating system. Regarding the ModuleType IMHO they should be used to provide information that describes the module output/target not the build process! Iso , LiveIso , Alias , ... all of them are meaningless they are not true metadata. Long term enhancements: X) tags like "linkerflag" or "compilerflag" are gcc/mingw specific and should be replaced with other tags that provide the equivalent functionality using a more abstract aproach so other backends/compilers could benefit from it. rbuild files should only describe the source code and the compilation process without including specific information. /Marc

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev