Ros-dev November 2005

ros-dev@reactos.org

64 participants
176 discussions

by James Tabor

Hi all! This is the hivesys.inf PCNet section. I copied fetnd5a.sys to pcnet.sys. I can query network properties w/o a crash! All I get is IPHLPAPI.dll need more work and GetAdapterInfo did not return the expected data. Bus 0, device 18, function 0, Ven 1106/Dev 3065/class 0200. Start->Settings->Settings Menu->Network Properties Select VT6102->Properties, get the VIA PCNet Status Menu, select Properties, get the VIA PCNet Pro~ Menu, select Internet Protocol (TCP/IP), select Properties, get the Error menu. Wow! Did not crash! Need to check if I'm on the right track here! Thanks, James ; ReactOS PCNet NIC driver ; To use the AMD supplied driver change the driver name to pcntn5m.sys ; HKLM,"SYSTEM\CurrentControlSet\Services\PCNet","ErrorControl",0x00010001,0x00000000 HKLM,"SYSTEM\CurrentControlSet\Services\PCNet","Group",0x00000000,"NDIS" HKLM,"SYSTEM\CurrentControlSet\Services\PCNet","ImagePath",0x00020000,"system32\drivers\pcnet.sys" HKLM,"SYSTEM\CurrentControlSet\Services\PCNet","Start",0x00010001,0x00000003 HKLM,"SYSTEM\CurrentControlSet\Services\PCNet","Type",0x00010001,0x00000001 HKLM,"SYSTEM\CurrentControlSet\Services\PCNet\Enum","0",0x00000000,"PCI\VEN_1106&DEV_3065\0000" HKLM,"SYSTEM\CurrentControlSet\Services\PCNet\Enum","Count",0x00010001,0x00000001 HKLM,"SYSTEM\CurrentControlSet\Services\PCNet\Enum","NextInstance",0x00010001,0x00000001 HKLM,"SYSTEM\CurrentControlSet\Enum\PCI\VEN_1106&DEV_3065&SUBSYS_01021106&REV_10\0000","Service",0x00000000,"PCNet" HKLM,"SYSTEM\CurrentControlSet\Enum\PCI\VEN_1106&DEV_3065&SUBSYS_01021106&REV_10\0000","Class",0x00000000,"Net" HKLM,"SYSTEM\CurrentControlSet\Enum\PCI\VEN_1106&DEV_3065&SUBSYS_01021106&REV_10\0000","ClassGUID",0x00000000,"{4D36E972-E325-11CE-BFC1-08002BE10318}" HKLM,"SYSTEM\CurrentControlSet\Enum\PCI\VEN_1106&DEV_3065&SUBSYS_01021106&REV_10\0000","Driver",0x00000000,"{4D36E972-E325-11CE-BFC1-08002BE10318}\0000" ; Configuration Entries for the PCNet Adapter HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","Characteristics",0x00010001,0x00000000 HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","DriverDesc",0x00000000,"VT6102" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","ProviderName",0x00000000,"VIA Tech" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","NetCfgInstanceId",0x00000000,"{RANDOMCFGGUIDFOR_PCNET1}" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000\Linkage","Export",0x00000000,"\Device\PCNet1" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000\Linkage","RootDevice",0x00000000,"PCNet1" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000\Linkage","UpperBind",0x00000000,"Tcpip" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","BUS_TO_SCAN",0x00000000,"ALL" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","BUSTIMER",0x00000000,"0" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","BUSTYPE",0x00000000,"5" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","EXTPHY",0x00000000,"0" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","FDUP",0x00000000,"0" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","LED0",0x00000000,"10000" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","LED1",0x00000000,"10000" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","LED2",0x00000000,"10000" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","LED3",0x00000000,"10000" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","MPMODE",0x00000000,"0" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","TP",0x00000000,"1" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","AdapterCFID",0x00000000,"811929862" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","AdapterType",0x00000000,"5" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","SlotNumber",0x00000000,"8" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","BusNumber",0x00000000,"0" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","FunctionNumber",0x00000000,"0" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","EarlyReceive",0x00000000,"0" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","EarlyTransmit",0x00000000,"0" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","BurstLength",0x00000000,"1" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","ReceiveBurstIndicate",0x00000000,"64" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","ReceiveBuffers",0x00000000,"64" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","TransmitBuffers",0x00000000,"32" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","ReceiveThreshold",0x00000000,"0" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","TransmitThreshold",0x00000000,"0" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","MapRegisters",0x00000000,"32" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","ConnectionType",0x00000000,"0" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","ValidatePacketLen",0x00000000,"1" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","IPXSPXAutoFrame",0x00000000,"0" HKLM,"SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\{RANDOMCFGGUIDFOR_PCNET1}",,0x00000000,"Network Adapters" HKLM,"SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\{RANDOMCFGGUIDFOR_PCNET1}\Connection","Name",0x00000000,"VIA PCNet" HKLM,"SYSTEM\CurrentControlSet\Services\PCNet1\Parameters\Tcpip","DefaultGateway",0x00010000,"10.65.145.1" HKLM,"SYSTEM\CurrentControlSet\Services\PCNet1\Parameters\Tcpip","IPAddress",0x00010000,"10.65.145.79" HKLM,"SYSTEM\CurrentControlSet\Services\PCNet1\Parameters\Tcpip","SubnetMask",0x00010000,"255.255.255.0"

18 years, 7 months

RE: Ros-dev Digest, Vol 14, Issue 25

by Lucio Diaz

David Hinz wrote: Hey guys, when I just translated format, I stunbled over one thing: What if somebody changed the content of a string after I translated it? After some minutes, I had a easy solution for that problem: The En.rc gets a little line in it's head-comment with a revision number. Each time somebody changes or adds a string in the En.rc, he sets the revision number +1 and so all translators have an easy to control indicator, if they need to translate something or not. But I think one thing should be clear, if there just has been corrected a spelling mistake and not something important, the revision number won't be touched. Now some example headers: in the EN.rc: /* * Moved all hardcoded strings to En.rc. * By Magnus Olsen 2005 * * Revision: 1 */ in my De.rc: /* * Moved all hardcoded strings to En.rc. * By Magnus Olsen 2005 * First German Translation by David Hinz 20051010 * * Translated Revision 1 of En.rc */ This is just an idea, but I think this could save a lot of work on bigger applications than format... Greets, David Hinz --------------------------------------- I agree, in fact i am working in a program to manage translation in reactos, i am using Delphi 2.0 but as i am not much skilled (long time since i used pascal) and my time is on the limit it is going slowly but it should work as follow: Part 1: - You select your language - You select the working directory of reactos source. - The program scans all files for en.rc files and list their directories (as their names are all the same). - With each file the program check a text file with a list of en.rc files, and if it is not there it adds it, and it is shown in the GUI as highlighted (pending translation). - If the file is found in the list, it check if translating language file is current--> if it is not current then the file is highlighted (pending translation). - If the file is found in the list, and found a translation file current--> the file is listed but not highlighted. - It does with all rc files till no more rc files in the directory. Part 2: - On clicking in a file in the listbox (highlighted or not) it will be shown in an Richtext edit panel and besides another panel with the material already translated (if there is any language related file already done), if not, the english text will be shown with the "probable translatable" areas highligthed (those between ""). -A save button, that will save the changes in the second panel automatically into the right directory in a language working copy. What do you think? ______________________________________________ Renovamos el Correo Yahoo! Nuevos servicios, más seguridad http://correo.yahoo.es

18 years, 8 months

UsbView with Overflows

by James Tabor

Hi, Running usbview.exe, killed it with ctm. It fills up memory with threads. Start of Usbview, (lib/shell32/shlview.c:1517) LVN_KEYDOWN key=0x0000000d MainFrameBase::OpenShellFolders(): parent_pidl=C:\Documents and Settings\Adminis trator.REACTOS\Desktop (lib/shell32/shlexec.c:1060) flags ignored: 0x0000000c (lib/rtl/env.c:570) Return STATUS_VARIABLE_NOT_FOUND: PROMPT FIXME: CopyImage doesn't support IMAGE_ICON correctly! (lib/ntdll/ldr/utils.c:1190) LdrGetExportByName(): failed to find mxdMessage (lib/ntdll/ldr/utils.c:2015) Failed to create or open dll section of 'msacm.drv' (Status c0000135) (lib/ntdll/ldr/utils.c:2015) Failed to create or open dll section of 'midimap.dr v' (Status c0000135) (lib/rpcrt4/ndr_marshall.c:499) sized string format=68 (lib/rpcrt4/ndr_marshall.c:446) sized string format=68 (lib/rpcrt4/ndr_marshall.c:463) buffer overflow 978 bytes (lib/rpcrt4/ndr_marshall.c:563) sized string format=68 (lib/rpcrt4/ndr_marshall.c:1853) buffer overflow 2556 byte <Snip .. ..> (lib/rpcrt4/ndr_marshall.c:563) sized string format=68 (lib/rpcrt4/ndr_marshall.c:1853) buffer overflow 2580 bytes (lib/rpcrt4/ndr_marshall.c:499) sized string format=68 (lib/rpcrt4/ndr_marshall.c:446) sized string format=68 (lib/rpcrt4/ndr_marshall.c:463) buffer overflow 923 bytes (lib/rpcrt4/ndr_marshall.c:563) sized string format=68 (lib/rpcrt4/ndr_marshall.c:1853) buffer overflow 2580 bytes <Killed by Ctm> (subsys/win32k/ntuser/window.c:581) thread cleanup: while destroy wnds, wnd=0x8d 9a30dc (subsys/win32k/objects/gdiobj.c:585) Attempted to free global gdi handle 0x21080 268, caller needs to get ownership first!!! (subsys/win32k/objects/gdiobj.c:585) Attempted to free global gdi ha(lib/rpcrt4/ ndr_marshall.c:499) sized string format=68 (lib/rpcrt4/ndr_marshall.c:446) sized string format=68 (lindle 0xa0802ed, caller needs to get ownership first!!! b/rpcrt4/ndr_marshall.c:463) buffer overflow 923 bytes

19 years, 1 month

Drivers.exe Hard System Fault

by James Tabor

Hi, I was testing with drivers.exe from the W2K DDK. It worked once before about a month ago. Now it crashes the system w/o any display at all. WinObj.exe works fine. Revision: 19187 Node Kind: directory Schedule: normal Last Changed Author: hbirr Last Changed Rev: 19187 Last Changed Date: 2005-11-12 23:45:32 +0000 (Sat, 12 Nov 2005) Properties Last Updated: 2005-10-01 16:19:41 +0000 (Sat, 01 Oct 2005) (subsys/win32k/objects/gdiobj.c:585) Attempted to free global gdi handle 0x13080 1fb, caller needs to get ownership first!!! lib/rtl/unicode.c:916: Pagable code called at IRQL > APC_LEVEL (2) KeBugCheck at ntoskrnl/rtl/libsupp.c:139 (ntoskrnl/mm/mm.c:275) Page fault at high IRQL was 2, address c5b62 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. Technical information: *** STOP: 0x00000000 (0x00000000,0x00000000,0x00000000,0x00000000) Frames: <ntoskrnl.exe:2585 (ntoskrnl/ke/bug.c:479 (KeBugCheckEx))> <ntoskrnl.exe:25bd (ntoskrnl/ke/bug.c:500 (KeBugCheck))> <ntoskrnl.exe:8d20d (ntoskrnl/rtl/libsupp.c:139 (CHECK_PAGED_CODE_RTL))> <ntoskrnl.exe:b9bda (lib/rtl/unicode.c:918 (RtlUnicodeStringToAnsiString))> <ntoskrnl.exe:554cd (ntoskrnl/ldr/loader.c:435 (LdrpQueryModuleInformation))> <ntoskrnl.exe:27f6a (ntoskrnl/ex/sysinfo.c:803 (QSISystemModuleInformation))> <ntoskrnl.exe:28e5d (ntoskrnl/ex/sysinfo.c:1558 (NtQuerySystemInformation))> <ntoskrnl.exe:9c57c ({standard input}:373 (KiSystemService))> <drivers.EXE:146f> Entered debugger on embedded INT3 at 0x0008:0x800b2376. kdb:> bt Eip: <ntoskrnl.exe:b2377 ({standard input}:28 (DbgBreakPointWithStatus))> Frames: <ntoskrnl.exe:2585 (ntoskrnl/ke/bug.c:479 (KeBugCheckEx))> <ntoskrnl.exe:25bd (ntoskrnl/ke/bug.c:500 (KeBugCheck))> <ntoskrnl.exe:8d20d (ntoskrnl/rtl/libsupp.c:139 (CHECK_PAGED_CODE_RTL))> <ntoskrnl.exe:b9bda (lib/rtl/unicode.c:918 (RtlUnicodeStringToAnsiString))> <ntoskrnl.exe:554cd (ntoskrnl/ldr/loader.c:435 (LdrpQueryModuleInformation))> <ntoskrnl.exe:27f6a (ntoskrnl/ex/sysinfo.c:803 (QSISystemModuleInformation))> <ntoskrnl.exe:28e5d (ntoskrnl/ex/sysinfo.c:1558 (NtQuerySystemInformation))> <ntoskrnl.exe:9c57c ({standard input}:373 (KiSystemService))> <drivers.EXE:146f> <drivers.EXE:170f> <kernel32.dll:31635 (lib/kernel32/process/create.c:68 (BaseProcessStartup))> <00000000> kdb:>

19 years, 1 month

[Vote] Top-level source header

by Casper Hornstrup

The discussion is located here: http://www.reactos.org/archives/public/ros-dev/2005-October/005671.html I will create a vote with the options below. Proposal A from Ged Murphy: /* * ReactOS <place holder> * Copyright (C) 2005 ReactOS Foundation * * LICENCE: <place holder> * PROJECT: <place holder> * FILE: <place holder> * PURPOSE: <place holder> * PROGRAMMERS: <place holder> * REVISIONS: * <place holder> * */ Proposal B from Alex Ionescu: /* * PROJECT: ReactOS Kernel * LICENSE: GPL - See COPYING in the top level directory * FILE: ntoskrnl/ex/mutant.c * PURPOSE: section of the kernel * PROGRAMMERS: Alex Ionescu (alex at reactos.org) * David Welch (welch at cwcom.net) */ Proposal C from Casper Hornstrup/Gé van Geldorp: /* * PROJECT: ReactOS Kernel * LICENSE: GPL - See COPYING in the top level directory * COPYRIGHT: Copyright 2004-2005 John Doe * Copyright 2005 Jane Doe */

19 years, 1 month

Symbolic Links

by David Hinz

I was just wondering, if we could implement symbolic links in ReactOS. As I don't want to add this feature to every filesystem that doesn't support symbolic links, I thought about another way. I had two ideas: 1. Use a file for this, comparable to files like HOSTS etc 2. Use the registry The more I thought about this, I liked my second idea more than my first and noticed what a great thing the registry is. We could simply add keys like HKEY_LOCAL_MACHINE\SYSTEM\symlinks\C:\My Files and set the target directory as it's value. It's very easy to search for such keys, so it shouldn't be that hard to implement it into the IFS-driver. More complicated would be the implementation into explorer and the creation of a commandline utility. A second feature could be to create such links for every user, so that every user could use C:\My Files\... which would be linked to C:\Documents and Settings\Username\My Files\... and he wouldn't even notice. I think that would be a nice feature and I would really like to implement this, but I'm afraid I can't do this alone, as I don't have much experience and I'm just beginning to learn C++ and asm, so it would be nice, if someone of you who likes this idea could help me with this. Greets, David Hinz

19 years, 1 month

[Fwd: [ros-svn] CC: Eric/IDL Guys - MIDL Compatibility]

by Alex Ionescu

19 years, 1 month

rbuild broken?

by Hartmut Birr

Hi, all drivers do export its internal functions. - Hartmut Exp Addr Hint Ord Export Name by vfatfs.sys - Wed Nov 30 23:05:54 2005 -------- ---- ----- --------------------------------------------------------- 000059FC 0 1 ClusterToSector 000053DE 1 2 CountAvailableClusters 00009DD0 2 3 DriverEntry@8 0000514B 3 4 FAT12FindAndMarkAvailableCluster 00004F59 4 5 FAT12GetNextCluster 000056DF 5 6 FAT12WriteCluster 00004FF9 6 7 FAT16FindAndMarkAvailableCluster 00004E9A 7 8 FAT16GetNextCluster 00004C5D 8 9 FAT16OffsetToCluster 000057C8 9 10 FAT16WriteCluster 0000527D A 11 FAT32FindAndMarkAvailableCluster 00004DD4 B 12 FAT32GetNextCluster 00004AE0 C 13 FAT32OffsetToCluster 000058A5 D 14 FAT32WriteCluster 00003137 E 15 FATGetNextDirEntry 000035B3 F 16 FATXGetNextDirEntry 0000E000 10 17 FileInformationClassNames 000019A7 11 18 FindFile 000024B0 12 19 FsdDosDateTimeToSystemTime 0000254D 13 20 FsdSystemTimeToDosDateTime 00005A26 14 21 GetNextCluster 00005A69 15 22 GetNextClusterExtend 0000E0C0 16 23 MajorFunctionNames 0000A620 17 24 NextCluster 0000A65C 18 25 OffsetToCluster 00001801 19 26 ReadVolumeLabel 00005B9D 1A 27 VfatAcquireForLazyWrite@8 00005C15 1B 28 VfatAcquireForReadAhead@8 00003B7E 1C 29 VfatAddEntry 0000A1C3 1D 30 VfatAllocateIrpContext 0000138C 1E 31 VfatBlockDeviceIoControl 0000A3D4 1F 32 VfatBuildRequest@8 00001430 20 33 VfatCleanup 000015F3 21 34 VfatClose 00001550 22 35 VfatCloseFile 00001D14 23 36 VfatCreate 0000477B 24 37 VfatDelEntry 00002630 25 38 VfatDirectoryControl 00008EEF 26 39 VfatFileSystemControl 0000831D 27 40 VfatFlush 000081B9 28 41 VfatFlushVolume 00009FF0 29 42 VfatFreeIrpContext 0000A558 2A 43 VfatGetUserBuffer 00011010 2B 44 VfatGlobalData 00005C8D 2C 45 VfatInitFastIoRoutines 00002FC2 2D 46 VfatIsDirectoryEmpty 0000A5B1 2E 47 VfatLockUserBuffer 00007897 2F 48 VfatQueryInformation 0000C230 30 49 VfatQueryVolumeInformation 0000A4D2 31 50 VfatQueueRequest 0000AD85 32 51 VfatRead 00001070 33 52 VfatReadDisk 000010F4 34 53 VfatReadDiskPartial 00005BE3 35 54 VfatReleaseFromLazyWrite@4 00005C5B 36 55 VfatReleaseFromReadAhead@4 00007474 37 56 VfatSetAllocationSizeInformation 00004AD0 38 57 VfatSetExtendedAttributes 00007D3D 39 58 VfatSetInformation 0000C4C5 3A 59 VfatSetVolumeInformation 0000BFC0 3B 60 VfatShutdown@8 000037C0 3C 61 VfatUpdateEntry 0000B301 3D 62 VfatWrite 00001240 3E 63 VfatWriteDiskPartial 00005974 3F 64 WriteCluster 0000E140 40 65 long_illegals 00001690 41 66 vfat8Dot3ToString 00006316 42 67 vfatAddFCBToTable 00006AA7 43 68 vfatAttachFCBToFileObject 0000615B 44 69 vfatDestroyCCB 000061A4 45 70 vfatDestroyFCB 00002F90 46 71 vfatDirEntryGetFirstCluster 00006B10 47 72 vfatDirFindFile 00006204 48 73 vfatFCBIsDirectory 00006215 49 74 vfatFCBIsRoot 00003919 4A 75 vfatFindDirSpace 00006CCA 4B 76 vfatGetFCBForFile 000063B6 4C 77 vfatGrabFCBFromTable 0000C210 4D 78 vfatIsLongIllegal 000066F0 4E 79 vfatMakeFCBFromDirEntry 0000653C 4F 80 vfatMakeRootFCB 00005E8B 50 81 vfatNewFCB 000066B8 51 82 vfatOpenRootFCB 00006236 52 83 vfatReleaseFCB 00005DC7 53 84 vfatSplitPathName

19 years, 1 month

RE: [ion] 19742: - Implement RtlPrefectMemoryNonTemporal.Patch by Patrick Baggett <baggett.patrick@gmail.com> and myself.

by Ge van Geldorp

> From: ion(a)svn.reactos.com > > + > +@RtlPrefetchMemoryNonTemporal@8: > + ret /* Overwritten by ntoskrnl/ke/i386/kernel.c if SSE is supported (see Ki386SetProcessorFeatures() ) */ Is this routine so time-critical that we want to resort to self-modifying code? GvG

19 years, 1 month

Kernel32 race condition

by Ge van Geldorp

While working on proper logoff/shutdown processing, I'm running into an interesting race condition inside kernel32. The shutdown command (apps/utils/shutdown) calls ExitWindowsEx() and then terminates, which causes kernel32's DllMain() function to be called with the DLL_PROCESS_DETACH reason. This will clean up kernel32 resources, like calling RtlDeleteCriticalSection(&ConsoleLock). Now, before the process is completely shutdown, CSRSS will send it a CTRL_LOGOFF_EVENT. To deliver this event, CSRSS calls CreateRemoteThread(). So CreateRemoteThread() is called while the main thread is executing DLL_PROCESS_DETACH cleanup. During handling of CTRL_LOGOFF_EVENT, the new thread will try to enter the ConsoleLock critical section, which was already deleted by the main thread. Chaos results. To solve this, first I was looking for a way to disable new thread creation when a process enters ExitProcess(), but that won't solve the problem. We can still have a thread A which calls ExitProcess(), have a context switch to existing thread B of the same process which does something that needs the ConsoleLock. Then I considered SuspendThread()ing all other threads of the process when ExitProcess() is called, but that could potentially lead to deadlocks if the suspended threads hold synchronization objects. So now I'm inclined to believe that the solution is to just not do the resource cleanup during DLL_PROCESS_DETACH handling. But that doesn't feel very clean either. Anyone have a better idea? GvG

19 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev November 2005