- Ros-dev - ReactOS.org

Re: [ros-svn] [weiden] 13502: The structure layout of self-relative security descriptors may be different from absolute security descriptors depending on the platform. Self-relative security descriptors always use 32 bit offsets while absolute security descriptors use pointers which could be 64 bits.
by Alex Ionescu 12 Feb '05

12 Feb '05

weiden(a)svn.reactos.com wrote: >The structure layout of self-relative security descriptors may be different from absolute security descriptors depending on the platform. Self-relative security descriptors always use 32 bit offsets while absolute security descriptors use pointers which could be 64 bits. > > >Updated files: >trunk/reactos/include/ntos/rtl.h >trunk/reactos/include/ntos/security.h >trunk/reactos/lib/advapi32/sec/sec.c >trunk/reactos/lib/rtl/sd.c >trunk/reactos/ntoskrnl/se/sd.c >trunk/reactos/w32api/include/ddk/ntifs.h >trunk/reactos/w32api/include/ddk/winddk.h >trunk/reactos/w32api/include/winnt.h > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > > Well after arguing with me on IRC I'm happy to see that you finally realized I was right. Best regards, Alex Ionescu

2 1

Freeldy & NTVDMPAT/Deptool
by Alex Ionescu 12 Feb '05

12 Feb '05

Hi, First of all, what's up with ntvdmpath in the freeloader tree? I fail to see what it has to do with ROS, much less with freeloader...I'm recommending removal. Secondly... is there any problem with freeloader using the ros depends tool instead of deptool? I know before this was necessary because of different trees, but I would like to share as much as possible. Best regards, Alex Ionescu

2 1

Re: [ros-svn] [arty] 13483: Patch to fix NtCreateSempahore, in the case where the initial lookup
by Thomas Weidenmueller 10 Feb '05

10 Feb '05

arty(a)svn.reactos.com wrote: >Patch to fix NtCreateSempahore, in the case where the initial lookup >succeeds. We previously left the function without initializing >hSemaphore. Patch suggested by me and executed by hpoussin. > > To me it looks totally wrong. First of all, the handle in my tests is never written if the function fails (just create a testcase where your application tries to create thousands of semaphore objects to reproduce it). Second of all you initialize the semaphore object only if creating it failed, as in you initialize a semaphore object on a NULL pointer. Third of all you insert a handle to the object no matter if you previously could create it, so you would end up creating a handle to a null-pointer. The previous version I wrote just had one small bug, it checked if ObCreateObject failed to continue initialization and handle creation instead of checking if it succeeded. I'm going to revert this version of NtCreateSemaphore as it introduces even more bugs and adds behavior neither documented nor reproducable. I guess in case an application failed due to this function it was because of the fact that the function succeeded and didn't return a handle to a semaphore object even though one was created. Best Regards Thomas

2 1

vncviewer is oh so close
by art yerkes 10 Feb '05

10 Feb '05

The good news is that vncviewer is oh so close to running. If you apply this patch it *does* run, but I think the patch is wrong. Hopefully, after illustrating a wrong solution somebody might be able to see a right one. The problem it runs into is that the 2nd 'Alertability failed' message in KeWaitForMultipleObjects is always triggered, which makes vncviewer unable to display anything. If i #if 0 that block out, then it appears to work fine. I suspected that either we were being too conservative or there are too many APCs happening on that thread, and this confirms that one of the suspicions is true. The attached patch illustrates the probably broken solution. Screen: http://64.81.145.152/~arty/vncviewer2.jpg -- Here's a simple experiment. Stand on a train track between two locomotives which are pushing on you with equal force in opposite directions. You will exhibit no net motion. None the less, you may soon begin to notice that something important is happening. -- Robert Stirniman

1 0

Re: [ros-svn] [gvg] 13476: Fix EOL setting
by Martin Fuchs 09 Feb '05

09 Feb '05

Hi, did you know it is possible to configure Subversion, such that it automatically sets the correct properties for new checked in files? It looks at the file extensions to set properties such as the EOL style, mime type and to configure keyword expansion strings. For Windows the settings are stored in the registry, and for Unix they are stored in the file ~/.subversion/config. I attached a registry import file as an example, which contains settings I am using myself. Regards, Martin

2 1

RE: [weiden] 13459: moved smdll to rosrtl. We just _can't_have separate dlls for everything internal, that's what static libraries are for. Unless we want a dll hell evenworse than necessary...
by Ge van Geldorp 08 Feb '05

08 Feb '05

> From: weiden(a)svn.reactos.com > > moved smdll to rosrtl. We just _can't_ have separate dlls for > everything internal, that's what static libraries are for. > Unless we want a dll hell even worse than necessary... I think you are acting unbelievably rude here. Please revert your change and discuss this on the mailinglist first. Gé van Geldorp.

5 4

Re: [ros-diffs] [ion] 13305: Dynamic 3GB support, part 1. Only multiboot.S remains to be changed, all other parts of the Kernel now used KERNEL_BASE based on the command-line (Please don't use /3gb if you don't compile 3GB)
by Filip Navara 07 Feb '05

07 Feb '05

ion(a)svn.reactos.com wrote: >+ /* Gotta check 3GB setting right *here* before we use KERNEL_BASE! */ >+ if (!_strnicmp(KeLoaderCommandLine, "3GB", 3)) { > This looks obviously wrong, you're comparing the beginning of kernel command line with "3GB". It would make more sense to actually check if the "3GB" is somewhere in the command line (even though that's not correct too)... - Filip

2 1

bug in freeldr?
by Hartmut Birr 07 Feb '05

07 Feb '05

Hi, something has changed in freeldr. If freeldr founds a problem (missing driver) it shows a message box with an OK button. Since some days, it isn't possible to continue with pressing the enter key. - Hartmut

5 4

A Request (Direct3d)
by Maarten Bosma 05 Feb '05

05 Feb '05

Hi, I worked on direct3d for ros last year. But nothing useful came out. The problem is in "subsys/win32k/ntddraw/*.c". There are a some functions, which need to be implemented. They are called by DirectX and just pass the call to the display diver. Should be easily to implement - but not for me. I think it would be a real milestone for ReactOs, if a experienced kernel hacker would implement this, because the coder of the code that is already there "Peter Bajusz" had also coded a basic direct3d implementation about a year ago, that ran under winxp, but not under ros, because of this. (see old mailinglist arrive) However... I found out Peters new email address. He said that had to no time to work on it, but it still would be a huge step. Maarten Bosma

1 0

Header Problems
by Maarten Bosma 05 Feb '05

05 Feb '05

Hi, I have some header trouble: I can't include STL headers and window.h together. I also notice, that there isn't a urlmon.h except that form wine, and it isn't possible to include that for me. Maybe i have to include other headers, too ? Maarten Bosma

1 0

RE: [ros-svn] [weiden] 13406: Trevor McCort implemented desktop w allpaper changing
by PETREOLLE Sylvain 04 Feb '05

04 Feb '05

Now with source in svn trunk ! Well done ! Cordialement, Usurp (aka Sylvain PETREOLLE) Service de Production & d'Exploitation Informatique GEFCO - #DMIT/DATO/PSI/PEI Mail : <mailto:exploit@gefco.fr> Tel : 01.49.05.29.29 -----Message d'origine----- De : weiden(a)svn.reactos.com [mailto:weiden@svn.reactos.com] Envoyé : vendredi 4 février 2005 21:39 À : ros-svn(a)reactos.com Objet : [ros-svn] [weiden] 13406: Trevor McCort implemented desktop wallpaper changing Trevor McCort implemented desktop wallpaper changing ---------------------------------------------------------------------------- Ce message ainsi que toutes pièces jointes (le "message") sont confidentiels et sont exclusivement destinés à l'usage de la personne à laquelle ils sont adressés. Tout point de vue ou toute opinion contenus dans ce message expriment la pensée personnelle de leur auteur et ne représentent pas nécessairement la position des sociétés du Groupe GEFCO. Si vous n'êtes pas la personne à laquelle ce message est destiné, veuillez noter que vous avez reçu cet e-mail par erreur et qu'il vous est strictement interdit d'utiliser, de diffuser, de transférer, d'imprimer ou de copier ce message. Si vous avez reçu ce message par erreur, merci de contacter la personne qui vous l'a adressé et de l'effacer immédiatement. Les sociétés du Groupe GEFCO déclinent toute responsabilité en cas d'altération, de modification, d'édition, de diffusion sans autorisation de ce message ou en cas d'affection de ce message par un virus. This message and any attachments (the "message") are confidential and intended solely for the use of the individual to whom they are addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the GEFCO Group of Companies. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this message is strictly prohibited. If you have received this message in error please contact the sender and delete the message immediately. The GEFCO Group of Companies shall not be liable for the message if altered, changed, falsified, edited, diffused without authorization or affected by any virus. ----------------------------------------------------------------------------

1 0

Re: [ros-svn] [weiden] 13406: Trevor McCort implemented desktop wallpaper changing
by James Tabor 04 Feb '05

04 Feb '05

Hi! weiden(a)svn.reactos.com wrote: > Trevor McCort implemented desktop wallpaper changing > > > Added files: > trunk/reactos/lib/cpl/desk/appearance.c > trunk/reactos/lib/cpl/desk/background.c > trunk/reactos/lib/cpl/desk/dibitmap.c > trunk/reactos/lib/cpl/desk/dibitmap.h > trunk/reactos/lib/cpl/desk/en.rc > trunk/reactos/lib/cpl/desk/screensaver.c > trunk/reactos/lib/cpl/desk/settings.c > > Updated files: > trunk/reactos/include/defines.h > trunk/reactos/lib/cpl/desk/Makefile > trunk/reactos/lib/cpl/desk/desk.c > trunk/reactos/lib/cpl/desk/desk.h > trunk/reactos/lib/cpl/desk/desk.rc > trunk/reactos/lib/cpl/desk/resource.h > > Deleted files: > trunk/reactos/lib/cpl/desk/desk.dsp > trunk/reactos/lib/cpl/desk/desk.dsw > How do you change the wallpaper in ros w/o a control panel? James

1 0

vmware kernel stack fault
by Gedi 04 Feb '05

04 Feb '05

SVN (13468) is crashing upon the first stage install in vmware. After a bit of chat in IRC, we think this has come about after the 13462 FreeLdr patch. Can someone have a look at this please as it's a little beyond me at the moment. Here is a screenshot ( http://homepage.ntlworld.com/gedmurphy/installcrash.jpg ), and the vmware log is attached. Thanks, Ged. Feb 08 21:38:53: vmx| Log for VMware Workstation pid=3484 version=4.5.2 build=build-8848 option=Release.4.5.2 Feb 08 21:38:53: vmx| Command line: "C:\Program Files\VMware\VMware Workstation\bin\vmware-vmx.exe" "-@" "pipe=\\.\pipe\vmx5f7d22078c314fbf; vm=5f7d22078c314fbf" "E:\vm\win98.vmx" Feb 08 21:38:53: vmx| UI Connecting to pipe '\\.\pipe\vmx5f7d22078c314fbf' with user '(null)' Feb 08 21:38:53: vmx| ConfigDB: Set ConfigVersion to 7 Feb 08 21:38:53: vmx| ConfigDB: Set HWVersion to 3 Feb 08 21:38:53: vmx| GCFMI: DLL load=0x00330000 size=0x000cd000 name=LIBEAY32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x00400000 size=0x00395000 name=vmware-vmx.exe Feb 08 21:38:53: vmx| GCFMI: DLL load=0x690d0000 size=0x0000d000 name=ntwrap.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x71aa0000 size=0x00008000 name=WS2HELP.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x71ab0000 size=0x00017000 name=WS2_32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x71ad0000 size=0x00009000 name=WSOCK32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x72280000 size=0x0002a000 name=DINPUT.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x73dd0000 size=0x000fe000 name=MFC42.DLL Feb 08 21:38:53: vmx| GCFMI: DLL load=0x73f10000 size=0x0005c000 name=DSOUND.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x74ae0000 size=0x00007000 name=CFGMGR32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x76780000 size=0x00009000 name=shfolder.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x76b40000 size=0x0002d000 name=WINMM.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x76bf0000 size=0x0000b000 name=PSAPI.DLL Feb 08 21:38:53: vmx| GCFMI: DLL load=0x773d0000 size=0x00102000 name=comctl32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x774e0000 size=0x0013c000 name=ole32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x77920000 size=0x000f3000 name=setupapi.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x77c00000 size=0x00008000 name=VERSION.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x77c10000 size=0x00058000 name=MSVCRT.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x77d40000 size=0x00090000 name=USER32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x77e70000 size=0x00091000 name=RPCRT4.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x77f10000 size=0x00046000 name=GDI32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x77f60000 size=0x00076000 name=SHLWAPI.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x77fe0000 size=0x00011000 name=Secur32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x7c800000 size=0x000f4000 name=kernel32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x7c900000 size=0x000b0000 name=ntdll.dll Feb 08 21:38:53: vmx| GCFMI: reached kernel memory at 0x7fff0000 Feb 08 21:38:53: vmx| GCFMI: free=0x67a6e000, potential=0x6893b000 start=0x00795000 Feb 08 21:38:53: vmx| CPU #0 TSC = 32656457339752 Feb 08 21:38:53: vmx| TSC delta 0 Feb 08 21:38:53: vmx| VMMon_GetkHzEstimate: Calculated 1993531 kHz Feb 08 21:38:53: vmx| pcpu #0 CPUID numEntries=2 GenuineIntel Feb 08 21:38:53: vmx| pcpu #0 CPUID version=0xf24 features=0x3febf9ff extFeatures=0x0 ebx=0x1080e Feb 08 21:38:53: vmx| CPUID common features: 0x3febf9ff extFeatures: 0 Feb 08 21:38:53: vmx| GCFMI: DLL load=0x00330000 size=0x000cd000 name=LIBEAY32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x00400000 size=0x00395000 name=vmware-vmx.exe Feb 08 21:38:53: vmx| GCFMI: DLL load=0x690d0000 size=0x0000d000 name=ntwrap.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x71aa0000 size=0x00008000 name=WS2HELP.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x71ab0000 size=0x00017000 name=WS2_32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x71ad0000 size=0x00009000 name=WSOCK32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x72280000 size=0x0002a000 name=DINPUT.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x73dd0000 size=0x000fe000 name=MFC42.DLL Feb 08 21:38:53: vmx| GCFMI: DLL load=0x73f10000 size=0x0005c000 name=DSOUND.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x74ae0000 size=0x00007000 name=CFGMGR32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x76780000 size=0x00009000 name=shfolder.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x76b40000 size=0x0002d000 name=WINMM.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x76bf0000 size=0x0000b000 name=PSAPI.DLL Feb 08 21:38:53: vmx| GCFMI: DLL load=0x773d0000 size=0x00102000 name=comctl32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x774e0000 size=0x0013c000 name=ole32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x77920000 size=0x000f3000 name=setupapi.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x77c00000 size=0x00008000 name=VERSION.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x77c10000 size=0x00058000 name=MSVCRT.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x77d40000 size=0x00090000 name=USER32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x77e70000 size=0x00091000 name=RPCRT4.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x77f10000 size=0x00046000 name=GDI32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x77f60000 size=0x00076000 name=SHLWAPI.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x77fe0000 size=0x00011000 name=Secur32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x7c800000 size=0x000f4000 name=kernel32.dll Feb 08 21:38:53: vmx| GCFMI: DLL load=0x7c900000 size=0x000b0000 name=ntdll.dll Feb 08 21:38:53: vmx| GCFMI: reached kernel memory at 0x7fff0000 Feb 08 21:38:53: vmx| GCFMI: free=0x67a6e000, potential=0x6893b000 start=0x00795000 Feb 08 21:38:53: vmx| changing directory to E:\vm\. Feb 08 21:38:53: vmx| Config file: E:\vm\win98.vmx Feb 08 21:38:54: vmx| PowerOn Feb 08 21:38:54: vmx| HOST Windows version 5.1, build 2600, platform 2, "Service Pack 2" Feb 08 21:38:54: vmx| DICT --- USER PREFERENCES Feb 08 21:38:54: vmx| DICT pref.view.navBar.type = favorites Feb 08 21:38:54: vmx| DICT pref.mruDest0.present = FALSE Feb 08 21:38:54: vmx| DICT pref.mruDest0.destString = Feb 08 21:38:54: vmx| DICT pref.mruDest0.user = Feb 08 21:38:54: vmx| DICT pref.mruDest1.present = FALSE Feb 08 21:38:54: vmx| DICT pref.mruDest1.destString = Feb 08 21:38:54: vmx| DICT pref.mruDest1.user = Feb 08 21:38:54: vmx| DICT pref.mruDest2.present = FALSE Feb 08 21:38:54: vmx| DICT pref.mruDest2.destString = Feb 08 21:38:54: vmx| DICT pref.mruDest2.user = Feb 08 21:38:54: vmx| DICT pref.mruDest3.present = FALSE Feb 08 21:38:54: vmx| DICT pref.mruDest3.destString = Feb 08 21:38:54: vmx| DICT pref.mruDest3.user = Feb 08 21:38:54: vmx| DICT pref.mruDest4.present = FALSE Feb 08 21:38:54: vmx| DICT pref.mruDest4.destString = Feb 08 21:38:54: vmx| DICT pref.mruDest4.user = Feb 08 21:38:54: vmx| DICT pref.mruDest5.present = FALSE Feb 08 21:38:54: vmx| DICT pref.mruDest5.destString = Feb 08 21:38:54: vmx| DICT pref.mruDest5.user = Feb 08 21:38:54: vmx| DICT pref.mruDest6.present = FALSE Feb 08 21:38:54: vmx| DICT pref.mruDest6.destString = Feb 08 21:38:54: vmx| DICT pref.mruDest6.user = Feb 08 21:38:54: vmx| DICT pref.mruDest7.present = FALSE Feb 08 21:38:54: vmx| DICT pref.mruDest7.destString = Feb 08 21:38:54: vmx| DICT pref.mruDest7.user = Feb 08 21:38:54: vmx| DICT webUpdate.checkLast = 1107898305 Feb 08 21:38:54: vmx| DICT pref.placement.left = 345 Feb 08 21:38:54: vmx| DICT pref.placement.top = 131 Feb 08 21:38:54: vmx| DICT pref.placement.right = 1076 Feb 08 21:38:54: vmx| DICT pref.placement.bottom = 666 Feb 08 21:38:54: vmx| DICT pref.tip.index = 10 Feb 08 21:38:54: vmx| DICT prefvmx.mru.config = E:\vm\win98.vmx;C:\Documents and Settings\gedi\My Documents\My Virtual Machines\Windows 98\win98.vmx; Feb 08 21:38:54: vmx| DICT prefvmx.mru.suspended = C:\Documents and Settings\gedi\My Documents\My Virtual Machines\Windows 98\win98.vmx; Feb 08 21:38:54: vmx| DICT pref.currentVM = /vm/#5f7d22078c314fbf/ Feb 08 21:38:54: vmx| DICT pref.openedVM0.present = TRUE Feb 08 21:38:54: vmx| DICT pref.openedVM0.path = /vm/#5f7d22078c314fbf/ Feb 08 21:38:54: vmx| DICT pref.openedVM0.file = E:\vm\win98.vmx Feb 08 21:38:54: vmx| DICT pref.openedVM0.name = Reactos Feb 08 21:38:54: vmx| DICT pref.openedVM.maxNum = 1 Feb 08 21:38:54: vmx| DICT pref.openedVM1.present = TRUE Feb 08 21:38:54: vmx| DICT pref.openedVM1.path = /vm/#041588a3d3f91255/ Feb 08 21:38:54: vmx| DICT pref.openedVM1.file = C:\Documents and Settings\gedi\My Documents\My Virtual Machines\Windows 98\win98.vmx Feb 08 21:38:54: vmx| DICT pref.openedVM1.name = ReactOS Feb 08 21:38:54: vmx| DICT hint.powerOff = FALSE Feb 08 21:38:54: vmx| DICT pref.tip.startup = FALSE Feb 08 21:38:54: vmx| DICT pref.view.navBar = FALSE Feb 08 21:38:54: vmx| DICT hint.tools.toolsReminder = FALSE Feb 08 21:38:54: vmx| DICT hint.tools.toolsImage = FALSE Feb 08 21:38:54: vmx| DICT hint.monitorInit.mem.hostovercommit = FALSE Feb 08 21:38:54: vmx| DICT --- USER DEFAULTS Feb 08 21:38:54: vmx| DICT --- HOST DEFAULTS Feb 08 21:38:54: vmx| DICT prefvmx.useRecommendedLockedMemSize = TRUE Feb 08 21:38:54: vmx| DICT priority.grabbed = normal Feb 08 21:38:54: vmx| DICT priority.ungrabbed = normal Feb 08 21:38:54: vmx| DICT --- SITE DEFAULTS Feb 08 21:38:54: vmx| DICT prefvmx.useRecommendedLockedMemSize = TRUE Feb 08 21:38:54: vmx| DICT priority.grabbed = normal Feb 08 21:38:54: vmx| DICT priority.ungrabbed = normal Feb 08 21:38:54: vmx| DICT --- COMMAND LINE Feb 08 21:38:54: vmx| DICT gui.available = TRUE Feb 08 21:38:54: vmx| DICT --- CONFIGURATION Feb 08 21:38:54: vmx| DICT config.version = 7 Feb 08 21:38:54: vmx| DICT virtualHW.version = 3 Feb 08 21:38:54: vmx| DICT scsi0.present = TRUE Feb 08 21:38:54: vmx| DICT memsize = 232 Feb 08 21:38:54: vmx| DICT ide0:0.present = TRUE Feb 08 21:38:54: vmx| DICT ide0:0.fileName = Windows 98.vmdk Feb 08 21:38:54: vmx| DICT ide0:0.deviceType = plainDisk Feb 08 21:38:54: vmx| DICT ide1:0.present = TRUE Feb 08 21:38:54: vmx| DICT ide1:0.fileName = auto detect Feb 08 21:38:54: vmx| DICT ide1:0.deviceType = cdrom-raw Feb 08 21:38:54: vmx| DICT floppy0.present = FALSE Feb 08 21:38:54: vmx| DICT Ethernet0.present = TRUE Feb 08 21:38:54: vmx| DICT sound.present = TRUE Feb 08 21:38:54: vmx| DICT sound.fileName = -1 Feb 08 21:38:54: vmx| DICT displayName = Reactos Feb 08 21:38:54: vmx| DICT guestOS = win98 Feb 08 21:38:54: vmx| DICT priority.grabbed = normal Feb 08 21:38:54: vmx| DICT priority.ungrabbed = normal Feb 08 21:38:54: vmx| DICT powerType.powerOff = default Feb 08 21:38:54: vmx| DICT powerType.powerOn = default Feb 08 21:38:54: vmx| DICT powerType.suspend = default Feb 08 21:38:54: vmx| DICT powerType.reset = default Feb 08 21:38:54: vmx| DICT Ethernet0.addressType = generated Feb 08 21:38:54: vmx| DICT uuid.location = 56 4d f6 43 c0 7c f9 b8-8f d7 84 49 b1 3b af 3e Feb 08 21:38:54: vmx| DICT uuid.bios = 56 4d f6 43 c0 7c f9 b8-8f d7 84 49 b1 3b af 3e Feb 08 21:38:54: vmx| DICT ethernet0.generatedAddress = 00:0c:29:3b:af:3e Feb 08 21:38:54: vmx| DICT ethernet0.generatedAddressOffset = 0 Feb 08 21:38:54: vmx| DICT ide1:0.startConnected = TRUE Feb 08 21:38:54: vmx| DICT tools.remindInstall = TRUE Feb 08 21:38:54: vmx| DICT sound.virtualDev = es1371 Feb 08 21:38:54: vmx| DICT serial0.present = TRUE Feb 08 21:38:54: vmx| DICT serial0.fileType = file Feb 08 21:38:54: vmx| DICT serial0.fileName = debug.txt Feb 08 21:38:54: vmx| DICT redoLogDir = . Feb 08 21:38:54: vmx| DICT parallel0.present = FALSE Feb 08 21:38:54: vmx| DICT parallel0.fileType = file Feb 08 21:38:54: vmx| DICT parallel0.fileName = debug.txt Feb 08 21:38:54: vmx| DICT --- USER DEFAULTS Feb 08 21:38:54: vmx| DICT --- HOST DEFAULTS Feb 08 21:38:54: vmx| DICT prefvmx.useRecommendedLockedMemSize = TRUE Feb 08 21:38:54: vmx| DICT priority.grabbed = normal Feb 08 21:38:54: vmx| DICT priority.ungrabbed = normal Feb 08 21:38:54: vmx| DICT --- SITE DEFAULTS Feb 08 21:38:54: vmx| DICT prefvmx.useRecommendedLockedMemSize = TRUE Feb 08 21:38:54: vmx| DICT priority.grabbed = normal Feb 08 21:38:54: vmx| DICT priority.ungrabbed = normal Feb 08 21:38:54: vmx| DICT --- GLOBAL SETTINGS Feb 08 21:38:54: vmx| MStat: Creating Stat vm.uptime Feb 08 21:38:54: vmx| GetSystemTimeAdjustment returned unknown clockInterval 100144 Feb 08 21:38:54: vmx| LICENSE using: 'HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Workstation\License.ws.4.0' Feb 08 21:38:54: vmx| MM: Using partialmap, 59392 pages AC 0 CE 0 TM 0 Feb 08 21:38:54: vmx| STATDECLGROUP stats Root "" null Feb 08 21:38:54: vmx| WSSCAN: reserved mem (in MB) min=32 max=384 recommended=384 Feb 08 21:38:54: vmx| hostMem=512 maxAllowedAll=4096 maxAllowedVM=3600 Feb 08 21:38:54: vmx| totOverhead=16 Feb 08 21:38:54: vmx| WSSCAN: used rec mem (in MB) 384 Feb 08 21:38:54: vmx| WSSCAN: Overhead 64369 paged 13197 nonpaged Feb 08 21:38:54: vmx| WSSCAN 1 36 88889 88889 98304 130904 50 0 Feb 08 21:38:54: vmx| Mapped mainmem as pageable (offset ffbff000) Feb 08 21:38:54: vmx| CPUID after masking: version 0xf28 features 0x1febfbff extFeatures 0x0 Feb 08 21:38:54: vmx| CPU.cpuFeatures = 0x1b1fe01 Feb 08 21:38:54: vmx| APIC: IO APIC at 0xfec00000 Feb 08 21:38:54: vmx| KHZEstimate 1993531 Feb 08 21:38:54: vmx| MHZEstimate 1994 Feb 08 21:38:54: vmx| NumVCPUs 1 Feb 08 21:38:54: vmx| location-UUID is 56 4d f6 43 c0 7c f9 b8-8f d7 84 49 b1 3b af 3e Feb 08 21:38:54: vmx| TimeTracker host to guest rate conversion 32657051752596 @ 1993531000Hz -> 32657051752596 @ 1993531000Hz Feb 08 21:38:54: vmx| TimeTracker host to guest rate conversion ((x * 2147483648) >> 31) + 0 Feb 08 21:38:54: vmx| DISK: Treating disk 'Windows 98.vmdk' as persistent Feb 08 21:38:54: Floppy| Msg_Reset: Feb 08 21:38:54: Floppy| [msg.dictionary.load.statFailed] Unable to get information about file "C:\Documents and Settings\All Users\Application Data\VMware\VMware Workstation\settings.ini": The system cannot find the file specified. Feb 08 21:38:54: Floppy| ---------------------------------------- Feb 08 21:38:54: vmx| DISK: OPEN ide:0:0 'Windows 98.vmdk' persistent R[] Feb 08 21:38:54: vmx| DISKLIB-DSCPTR: Opened [0]: "Windows 98-f001.vmdk" 0 (0x2) Feb 08 21:38:54: vmx| DISKLIB-LINK : Opened 'Windows 98.vmdk' (0xa): twoGbMaxExtentFlat, 2097152 sectors / 1024 Mb. Feb 08 21:38:54: Floppy| PREF Optional preferences file not found at C:\Documents and Settings\All Users\Application Data\VMware\VMware Workstation\settings.ini. Using default values. Feb 08 21:38:54: Floppy| Msg_Reset: Feb 08 21:38:54: Floppy| [msg.dictionary.load.statFailed] Unable to get information about file "C:\Documents and Settings\gedi\Application Data\VMware\config.ini": The system cannot find the file specified. Feb 08 21:38:54: Floppy| ---------------------------------------- Feb 08 21:38:54: Floppy| PREF Optional preferences file not found at C:\Documents and Settings\gedi\Application Data\VMware\config.ini. Using default values. Feb 08 21:38:54: vmx| DISKLIB-CACHE : 'Windows 98.vmdk' : pgSz=4096 max=1048576 minRA=0 maxRA=65536 update=2000 Feb 08 21:38:54: vmx| DISKLIB-LIB : Opened "Windows 98.vmdk" (flags 0xa). Feb 08 21:38:54: vmx| DISK: OPEN 'Windows 98.vmdk' Geo (2080/16/63) BIOS Geo (0/0/0) freeSpace=3679Mb Feb 08 21:38:54: vmx| SCSI0: UNTAGGED commands will be converted to ORDER tags. Feb 08 21:38:54: vmx| MStat: Creating Stat vm.heartbeat Feb 08 21:38:54: vmx| DISK: ide0:0 : toolsVersion = 0 Feb 08 21:38:54: vmx| Msg_Hint: msg.tools.toolsReminder (not shown) Feb 08 21:38:54: vmx| TOOLS INSTALL initializing state to IDLE on power on. Feb 08 21:38:54: vmx| Display orientation is default. Feb 08 21:38:54: vmx| Display frequency is 60HZ Feb 08 21:38:54: vmx| Using unified VGA. Feb 08 21:38:54: vmx| USB: Initializing UHCI host controller Feb 08 21:38:54: vmx| USB: Initializing USB Generic backend Feb 08 21:38:54: usbEnum| VTHREAD thread 6 "usbEnum" host id 1692 started Feb 08 21:38:54: vmx| VTHREAD create thread 6 "usbEnum" Feb 08 21:38:54: vmx| VLANCE: send cluster threshold is 80, size = 2 recalcInterval is 2 ticks Feb 08 21:38:54: vmx| Ethernet0 MAC Address: 00:0c:29:3b:af:3e Feb 08 21:38:54: vmx| VMXNET: send cluster threshold is 80, size = 2 recalcInterval is 2 ticks Feb 08 21:38:54: vmx| SOUND: ES1371Win32GetDevNum: sound device -1 not found. Using default. Feb 08 21:38:54: vmx| VirtualProtect MapProtectMem(0xf10000,0x1000) returns 0x1e7 Feb 08 21:38:54: vmx| Can't read-only monitor pages from 0x00F10000 to 0x00F11000 Feb 08 21:38:54: vmx| VirtualProtect MapProtectMem(0xf12000,0x0) returns 0x57 Feb 08 21:38:54: vmx| Can't read-only monitor pages from 0x00F12000 to 0x00F12000 Feb 08 21:38:54: vmx| VMX_PowerOn: ModuleTable_PowerOn = 1 Feb 08 21:38:54: mks| VTHREAD thread 1 "mks" host id 3500 started Feb 08 21:38:54: vmx| VTHREAD create thread 1 "mks" Feb 08 21:38:54: mks| Async MKS thread is alive Feb 08 21:38:54: vcpu-0| VTHREAD thread 4 "vcpu-0" host id 2624 started Feb 08 21:38:54: vmx| VTHREAD create thread 4 "vcpu-0" Feb 08 21:38:54: mks| Attaching local console. Feb 08 21:38:54: mks| Display orientation is default. Feb 08 21:38:54: mks| Display frequency is 60HZ Feb 08 21:38:54: kbh| VTHREAD thread 7 "kbh" host id 3676 started Feb 08 21:38:54: mks| VTHREAD create thread 7 "kbh" Feb 08 21:38:54: mks| KHBKL: Unable to parse keystring at: '' Feb 08 21:38:54: mks| VTHREAD destroy thread 7 "kbh" Feb 08 21:38:54: vcpu-0| IOAPIC: unsupported version 0xff Feb 08 21:38:54: vcpu-0| Monitor initialized: Release.4.5.2build-8848 (gcc). cflags: 0x08080040.2109d430 Feb 08 21:38:54: vmx| DnD rpc already set to 1 Feb 08 21:38:54: vcpu-0| cpuFeatures = 0x1b1fe01 Feb 08 21:38:54: vcpu-0| DISK: ide0:0 : capacity=2097152 Feb 08 21:38:54: vmx| VNET: Notification enabled for Ethernet0 Feb 08 21:38:54: vmx| MACVNET: Notification Enabled for Ethernet0 Feb 08 21:38:54: vmx| Msg_Question: Feb 08 21:38:54: vmx| [msg.serial.file.open] Filename "debug.txt" that we were about to create already exists. Feb 08 21:38:54: vmx| To append new data at the end of the file, please select Append. Feb 08 21:38:54: vmx| To replace the content of the file with new data, please select Overwrite. Feb 08 21:38:54: vmx| To retry the connect operation after you have moved the file to another location, please select Retry. Feb 08 21:38:54: vmx| To cancel the connect operation, please select Cancel. Feb 08 21:38:54: vmx| ---------------------------------------- Feb 08 21:38:56: vmx| Msg_Question: msg.serial.file.open reply=1 Feb 08 21:38:56: vmx| Winnt_CDROM: Detected a CD-ROM of 'D:\' Feb 08 21:38:56: vcpu-0| sz=3015392 Feb 08 21:38:56: vcpu-0| SVGA: Registering MemSpace at 0xfa000000(0x00000000) and 0xf9000000(0x00000000) Feb 08 21:38:56: vcpu-0| PCI OPROM: Asked to map the VBIOS OPROM at 0xfe800000 (size 32768 bytes) Feb 08 21:38:56: vcpu-0| PCI OPROM: Asked to unmap the VBIOS OPROM Feb 08 21:38:56: vcpu-0| SVGA: Unregistering MemSpace at 0xfa000000(0xfa000000) and 0xf9000000(0xf9000000) Feb 08 21:38:56: vcpu-0| PCI OPROM: Asked to map the SBIOS OPROM at 0xfe800000 (size 16384 bytes) Feb 08 21:38:56: vcpu-0| PCI OPROM: Asked to unmap the SBIOS OPROM Feb 08 21:38:56: vcpu-0| PCI OPROM: Asked to map the VLANCE OPROM at 0xfe800000 (size 65536 bytes) Feb 08 21:38:56: vcpu-0| PCI OPROM: Asked to unmap the VLANCE OPROM Feb 08 21:38:56: vcpu-0| SVGA: Registering MemSpace at 0xfa000000(0xfa000000) and 0xf9000000(0xf9000000) Feb 08 21:38:56: vcpu-0| PCI OPROM: Asked to map the VBIOS OPROM at 0xfe800000 (size 32768 bytes) Feb 08 21:38:56: vcpu-0| PCI OPROM: Asked to unmap the VBIOS OPROM Feb 08 21:38:56: vcpu-0| SVGA: Unregistering MemSpace at 0xfa000000(0xfa000000) and 0xf9000000(0xf9000000) Feb 08 21:38:56: vcpu-0| SVGA: Registering IOSpace at 0x1460 (0x0000) Feb 08 21:38:56: vcpu-0| SVGA: Registering MemSpace at 0xfa000000(0xfa000000) and 0xf9000000(0xf9000000) Feb 08 21:38:56: vcpu-0| UHCI: Global Reset Feb 08 21:38:56: vcpu-0| UHCI: HCReset Feb 08 21:38:57: vcpu-0| UHCI: HCReset Feb 08 21:38:57: kbh| VTHREAD thread 7 "kbh" host id 2684 started Feb 08 21:38:57: mks| VTHREAD create thread 7 "kbh" Feb 08 21:38:57: vmx| VMXVmdbLoadUsbDevices: New set of 3 USB devices Feb 08 21:38:57: vcpu-0| AIOGNRC: Starting 1 I/O thread. Feb 08 21:38:57: IO#0| VTHREAD thread 8 "IO#0" host id 3472 started Feb 08 21:38:57: vcpu-0| VTHREAD create thread 8 "IO#0" Feb 08 21:38:57: vcpu-0| Winnt_CDROM: 'D:' Length 24 MaxTransferLength 131072 MaxPhysPages 32 Feb 08 21:38:57: vcpu-0| Winnt_CDROM: AlignMask 0x1 !AsyncEvent !TaggedQ ScanUp DMA Feb 08 21:38:58: vcpu-0| PCI OPROM: Asked to map the SBIOS OPROM at 0xfe800000 (size 16384 bytes) Feb 08 21:38:58: vcpu-0| PCI OPROM: Asked to unmap the SBIOS OPROM Feb 08 21:38:58: vcpu-0| PCI OPROM: Asked to map the VLANCE OPROM at 0xfe800000 (size 65536 bytes) Feb 08 21:38:58: vcpu-0| PCI OPROM: Asked to map the VLANCE OPROM at 0xfe800000 (size 65536 bytes) Feb 08 21:38:58: vcpu-0| PCI OPROM: Asked to unmap the VLANCE OPROM Feb 08 21:38:58: vcpu-0| VIDE: Curr CHS info cyls: 2080 heads: 16 sects: 63 lba_cap: 2097152 Feb 08 21:39:00: vcpu-0| BIOS-UUID is 56 4d f6 43 c0 7c f9 b8-8f d7 84 49 b1 3b af 3e Feb 08 21:39:14: vcpu-0| VIDE: (0x1f0) OUTB Cmd of 0x8 for non-existent drive 1 Feb 08 21:39:14: vcpu-0| VIDE: (0x1f0) OUTB Cmd of 0xec for non-existent drive 1 Feb 08 21:39:19: vcpu-0| Triple fault. Feb 08 21:39:19: vcpu-0| Msg_Hint: msg.monitorEvent.cpl0SS (shown) Feb 08 21:43:15: vmx| Stopping VCPU threads... Feb 08 21:43:15: vmx| VTHREAD destroy thread 4 "vcpu-0" Feb 08 21:43:16: vmx| VTHREAD destroy thread 1 "mks" Feb 08 21:43:16: mks| Async MKS thread is exiting Feb 08 21:43:16: vmx| TOOLS received request in VMX to set option 'enableDnD' -> '0' Feb 08 21:43:16: vmx| VTHREAD destroy thread 6 "usbEnum" Feb 08 21:43:16: vmx| Detatching local console. Feb 08 21:43:16: vmx| VTHREAD destroy thread 7 "kbh" Feb 08 21:43:16: vmx| MKS local poweroff Feb 08 21:43:16: vmx| AIOWIN32: asyncOps=1 syncOps=0 bufSize=0Kb delayed=0 fixed=0 sgOp=1 sgOn=1 Feb 08 21:43:16: IO#0| AIOGNRC: thread #0 exiting (1466) Feb 08 21:43:16: vmx| VTHREAD destroy thread 8 "IO#0" Feb 08 21:43:16: vmx| AIOGNRC: asyncOps=0 syncOps=0 maxPending=0 maxCompleted=0 Feb 08 21:43:16: vmx| AIOPowerOff Floppy Feb 08 21:43:16: Floppy| AIOSlave: Floppy exiting cleanly. Feb 08 21:43:16: Floppy| IPC_exit: disconnecting all threads Feb 08 21:43:16: Floppy| Floppy IPC closed the connection with thread VMX (00E1D048) Feb 08 21:43:16: Floppy| Floppy IPC The "VMX" thread exited cleanly. Feb 08 21:43:16: Floppy| VTHREAD thread 5 start exiting Feb 08 21:43:16: Floppy| VTHREAD thread 5 exiting, 1 left Feb 08 21:43:16: vmx| VMX IPC closed the connection with thread Floppy (007A3EA0) Feb 08 21:43:16: vmx| VTHREAD destroy thread 5 "Floppy" Feb 08 21:43:16: vmx| vmdbPipe_Streams: Couldn't read Feb 08 21:43:16: vmx| VMX idle exit Feb 08 21:43:16: vmx| Flushing VMX VMDB connections Feb 08 21:43:16: vmx| IPC_exit: disconnecting all threads Feb 08 21:43:16: vmx| VMX exit.

1 0

RE: [hbirr] 12829: - Prevent from callingPsTerminateCurrentThread from within an apc ifPsTerminateThread was already called.
by Ge van Geldorp 04 Feb '05

04 Feb '05

> From: hbirr(a)svn.reactos.com > > - Prevent from calling PsTerminateCurrentThread from within > an apc if PsTerminateThread was already called. This change prevents terminating a thread from another thread. In that case, PsTerminateOtherThread() is called, which sets up an APC and sets Thread->HasTerminated to TRUE. This will make PiTerminateThreadNormalRoutine() skip the call to PsTerminateCurrentThread(). A side effect is that a multi-threaded app will not exit on an ExitProcess() call. The thread calling ExitProcess() will terminate, but the other threads will happily continue running. This is the reason GUI console windows don't close anymore when you click their close button. Gé van Geldorp.

1 0

Re: [ros-kernel] WinQuake
by James Tabor 03 Feb '05

03 Feb '05

Magnus Olsen wrote: > Hi > NtUserChangeDisplaySettings UNIMPLEMENTED > changes that stub to return DISP_CHANGE_FAILED > and use cmd winquake -noautostretch -startwindowed > > it will not work 100% fine until the NtUserChangeDisplaySettings > are being implemnet. it is old news. That I think most people know > last time, w3seek was working on more easy way to implement > this api. it need a globa desktop pointer. last time I check > reactos did not have one. And that make it hard to implement > NtUserChangeDisplaySettings api > From, http://cvs.cosoft.org.cn/cgi-bin/viewcvs.cgi/fileshare/FreeWin/include/win3… LONG STDCALL NtUserChangeDisplaySettings( PUNICODE_STRING lpszDeviceName, LPDEVMODEW lpDevMode, HWND hwnd, DWORD dwflags, LPVOID lParam); Oh well, I guess this is from a ROS fork, James

1 0

The Build Ros on Ros lockup Problem
by James Tabor 03 Feb '05

03 Feb '05

Past to wrong list. Lockup! 1> (KERNEL32:file/file.c:734) NtOpenFile() failed c5fd00 (Status c000003a) (KERNEL32:file/file.c:734) NtOpenFile() failed c5fd00 (Status c000003a) (KERNEL32:mem/global.c:412) Memory Load: 12 (KERNEL32:mem/global.c:412) M(KERNEL32:file/file.c:734) NtOpenFile() failed 6df de0 (Status c0000034) emory Load: 12 (KERNEL32:file/file.c:734) NtOpenFile() failed fdfcc0 (Status c0000034) (KERNEL32:file/file.c:734) NtOpenFile() failed fdfcc0 (Status c0000034) 2> Open new cmd window and dumped a ps list. P PID PPID KTime UTime NAME t TID KTime UTime State WaitResson w PID Hwnd WndStile TID WndName P 4 0 1:10:08 0:00:00 ProcName: System t 12 0:00:03 0:00:00 Unknown Executive t 16 1:09:36 0:00:00 Ready Executive t 20 0:00:00 0:00:00 Unknown WrQueue t 24 0:00:00 0:00:00 Unknown WrQueue t 28 0:00:00 0:00:00 Unknown WrQueue t 32 0:00:00 0:00:00 Unknown WrQueue t 36 0:00:00 0:00:00 Unknown WrQueue t 40 0:00:00 0:00:00 Unknown WrQueue t 44 0:00:00 0:00:00 Unknown WrQueue t 48 0:00:00 0:00:00 Unknown WrQueue t 52 0:00:00 0:00:00 Unknown WrQueue t 56 0:00:00 0:00:00 Unknown WrQueue t 60 0:00:00 0:00:00 Unknown WrQueue t 64 0:00:00 0:00:00 Unknown WrQueue t 68 0:00:00 0:00:00 Unknown WrQueue t 72 0:00:00 0:00:00 Unknown WrQueue t 76 0:00:00 0:00:00 Unknown WrQueue t 80 0:00:29 0:00:00 Ready Executive t 84 0:00:00 0:00:00 Unknown Executive t 88 0:00:00 0:00:00 Unknown Executive t 92 0:00:00 0:00:00 Unknown Executive t 100 0:00:00 0:00:00 Unknown Executive t 128 0:00:00 0:00:00 Unknown Executive t 132 0:00:00 0:00:00 Unknown Executive P 104 4 0:00:00 0:00:00 ProcName: smss.exe t 108 0:00:00 0:00:00 Unknown UserReq t 112 0:00:00 0:00:00 Unknown UserReq t 116 0:00:00 0:00:00 Unknown UserReq P 136 104 0:00:59 0:00:01 ProcName: csrss.exe t 144 0:00:02 0:00:00 Unknown UserReq t 148 0:00:00 0:00:00 Unknown UserReq t 152 0:00:00 0:00:00 Unknown Executive t 156 0:00:00 0:00:00 Unknown UserReq t 168 0:00:00 0:00:00 Unknown UserReq t 172 0:00:00 0:00:00 Unknown Executive w 136 4 00000000 172 t 176 0:00:00 0:00:00 Unknown Executive w 136 8 86000000 176 t 180 0:00:00 0:00:00 Unknown Executive w 136 c 86000000 180 t 192 0:00:00 0:00:00 Unknown UserReq t 208 0:00:00 0:00:00 Unknown UserReq t 224 0:00:00 0:00:00 Unknown UserReq t 236 0:00:00 0:00:00 Unknown UserReq t 244 0:00:23 0:00:00 Unknown Executive w 136 17c 04cf0000 244 w 136 180 14ca0000 244 Command Prompt w 136 188 14ca0000 244 Command Prompt t 252 0:00:00 0:00:00 Unknown UserReq t 6252 0:00:00 0:00:00 Unknown UserReq t 80208 0:00:01 0:00:00 Unknown UserReq t 83484 0:00:00 0:00:00 Unknown UserReq t 83508 0:00:00 0:00:00 Unknown UserReq t 83520 0:00:00 0:00:00 Unknown UserReq t 83544 0:00:00 0:00:00 Unknown UserReq P 160 104 0:00:00 0:00:00 ProcName: winlogon.exe t 164 0:00:00 0:00:00 Unknown UserReq w 160 10 84000000 164 SAS P 184 160 0:00:00 0:00:00 ProcName: services.exe t 188 0:00:00 0:00:00 Unknown UserReq t 196 0:00:00 0:00:00 Unknown UserReq P 200 184 0:00:00 0:00:00 ProcName: eventlog.exe t 204 0:00:00 0:00:00 Unknown UserReq P 216 160 0:00:00 0:00:00 ProcName: userinit.exe t 220 0:00:00 0:00:00 Unknown UserReq P 228 216 0:00:37 0:00:13 ProcName: explorer.exe t 232 0:00:37 0:00:13 Unknown Executive w 228 c0 04c00000 232 w 228 cc 94000000 232 Program Manager w 228 d0 50010000 232 w 228 d4 56010340 232 w 228 d8 40000002 232 w 228 f0 96040000 232 w 228 fc 5000000b 232 Start w 228 100 50000045 232 Running Applications w 228 104 56001341 232 w 228 108 84800000 232 w 228 10c 50000000 232 w 228 110 84800003 232 w 228 114 50000000 232 w 228 118 84800003 232 w 228 11c 56000b4d 232 w 228 120 84800001 232 w 228 124 5600a249 232 w 228 134 86040000 232 Start Menu P 240 228 0:00:00 0:00:00 ProcName: cmd.exe t 248 0:00:00 0:00:00 Unknown UserReq P 6244 240 0:00:00 0:00:00 ProcName: make.EXE t 6248 0:00:00 0:00:00 Unknown UserReq P 80200 6244 0:00:01 0:00:00 ProcName: make.exe t 80204 0:00:01 0:00:00 Unknown UserReq P 83476 80200 0:00:00 0:00:00 ProcName: gcc.exe t 83480 0:00:00 0:00:00 Unknown UserReq P 83496 83476 0:00:00 0:00:00 ProcName: as.exe t 83500 0:00:00 0:00:00 Unknown UserReq P 83512 228 0:00:00 0:00:00 ProcName: cmd.exe t 83516 0:00:00 0:00:00 Unknown UserReq 3> Control - C (KERNEL32:file/file.c:734) NtOpenFile() failed 67fe20 (Status c0000034) (ntuser/timer.c:157) Unable to locate timer in message queue (toolbar.c:411:TOOLBAR_GetImageListForDrawing) bitmap for ID 0, index 1 is not v alid, number of bitmaps in imagelist: 0 (conio.c:1061) Console_Api Ctrl-C (KERNEL32:except/except.c:159) Unhand(KERNEL32:except/except.c:159) Unhandled ex ception (KERNEL32:except/except.c:160) Address: (KERNEL32:exce(KERNEL32:except/except.c:159) Unhandled exception (KERNEL32:except/except.c:160) Address: (KERNEL32:except/except.c:163) 40f46c C:\mingw\bin\make.EXE CS:EIP 1b:40f46c DS 23 ES 23 FS 3b GS 23 EAX: 00000000 EBX: (KERNEL32:misc/console.c:2967) GenerateConsoleCtrlEvent(0x0 , 0x1864) UNIMPLEMENTED! led exception (KERNEL32:except/except.c:160) Address: (KERNEL32:except/except.c:163) 7c919155 C:\ReactOS\system32\ntdll.dll CS:EIP 1b:7c919155 DS 23 ES 23 FS 3b GS 23 pt/except.c:163) 40f46c C:\mingw\bin\make.exe CS:EIP 1b:40f46c DS 23 ES 23 FS 3b GS 23 EAX: 00000000 EBX: 008b3730 ECX: 00000001 EDX: 00000000 EBP: 0074f128 ESI: 00879a58 ESP: 0074f0f0 EDI: 00879a58 EFLAGS: 008c61b0 ECX: 00000001 EDX: 00000000 EBP: 0074f3f8 ESI: 0088b0b8 ESP: 0074f3c0 EDI: 0088b0b8 EFLAGS: 00010206 (KERNEL32:except/except.c:166) Frames: EAX: 00d70000 EBX: 00c5fef0 ECX: 7c91f0e8C:\mingw\bin\make.EXE EDX: 7ffde000 EBP: 00c5fdc8 ESI: 00c5fec0 ESP: 00c5fdc0 EDI: 00000000 EFLAGS: 00010206 (KERNEL32:except/except.c:166) Frames: (KERNEL32:except/except.c:174) 7c91a1bb C:00010202 (KERNEL32:except/except.c:166) Frames: (KERNEL32:except/except.c:174) 41bcd6 C:\mingw\bin\make.exe (KERNEL32:except/except.c:174) 41af2a C:\mingw\bin\make.exe (KERNEL32:except/except.c:174) 41c8ef (KERNEL32:except/except.c:174) 41af2a C:\mingw\bin\make.EXE (KERNEL32:except/except.c:174) 41c8ef C:\mingw\bin\make.EXE (KERNEL32:except/except.c:174) 41c161 C:\mingw\bin\make.EXE (KERNEL32:except/except.\ReactOS\system32\ntdll.dll (KERNEL32:except/except.c:174) 7800719a C:\ReactOS\system32\msvcrt.dll (KERNEL32:except/except.c:174) 7801ea62 C:\ReactOS\system32\msvcrt.dll (KERNEL32:except/except.c:174) 7800399a C:\C:\mingw\bin\make.exe (KERNEL32:except/except.c:174) 41c161 C:\mingw\bin\make.exe (KERNEL32:except/except.c:174) 41af2a C:\mingw\bin\make.exe (KERNEL32:except/except.c:174) 41c8ef C:\mingw\bin\make.exe (KERc:174) 41af2a C:\mingw\bin\make.EXE (KERNEL32:except/except.c:174) 41abe0 C:\mingw\bin\make.EXE (KERNEL32:except/except.c:174) 412e0a C:\mingw\bin\make.EXE (KERNEL32:except/except.c:174) 401189 C:\minReactOS\system32\msvcrt.dll (KERNEL32:except/except.c:174) 7800612b C:\ReactOS\system32\msvcrt.dll (KERNEL32:except/except.c:174) 413af6 C:\mingw\bin\gcc.exe (KERNEL32:except/except.c:174) 406af9 C:\mingw\binNEL32:except/except.c:1 74) 41c161 C:\mingw\bin\make.exe (KERNEL32:except/except.c:174) 41af2a C:\mingw\bin\make.exe (KERNEL32:except/except.c:174) 41c8ef C:\mingw\bin\make.exe (KERNEL32:except/except.c:174) gw\bin\make.EXE (KERNEL32:except/except.c:174) 401018 C:\mingw\bin\make.EXE (KERNEL32:except/except.c:174) 7c83257c C:\ReactOS\system32\kernel32.dll \gcc.exe (KERNEL32:except/except.c:174) 40b7e6 C:\mingw\bin\gcc.exe (KERNEL32:except/except.c:174) 40fa9f C: 41c161 C:\mingw\bin\make.e xe (KERNEL32:except/except.c:174) 41af2a C:\mingw\bin\make.exe (KERNEL32:except/except.c:174) 41c8ef C:\mingw\bin\make.exe (KERNEL32:except/except.c:174) 41c161 C:\mingw\bin\\mingw\bin\gcc.exe (KERNEL32:except/except.c:174) 40123b C:\mingw\bin\gcc.exe (KERNEL32:except/except.c:174) 401268 C:\mingw\bin\gcc.exe (KERNEL32:except/except.c:make.exe (KERNEL32:except/except.c:174) 41af2a C:\mingw\bin\make.exe (KERNEL32:except/except.c:174) 41abe0 C:\mingw\bin\make.exe (KERNEL32:except/except.c:174) 412e0a C:\mingw\bin\make.exe (KERNEL32:excep174) 7c83257c C:\ReactOS\system32\KERNEL32.dll t/except.c:174) 401189 C:\mingw\bin\make.exe (KERNEL32:except/except.c:174) 401018 C:\mingw\bin\make.exe (KERNEL32:except/except.c:174) 7c83257c C:\ReactOS\system32\kernel32.dll 4> Exit at cmd line, just return a lf cr. 5> The only thing left was this, P 83496 83476 0:00:00 0:00:00 ProcName: as.exe t 83500 0:00:00 0:00:00 Unknown UserReq 6> Mouse select X to close the cmd window; (KERNEL32:except/except.c:159) Unhandled exception (KERNEL32:except/except.c:160) Address: (KERNEL32:except/except.c:163) 7c90b7b3 C:\ReactOS\system32\ntdll.dll CS:EIP 1b:7c90b7b3 DS 23 ES 23 FS 3b GS 23 EAX: 00000000 EBX: 00000000 ECX: 7c83d700 EDX: 00000024 EBP: 00d6ff18 ESI: 00000000 ESP: 00d6fea0 EDI: 00000000 EFLAGS: 00010216 (KERNEL32:except/except.c:166) Frames: (KERNEL32:except/except.c:174) 7c90b4b0 C:\ReactOS\system32\ntdll.dll (KERNEL32:except/except.c:174) 7c8063b2 C:\ReactOS\system32\KERNEL32.dll (KERNEL32:except/except.c:174) 7c8302a0 C:\ReactOS\system32\KERNEL32.dll Window did not close BTW. Just sits there, James

1 0

WinQuake
by James Tabor 03 Feb '05

03 Feb '05

Post to wrong list. Start WinQuake, no prob; (objects/color.c:317) NtGdiRealizePalette is unimplemented (objects/gdiobj.c:866) Attempted to lock object 0x0 that is deleted! Frames: <win32k.sys: 47c2d> <win32k.sys: 3d159> <ntoskrnl.exe: 3b4b> <7FFE0304> (ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED (ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED (ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED (ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED (ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED (ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED (ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED (ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED (ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED (ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED (ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED (ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED (ntuser/stubs.c:112) WIN32K: NtUserChangeDisplaySettings UNIMPLEMENTED (mci.c:536:MCI_LoadMciDriver) Couldn't load driver for type CDAUDIO. If you don't have a windows installation accessible from Wine, you perhaps forgot to create a [mci] section in system.ini Freeing page with rmap entries. But in the game the system goes down, no reboot, just shutdown! KeBugCheck at mm/freelist.c:719 Page fault at high IRQL was 2 Bug detected (code 0 param 0 0 0 0) The bug code is undefined. Please use an existing code instead. Frames: <ntoskrnl.exe: cb0c> <ntoskrnl.exe: cb2c> <ntoskrnl.exe: 5ae96> <ntoskrnl.exe: 570f2> <ntoskrnl.exe: 16975> <ntoskrnl.exe: 5cce7> <ntoskrnl.exe: 169b5> <ntoskrnl.exe: 16dcc> <ntoskrnl.exe: 17324> <ntoskrnl.exe: 3a30> Wow! James

1 0

RE: [ros-dev] Proposal to change .sym files
by Murphy, Ged (Bolton) 03 Feb '05

03 Feb '05

Ge van Geldorp wrote: > If symbolic info was present in file.nostrip.ext (i.e. it was compiled with > -g, which at present implies DBG := 1), then it will also be present in > file.ext. So, the backtrace on e.g. BSODs should print the function > name/source file/source line in addition to the address. Which means we > won't have to use addr2line very often. If there was no symbolic info in > file.nostrip.ext, addr2line wouldn't be of help anyway. I like this idea. Me, Alex and Steven were discussing something similar the other day in IRC. I never expected things to move so fast :) Ged ************************************************************************ 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)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> 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

1 0

Proposal to change .sym files
by Ge van Geldorp 03 Feb '05

03 Feb '05

In anticipation of doing some work on performance issues, I've been experimenting with our kernel profiler the last few days. For those who don't know, you can activate the profiler by including the /PROFILE option on the command line. On each timer interrupt the current EIP will be saved, after 30 sec a background task will convert the saved EIPs to function name/file name, count how often each function name occurs and write the results to a file %system_root%\profiler.log. There are 100 timer ticks per second, a 30 sec measuring interval will therefore generate 3000 EIPs. This works very nice, but I'm running into one problem on my 300MHz test machine: conversion of the EIPs to function name by the background thread takes about 60 sec. Almost all of that time is spent looking up the correct .stabs entry from the info in the .sym file. This is done using a linear search. Since there can be 100000 .stabs entries in a .sym file, going through these for each of the 3000 measurements can mean 300000000 compares. Even worse, two passes are made through the .stabs list for each measurement, one to find the function name and one to find the file name. No wonder this takes 60 sec. So, we need to improve the search. I've done some simulations, and when I use a binary search instead of a linear search, the performance is dramatically better. Time required to convert all measurements drops from 60 sec to 0.06 sec, a 1000 fold improvement. To be able to use a binary search, the information in the .sym file needs to be sorted and uniform (each element contains the same type of data) which it currently isn't. We have .stabs entries defining a function (N_FUN), source line (N_SLINE) and source file (N_SO). Currently, we only use the .sym files to convert an address to function name/file name/source line, not the other way around (no function name to address for example). I'd like to drop using the .stab format in the .sym files and change to the following format: +----------+ |header | +----------+ |symentries| +----------+ |strings | +----------+ The header would just contain the start location and number of symentries plus start location and total size of the strings. Each symentry would have the following info: typedef struct tagSYM_ENTRY { ULONG_PTR Address; ULONG FunctionOffset; ULONG FileOffset; ULONG SourceLine; } SYM_ENTRY, *PSYM_ENTRY; where Address is an address relative to the beginning of the module, FunctionOffset and FileOffset are offsets from the beginning of the strings section and SourceLine contains the source line number. The symentries are sorted by Address (done by rsym). Each Address would only appear once, and information would be made as complete as possible (e.g. when creating the symentries from the .stabs in the .nostrip.exe file each FunctionOffset would be set to point to the function name from the most recently encountered N_FUN .stab). This will allow us to retrieve all 3 pieces of information (function name, file name and source line) by doing just a single binary search. Comments, thoughts, objections? Gé van Geldorp.

7 20

gcc/msvc int64 suffix/LARGE_INTEGER portability macros
by Gunnar Dalsnes 02 Feb '05

02 Feb '05

Suggested gcc/msvc portability macros: #if defined(_MSC_VER) #define MK_INT64(a) (a) #define MK_UINT64(a) (a) __inline LARGE_INTEGER MK_LARGE_INTEGER(__int64 i) { LARGE_INTEGER li; li.QuadPart = i; return li; } #define LARGE_INTEGER_NULL MK_LARGE_INTEGER(0) #elif defined (__GNUC__) #define MK_INT64(a) (a##LL) #define MK_UINT64(a) (a##ULL) #define MK_LARGE_INTEGER(a) ((LARGE_INTEGER)(LONGLONG)a) #define LARGE_INTEGER_NULL ((LARGE_INTEGER)(LONGLONG)0LL) #else #error Unknown compiler for LARGE_INTEGER/int64 macros #endif example: LARGE_INTEGER test1(LARGE_INTEGER arg) { return MK_LARGE_INTEGER(arg.QuadPart+3); } LARGE_INTEGER test2() { LARGE_INTEGER a = LARGE_INTEGER_NULL; a.QuadPart += test1(LARGE_INTEGER_NULL).QuadPart; a.QuadPart += MK_INT64(1152921504606846975); return LARGE_INTEGER_NULL; } What do you think? Gunnar

4 4

ReactOS DOS subsystem
by AzeemArif 02 Feb '05

02 Feb '05

Hello ROS-Devs, I've been sharing some thoughts about DOS subsystem on ReactOS forum. I am pasting my last post (http://reactos.com/forum/viewtopic.php?p=2864#2864 ) <http://reactos.com/forum/viewtopic.php?p=2864#2864> here for your comments ======================================================== hello, I am back with my silly posts Smile But this time, after seriously reading and experimenting with FreeDos and DosEmu code. As many people suggested FreeDOS as an option to run as ReactOS subsystem, I concentrated more on FreeDOS. Something I came to know are 1) We need ReactOS DOS/Win16 subsystem so that we can run 16bit DOS applications on ReactOS. 2) FreeDOS itself is 16bit system 3) Compiling FreeDOS code with 32bit compiler is so difficult that it gave birth to a new project FreeDOS-32 (I tried compiling FreeDOS code with MinGW with no success) 4) FreeDOS-32 is in its infancy. Currently it can't even run simple DOS applications 5) DOSEmu is really slow Please give your valuable suggestions. AcetoliNe: I agree with your last post. ===================================================================== ~AzeemArif (ReactOS IRC channel - "azar")

2 2

ReactOS DOS subsystem
by AzeemArif 02 Feb '05

02 Feb '05

Hello ROS-Devs, I've been sharing some thoughts about DOS subsystem on ReactOS forum. I am pasting my last post (http://reactos.com/forum/viewtopic.php?p=2864#2864 ) <http://reactos.com/forum/viewtopic.php?p=2864#2864> here for your comments ======================================================== hello, I am back with my silly posts Smile But this time, after seriously reading and experimenting with FreeDos and DosEmu code. As many people suggested FreeDOS as an option to run as ReactOS subsystem, I concentrated more on FreeDOS. Something I came to know are 1) We need ReactOS DOS/Win16 subsystem so that we can run 16bit DOS applications on ReactOS. 2) FreeDOS itself is 16bit system 3) Compiling FreeDOS code with 32bit compiler is so difficult that it gave birth to a new project FreeDOS-32 (I tried compiling FreeDOS code with MinGW with no success) 4) FreeDOS-32 is in its infancy. Currently it can't even run simple DOS applications 5) DOSEmu is really slow Please give your valuable suggestions. AcetoliNe: I agree with your last post. ===================================================================== ~AzeemArif (ReactOS IRC channel - "azar")

1 0

RE: [ros-dev] msvcrt/crtdll "merge"
by Waldo Alvarez Cañizares 01 Feb '05

01 Feb '05

Hi Gunnar: >And about the strlen=ntdll.strlen stuff. Forwarded functions doesnt show >up as imported because they arent really imported, so this is normal. I think that it is not normal. The better way should be to really forward them, this is just half baked stuff. If you are not going to forward it, I think that it would be better to not declare them as such because that can cause confusion. >Dont understand what XP's ntdll exporting "WindowsCE" functions has to >do with anything? Was just a comment about ntdll, they are exported and nothing is mentioned in msdn. I said that because I think ntdll is very close to the runtime. Best Regards Waldo

2 1

RE: [ros-diffs] [jimtabor] 13373: Remove building of Advpack for now.
by Casper Hornstrup 01 Feb '05

01 Feb '05

What is the purpose of this regression? Also, this broke "make bootcd" Casper ________________________________ From: ros-diffs-bounces(a)reactos.com [mailto:ros-diffs-bounces@reactos.com] On Behalf Of jimtabor(a)svn.reactos.com Sent: 1. februar 2005 00:34 To: ros-diffs(a)reactos.com Subject: [ros-diffs] [jimtabor] 13373: Remove building of Advpack for now. Remove building of Advpack for now. Modified: trunk/reactos/Makefile ________________________________ Modified: trunk/reactos/Makefile --- trunk/reactos/Makefile 2005-01-31 22:13:43 UTC (rev 13372) +++ trunk/reactos/Makefile 2005-01-31 23:33:34 UTC (rev 13373) @@ -54,8 +54,8 @@ DLLS_SHELLEXT = shellext # User mode libraries -# libpcap packet epsapi -DLLS = acledit aclui advapi32 advpack cabinet cards comctl32 crtdll comdlg32 d3d8thk dbghelp expat fmifs freetype \ +# advpack libpcap packet epsapi +DLLS = acledit aclui advapi32 cabinet cards comctl32 crtdll comdlg32 d3d8thk dbghelp expat fmifs freetype \ gdi32 gdiplus glu32 hid imagehlp imm32 iphlpapi kernel32 lzexpand mesa32 midimap mmdrv mpr msacm msafd \ msgina msi msimg32 msvcrt20 msvideo mswsock netapi32 ntdll ole32 oleaut32 oledlg olepro32 opengl32 \ packet psapi riched20 richedit rpcrt4 samlib secur32 setupapi shell32 shlwapi snmpapi syssetup twain \

2 1

RE: [ros-dev] ACPI status
by PETREOLLE Sylvain 31 Jan '05

31 Jan '05

It works here, computer is put into low power state everytime you click on logoff. Usurp (aka Sylvain PETREOLLE) Service de Production & d'Exploitation Informatique GEFCO - #DMIT/DATO/PSI/PEI Mail : <mailto:exploit@gefco.fr> Tel : 01.49.05.29.29 -----Message d'origine----- De : Gge [mailto:gerard.gatineau@laposte.net] Envoyé : vendredi 28 janvier 2005 07:59 À : ReactOS Development List Objet : [ros-dev] ACPI status I built Ros with ACPI=1 but the feature is not working (in real hardware) as the computer does not go into low power state . At boot the debug messages displayed are : DriverBase for acpi.sys : 9ce1300 Advanced Configuration and Power Interface Bus Driver ACPI: System firmware supports: +------------------------------------------------------------ | Sx states: +S0 +S1 -S2 -S3 +S4 +S5 +------------------------------------------------------------ What is the status of the ACPI feature ? Is it supported actually ? Best regards Gerard _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev ---------------------------------------------------------------------------- Ce message ainsi que toutes pièces jointes (le "message") sont confidentiels et sont exclusivement destinés à l'usage de la personne à laquelle ils sont adressés. Tout point de vue ou toute opinion contenus dans ce message expriment la pensée personnelle de leur auteur et ne représentent pas nécessairement la position des sociétés du Groupe GEFCO. Si vous n'êtes pas la personne à laquelle ce message est destiné, veuillez noter que vous avez reçu cet e-mail par erreur et qu'il vous est strictement interdit d'utiliser, de diffuser, de transférer, d'imprimer ou de copier ce message. Si vous avez reçu ce message par erreur, merci de contacter la personne qui vous l'a adressé et de l'effacer immédiatement. Les sociétés du Groupe GEFCO déclinent toute responsabilité en cas d'altération, de modification, d'édition, de diffusion sans autorisation de ce message ou en cas d'affection de ce message par un virus. This message and any attachments (the "message") are confidential and intended solely for the use of the individual to whom they are addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the GEFCO Group of Companies. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this message is strictly prohibited. If you have received this message in error please contact the sender and delete the message immediately. The GEFCO Group of Companies shall not be liable for the message if altered, changed, falsified, edited, diffused without authorization or affected by any virus. ----------------------------------------------------------------------------

1 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