Ros-dev

ros-dev@reactos.org

5790 discussions

Re: [ros-diffs] [mbosma] 21894: [AUDIT] Unlock the Cache Manager - It is not even compatible to windows - Alex assures his code is clean
by Maarten Bosma 11 May '06

11 May '06

Here is the list from Alex. > (Nagar refers to Rajeev's book) > > ntoskrnl/cc/fs.c > > CcGetDirtyPages => STUB > CcGetFileObjectFromBcb => Nagar (not even sure i wrote it). > CcGetLsnForFileObject => STUB > CcInitializeCacheMap => Did not code. (calls CcRos) > CcIsThereDirtyData => STUB > CcPurgeCacheSection => STUB > CcSetFileSizes => Did not code. > CcSetLogHandleForFile => STUB > CcUninitializeCacheMap => Stub/Calls Ccros > > ntoskrnl/cc/view.c > > CcTryToAcquireBrokenMutex => Did not code (copy-pasted implementation of old mutext impl, renamed). > > ntoskrnl/cc/copy.c > > CcDeferWrite => STUB > CcFastCopyRead => STUB > CcFastCopyWrite => STUB > CcWaitForCurrentLazyWriterActivity => STUB > > ntoskrnl/cc/pin.c > > CcPinMappedData => STUB > CcPinRead => Did not code. > CcSetDirtyPinnedData => Did not code. > > ntoskrnl/cc/mdl.c > > CcMdlRead => STUB > CcMdlReadCompleteDev => Nagar/Trivial implementation. > CcMdlReadComplete => Nagar/Trivial implementation. > CcMdlWriteComplete => Same as read complete, just renamed to *write* > CcMdlWriteCompleteDev => STUB > CcMdlWriteAbort => STUB > CcPrepareMdlWrite => STUB > > ntoskrnl/cc/cacheman.c > > CcGetFlushedValidData => STUB > CcRemapBcb => STUB > CcScheduleReadAhead => STUB > CcSetAdditionalCacheAttributes => STUB > CcSetBcbOwnerPointer => STUB > CcSetDirtyPageThreshold => STUB > CcSetReadAheadGranularity => STUB mbosma(a)svn.reactos.org wrote: > Author: mbosma > Date: Fri May 12 02:40:37 2006 > New Revision: 21894 > > URL: http://svn.reactos.ru/svn/reactos?rev=21894&view=rev > Log: > [AUDIT] > Unlock the Cache Manager > - It is not even compatible to windows > - Alex assures his code is clean > > Modified: > trunk/reactos/ntoskrnl/cc/cacheman.c (props changed) > trunk/reactos/ntoskrnl/cc/copy.c (props changed) > trunk/reactos/ntoskrnl/cc/fs.c (props changed) > trunk/reactos/ntoskrnl/cc/mdl.c (props changed) > trunk/reactos/ntoskrnl/cc/pin.c (props changed) > trunk/reactos/ntoskrnl/cc/view.c (props changed) >

1 0

Re: [ros-bugs] [Bug 1473] Function definition fixes
by Magnus Olsen 11 May '06

11 May '06

----- Original Message ----- From: <ReactOS.Bugzilla(a)reactos.org> To: <ros-bugs(a)reactos.org> Sent: Thursday, May 11, 2006 9:41 AM Subject: [ros-bugs] [Bug 1473] Function definition fixes > http://www.reactos.org/bugzilla/show_bug.cgi?id=1473 > > > > > > ------- Comment #1 from w3seek(a)reactos.com 2006-05-11 09:41 CET ------- > Created an attachment (id=804) > --> (http://www.reactos.org/bugzilla/attachment.cgi?id=804&action=view) > The patch > > > -- > Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the QA contact for the bug, or are watching the QA contact. > You are the assignee for the bug, or are watching the assignee. > _______________________________________________ > Ros-bugs mailing list > Ros-bugs(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-bugs

1 0

RE: Ros-dev Digest, Vol 14, Issue 25
by Lucio Diaz 10 May '06

10 May '06

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

11 18

[Fwd: Re: [ros-dev] NDK Patches]
by Alex Ionescu 09 May '06

09 May '06

1 0

Re: [ros-bugs] [Bug 1460] Extended DOS Partition
by Royce Mitchell III 08 May '06

08 May '06

ReactOS.Bugzilla(a)reactos.org wrote: >http://www.reactos.org/bugzilla/show_bug.cgi?id=1460 > > >greatlord(a)reactos.com changed: > > What |Removed |Added >---------------------------------------------------------------------------- > Status|NEW |RESOLVED > Resolution| |WONTFIX > > > > >------- Comment #2 from greatlord(a)reactos.com 2006-05-08 21:13 CET ------- >you can not install any os on exstions partions >what I know, a OS need be on primary partions > >This bug report is invaild in my eyes > > Umm... this is not strictly true. You *can* install an OS on an extended partition. You just can't put the boot strap on an extended partition. Note that this is not a discussion about how *wise* such a thing would be...

2 1

RE: [ros-diffs] [greatlrd] 21849: if u update En.rc please update all other langues files, use the english text if no translatesion is no t availbal, other wise it will bsd in windows or in reactos and we get di ffent functions on each langues. DO NOT DO T
by Murphy, Ged (Bolton) 08 May '06

08 May '06

greatlrd(a)svn.reactos.org wrote: > if u update En.rc please update all other langues files, use > the english text if no translatesion is not availbal, other > wise it will bsd in windows or in reactos and we get diffent > functions on each langues. DO NOT DO THIS MISTAKE If it's just 1 or 2 lines, it generally not a big deal to alter all the files. However when the changes are large, and considering programmers are generally lazy ;) it can be a real pain to change all the resources. This problem is only going to get worse as more languages are added. I think it could be worthwhile setting up official translation teams who are contacted when a resource file changes. It'd be relatively easy to script. It would benefit both ReactOS, and people who want to get involved but aren't programmers. Our translation teams are a bit of a grey area at the moment. Our website is much better organised in this department than our actual operating system. 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

2 1

RE: [greatlrd] 21849: if u update En.rc please update all other langues files, use the english text if no translatesion is not availbal, other wise it will bsd in windows or in reactos and we get diffent functions on each langues. DO NOT DO T
by Ge van Geldorp 08 May '06

08 May '06

> From: greatlrd(a)svn.reactos.org > > Log: > if u update En.rc please update all other langues files, use > the english text if no translatesion is not availbal, other > wise it will bsd in windows or in reactos and we get diffent > functions on each langues. DO NOT DO THIS MISTAKE The resource loader will load the English text if the text is not available in the selected language (at least that's what is supposed to happen, if it doesn't there's a bug in the resource loader). GvG

2 2

Re: [ros-dev] RE: [greatlrd] 21849: if u update En.rc please update all other langues files, use the english text if no translatesion is not availbal, other wise it will bsd in windows or in reactos and we get diffent functions on each langues. DO NO
by Martin Fuchs 08 May '06

08 May '06

> > Log: > > if u update En.rc please update all other langues files, use > > the english text if no translatesion is not availbal, other > > wise it will bsd in windows or in reactos and we get diffent > > functions on each langues. DO NOT DO THIS MISTAKE > > The resource loader will load the English text if the text is not available in the > selected language (at least that's what is supposed to happen, if it doesn't > there's a bug in the resource loader). Correct with one small exception: String table resources are loaded in chunks of 16 strings, so strings should be updates with great care: If one inserts new strings into the string table only in English, the resource IDs of this new strings should be aligned to a boundary of 16. Regards, Martin

1 0

Third Boot Blue Screen
by James Tabor 04 May '06

04 May '06

Hi! Reporting a third boot hard fault. After install and reboot with driver wizard. On the third reboot after setting the display to 32 bit 1024x768 with background this happens. I repeated it three times to make sure this was not bogus. Revision is 21795. Thanks, James <Snip > (drivers/usb/miniport/sys/linuxwrapper.c:252) schedule_timeout: 5 ms (drivers/usb/usbport/hub.c:1230) hub_thread starting(drivers/usb/miniport/sys/linuxwrapper.c:286) schedule DONE!!!!!! (drivers/usb/miniport/sys/linuxwrapper.c:252) schedule_timeout: 1 ms (drivers/usb/miniport/sys/linuxwrapper.c:286) schedule DONE!!!!!! (drivers/usb/miniport/sys/linuxwrapper.c:793) pci_alloc_consistent() size=8196 (drivers/usb/miniport/sys/linuxwrapper.c:639) pci_pool_create(): UHCD PCI Slot/uhci_td size 48, 85/page (4096 alloc) (drivers/usb/miniport/sys/linuxwrapper.c:639) pci_pool_create(): UHCD PCI Slot/uhci_qh size 48, 85/page (4096 alloc) (drivers/usb/miniport/sys/ros_wrapper.c:8) wait_ms(10) (drivers/usb/miniport/sys/linuxwrapper.c:167) drv_num 2 80ef9423 80ef9320 (drivers/usb/usbport/usb.c:1255) .........................usb_new_device: usb-UHCD PCI Slot-0 interface 0 (drivers/usb/miniport/sys/linuxwrapper.c:167) drv_num 2 80ef9423 80ef9320 (drivers/usb/miniport/sys/linuxwrapper.c:181) probe0 80ef9423 (drivers/usb/usbport/hub.c:521) hub_thread should woke up (drivers/usb/miniport/sys/ros_wrapper.c:8) wait_ms(0) (drivers/usb/miniport/sys/ros_wrapper.c:8) wait_ms(0) (drivers/usb/miniport/sys/ros_wrapper.c:8) wait_ms(6) (drivers/usb/miniport/sys/linuxwrapper.c:181) probe1 80ef9320 (drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 2: 80efe148 80ef9423(drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 3: 80efe328 80ef9423(drivers/usb/miniport/common/fdo.c:270) USBMP: IRP_MJ_PNP / unknown minor function 0x9 (drivers/usb/miniport/common/pdo.c:333) USBMP: IRP_MJ_PNP / unknown minor function 0x15 (./ntoskrnl/ldr/loader.c:334) Driver Load Success: \SystemRoot\System32\drivers\usbhub.sys (./ntoskrnl/io/device.c:576) Cannot insert Device Object '\Device\USBFDO-0' into Handle Table (status 0xc0000035) (drivers/usb/miniport/common/fdo.c:270) USBMP: IRP_MJ_PNP / unknown minor function 0x8 (drivers/usb/miniport/sys/linuxwrapper.c:479) IoGetDmaAdapter done 0x81213888, mapRegisterCount=2 (drivers/usb/usbport/hcd-pci.c:74) usbcore: usb_hcd_pci_probe() called (drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 4: 80efe0b8 80ef9423(drivers/usb/miniport/sys/linuxwrapper.c:137) usbcor(drivers/usb/usbport/hub.c:1230) hub_thread startinge: Created system thread 80 (drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 5: 80efe114 80ef9320(drivers/usb/usbport/hcd-pci.c:74) usbcore: usb_hcd_pci_probe() called (drivers/usb/usbport/../miniport/linux/pci_hal.c:13) pci_enable_device() called. .. (drivers/usb/usbport/../miniport/linux/pci_hal.c:44) pci_resource_flags() called, x=0x0 (drivers/usb/usbport/../miniport/linux/pci_hal.c:21) pci_resource_start() called, x=0x0 (drivers/usb/usbport/../miniport/linux/pci_hal.c:33) pci_resource_len() called,x=0x0 (drivers/usb/usbport/../miniport/linux/pci_hal.c:86) request_region(): addr=0xd400, len=0x20 (drivers/usb/usbport/../miniport/linux/pci_hal.c:58) pci_set_drvdata() called... (drivers/usb/miniport/usbuhci/../linux/pci_hal.c:33) pci_resource_len() called,x=0x0 (drivers/usb/miniport/sys/linuxwrapper.c:252) schedule_timeout: 5 ms (drivers/usb/miniport/sys/linuxwrapper.c:286) schedule DONE!!!!!! (drivers/usb/miniport/sys/linuxwrapper.c:252) schedule_timeout: 1 ms (drivers/usb/miniport/sys/linuxwrapper.c:286) schedule DONE!!!!!! (drivers/usb/miniport/sys/linuxwrapper.c:793) pci_alloc_consistent() size=8196 (drivers/usb/miniport/sys/linuxwrapper.c:639) pci_pool_create(): UHCD PCI Slot/uhci_td size 48, 85/page (4096 alloc) (drivers/usb/miniport/sys/linuxwrapper.c:639) pci_pool_create(): UHCD PCI Slot/uhci_qh size 48, 85/page (4096 alloc) (drivers/usb/miniport/sys/ros_wrapper.c:8) wait_ms(10) (drivers/usb/miniport/sys/linuxwrapper.c:167) drv_num 6 80ef9423 80ef9320 (drivers/usb/usbport/usb.c:1255) .........................usb_new_device: usb-UHCD PCI Slot-0 interface 0 (drivers/usb/miniport/sys/linuxwrapper.c:167) drv_num 6 80ef9423 80ef9320 (drivers/usb/miniport/sys/linuxwrapper.c:181) probe0 80ef9423 (drivers/usb/usbport/hub.c:521) hub_thread should woke up (drivers/usb/miniport/sys/ros_wrapper.c:8) wait_ms(0) (drivers/usb/miniport/sys/ros_wrapper.c:8) wait_ms(0) (drivers/usb/miniport/sys/ros_wrapper.c:8) wait_ms(6) (drivers/usb/miniport/sys/linuxwrapper.c:181) probe1 80ef9320 (drivers/usb/miniport/sys/linuxwrapper.c:181) probe2 80ef9423 (drivers/usb/miniport/sys/linuxwrapper.c:181) probe3 80ef9423 (drivers/usb/miniport/sys/linuxwrapper.c:181) probe4 80ef9423 (drivers/usb/miniport/sys/linuxwrapper.c:181) probe5 80ef9320 (drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 6: 80efe148 80ef9423(drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 7: 80efe328 80ef9423(drivers/usb/miniport/common/fdo.c:270) USBMP: IRP_MJ_PNP / unknown minor function 0x9 (drivers/usb/miniport/common/pdo.c:333) USBMP: IRP_MJ_PNP / unknown minor function 0x15 (./ntoskrnl/io/device.c:576) Cannot insert Device Object '\Device\USBFDO-1' into Handle Table (status 0xc0000035) (drivers/usb/miniport/common/fdo.c:270) USBMP: IRP_MJ_PNP / unknown minor function 0x8 (drivers/usb/miniport/sys/linuxwrapper.c:479) IoGetDmaAdapter done 0x81216848, mapRegisterCount=2 (drivers/usb/usbport/hcd-pci.c:74) usbcore: usb_hcd_pci_probe() called (drivers/usb/usbport/hcd-pci.c:74) usbcore: usb_hcd_pci_probe() called (drivers/usb/usbport/../miniport/linux/pci_hal.c:13) pci_enable_device() called... (drivers/usb/usbport/../miniport/linux/pci_hal.c:44) pci_resource_flags() called, x=0x0 (drivers/usb/usbport/../miniport/linux/pci_hal.c:21) pci_resource_start() called, x=0x0 (drivers/usb/usbport/../miniport/linux/pci_hal.c:33) pci_resource_len() called,x=0x0 (drivers/usb/usbport/../miniport/linux/pci_hal.c:86) request_region(): addr=0xd000, len=0x20 (drivers/usb/usbport/../miniport/linux/pci_hal.c:58) pci_set_drvdata() called... (drivers/usb/miniport/usbuhci/../linux/pci_hal.c:33) pci_resource_len() called,x=0x0 (drivers/usb/miniport/sys/linuxwrapper.c:252) schedule_timeout: 5 ms (drivers/usb/miniport/sys/linuxwrapper.c:286) schedule DONE!!!!!! (drivers/usb/miniport/sys/linuxwrapper.c:252) schedule_timeout: 1 ms (drivers/usb/miniport/sys/linuxwrapper.c:286) schedule DONE!!!!!! (drivers/usb/miniport/sys/linuxwrapper.c:793) pci_alloc_consistent() size=8196 (drivers/usb/miniport/sys/linuxwrapper.c:639) pci_pool_create(): UHCD PCI Slot/uhci_td size 48, 85/page (4096 alloc) (drivers/usb/miniport/sys/linuxwrapper.c:639) pci_pool_create(): UHCD PCI Slot/uhci_qh size 48, 85/page (4096 alloc) (drivers/usb/miniport/sys/ros_wrapper.c:8) wait_ms(10) (drivers/usb/miniport/sys/linuxwrapper.c:167) drv_num 8 80ef9423 80ef9320 (drivers/usb/usbport/usb.c:1255) .........................usb_new_device: usb-UHCD PCI Slot-0 interface 0 (drivers/usb/miniport/sys/linuxwrapper.c:167) drv_num 8 80ef9423 80ef9320 (drivers/usb/miniport/sys/linuxwrapper.c:181) probe0 80ef9423 (drivers/usb/usbport/hub.c:521) hub_thread should woke up (drivers/usb/miniport/sys/ros_wrapper.c:8) wait_ms(0) (drivers/usb/miniport/sys/ros_wrapper.c:8) wait_ms(0) (drivers/usb/miniport/sys/ros_wrapper.c:8) wait_ms(6) (drivers/usb/miniport/sys/linuxwrapper.c:181) probe1 80ef9320 (drivers/usb/miniport/sys/linuxwrapper.c:181) probe2 80ef9423 (drivers/usb/miniport/sys/linuxwrapper.c:181) probe3 80ef9423 (drivers/usb/miniport/sys/linuxwrapper.c:181) probe4 80ef9423 (drivers/usb/miniport/sys/linuxwrapper.c:181) probe5 80ef9320 (drivers/usb/miniport/sys/linuxwrapper.c:181) probe6 80ef9423 (drivers/usb/miniport/sys/linuxwrapper.c:181) probe7 80ef9423 (drivers/usb/miniport/common/fdo.c:270) USBMP: IRP_MJ_PNP / unknown minor function 0x9 (drivers/usb/miniport/common/pdo.c:333) USBMP: IRP_MJ_PNP / unknown minor function 0x15 (./ntoskrnl/ldr/loader.c:334) Driver Load Success: \SystemRoot\system32\drivers\floppy.sys <Snip > (./ntoskrnl/ldr/loader.c:334) Driver Load Success: \SystemRoot\system32\drivers\i8042prt.sys (./ntoskrnl/ldr/loader.c:334) Driver Load Success: \SystemRoot\system32\drivers\mouclass.sys (./ntoskrnl/ldr/loader.c:334) Driver Load Success: \SystemRoot\system32\drivers\kbdclass.sys (drivers/usb/miniport/common/main.c:333) USBMP: PDO stub for major function 0x0 Assertion 'FALSE' failed at drivers/usb/miniport/common/main.c line 335 KeBugCheckWithTf at ntoskrnl/ke/i386/exp.c:1241 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. The problem seems to be caused by the following file: ntoskrnl.exe Technical information: *** STOP: 0x0000001E (0x80000003,0x8006bcb1,0x8005e4da,0x878000fc) *** ntoskrnl.exe - Address 0x8006bcb1 base at 0x80000000, DateStamp 0x0 Exception: -1160049408(0) Processor: 0 CS:EIP 8:8006bcb1 <ntoskrnl.exe:6bcb1 (lib/rtl/i386/debug_asm.S:23 (DbgBreakPoint))> cr2 8db6a000 cr3 26000 Proc: 81004c20 Pid: 4 <System> Thrd: 81005660 Tid: 0 DS 23 ES 23 FS 30 GS 0 EAX: 00000000 EBX: 80ec6cc7 ECX: 00000000 EDX: 00000000 EBP: 800b1730 ESI: 810195e0 ESP: 800b16b4 EDI: 01000040 EFLAGS: 00200282 kESP 800b16b4 kernel stack base 800af000 Frames: <usbuhci.sys:5be5 (drivers/usb/miniport/common/main.c:338 (IrpStub))> <ntoskrnl.exe:22044 (./ntoskrnl/io/irp.c:1076 (IofCallDriver))> <ntoskrnl.exe:330de (ntoskrnl/io/file.c:1139 (IoCreateFile))> <ntoskrnl.exe:34534 (ntoskrnl/io/file.c:2360 (NtOpenFile))> <ntoskrnl.exe:652b7 (ntoskrnl/ke/i386/trap.s:306 (KiFastCallEntry))> <ntoskrnl.exe:22919 (./ntoskrnl/io/device.c:204 (IopGetDeviceObjectPointer))> <ntoskrnl.exe:2299f (./ntoskrnl/io/device.c:786 (IoGetDeviceObjectPointer))> <kbdclass.sys:1b5e (drivers/input/kbdclass/kbdclass.c:833 (ClassAddDevice))> <ntoskrnl.exe:22b5a (./ntoskrnl/io/device.c:91 (IopInitializeDevice))> <ntoskrnl.exe:2b8c6 (./ntoskrnl/io/driver.c:2027 (NtLoadDriver))> <ntoskrnl.exe:652b7 (ntoskrnl/ke/i386/trap.s:306 (KiFastCallEntry))> <ntoskrnl.exe:820f9 (./ntoskrnl/io/driver.c:1398 (IopLoadDriver))> <ntoskrnl.exe:24bc6 (./ntoskrnl/io/driver.c:1469 (IopInitializeSystemDrivers))> <ntoskrnl.exe:836cc (./ntoskrnl/io/iomgr.c:434 (IoInit3))> <ntoskrnl.exe:8128c (./ntoskrnl/ex/init.c:668 (ExpInitializeExecutive))> <ntoskrnl.exe:4e75 (./ntoskrnl/ke/main.c:108 (KiSystemStartup))> <ntoskrnl.exe:7f53e (./ntoskrnl/ke/main.c:295 (_main))> <0>

1 0

Missing validation in MmMapViewOfSection
by Myria 04 May '06

04 May '06

If the ImageBase for a given executable is in the kernel range (above 0x7FFE1000 or whatever), from reading the code it seems like no validation will stop it from going above that address. I have no way to try it out because I don't have reactos installed. Interestingly, in Windows XP SP2, the only illegal ImageBase values are: 7C800000 - Causes a dialog box to appear during the ntdll process initialization APC saying that the program can't run because kernel32.dll was relocated. 7C900000 - Causes PspMapSystemDll to fail. As a result, the process is never created and NtCreateProcessEx returns an error. These errors occur even when /fixed:no is used. Every other address is allowed by Windows as long as /fixed:no is specified, even above the user-kernel barrier. Personally I think reactos should allow user mode programs to shove ntdll and kernel32 out of the way, but that's just me =) Finally, 04477 MmUnlockAddressSpace(AddressSpace); 04478 return(STATUS_UNSUCCESSFUL); and the one below it should return STATUS_CONFLICTING_ADDRESSES, determined by attempting to load an image based at a kernel address without a relocation section. MmCreatePeb has an invalid assertion: ASSERT(Peb == (PVOID)0x7FFDF000); If the process's .exe already is at that address, the PEB will be at the wrong address. There's also a nice way for a user-mode program to bugcheck the kernel or leak a small amount of information in MmCreatePeb: ImageConfigData = RtlImageDirectoryEntryToData(Peb->ImageBaseAddress, To crash the kernel, put a bogus load config directory entry pointer in your .exe. To read an arbitrary dword or two, set up the load config pointer such that it aims at your desired memory address, then read the PEB's OSCSDVersion and ImageProcessAffinityMask values once your process starts. Melissa

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev