- Ros-dev - ReactOS.org

Idea to save time in future - Language Support AndUse inReactos [non HTML - sorry for previous post]
by Radovan Skolnik 12 Mar '05

12 Mar '05

What you're saying is true however let me bring forth few points: 1. MUI only works one some Windows versions - true. However it runs basically on all Windows versions available today (Windows 98/Me is not your target) and Windows XP Home Edition as we all know is binary compatible with Windows XP so the limitation is only in version check. 2. You cannot get it free - true. But is this important? You cannog get Windows for free as well and still you're trying to clone it (rather succesfully). 3. Are you sure the API is not available? I believe it would be fairly easy to reasearch it even if it wasn't. 4. "So I think reactos must support least 2 langues at fly." Why limit yourself to 2 only? Why not 3 or 4? 5. "But why not deside which langues it will support when it compile." In my opinion this is answered very easily: a. Because you do not want to create ReactOS for power-users who are keen to compile stuff. If you need to compile it you'll scare newbies who just want the simplicity of their old Windows for free. b. Because it contradicts your initial requirement: "If you look at Amiga OS (Workbench 2.0 or higher) you can change the hole os langues when it was running." All in all: I think the M$ approach is really good one: scalable and easy to use. If you don't want to clone the API for whatever reason, clone the principle... Best regards Radovan Skolnik "Magnus Olsen" <magnus(a)itkonsult-olsen.com> Sent by: ros-dev-bounces(a)reactos.com 12.03.2005 14:57 -------------------------------------------------------------------------------- Please respond to ReactOS Development List -------------------------------------------------------------------------------- To "ReactOS Development List" <ros-dev(a)reactos.com> cc bcc Subject Re: [ros-dev] Idea to save time in future - Language Support AndUse inReactos The MUI only work on some windows version and you can not geting it free. or even the api. So I think reactos must support least 2 langues at fly. But why not deside which langues it will support when it compile. if you only want example english and french example you got it or you want all langues. you got it instead. when reactos are beign compile ? I have done a copy and paste from ms site http://www.microsoft.com/globaldev/DrIntl/faqs/MUIFaq.mspx#MUIques1 read it about it here. What versions of Windows are supported by MUI? MUI was introduced in the Windows 2000 timeframe and is available for: a.. Windows 2000 Professional b.. Windows 2000 Server Family - often implemented in a Terminal Services environment c.. Windows XP Professional d.. Windows XP for Tablet PC e.. Windows Server 2003 Family f.. Windows XP Embedded MUI is not supported on consumer versions of Windows such as Windows 9x, Windows Me, and Windows XP Home Edition. What are the system requirements of Windows MUI? MUI is an add-on to the English version of Windows XP Professional and Windows 2000 family of operating systems, and will not install on localized versions of Windows XP/2000 or on Windows XP Home Edition. Every additional language installed will require approximately 115 MB extra disk space for Windows XP, 45MB for Windows 2000; East Asian language support requires an additional 250 MB. How can I acquire Windows MUI? The Windows XP/2000 MUI is sold only through Volume Licensing programs such as the Microsoft Open License Program (MOLP / Open), Select, and Enterprise agreement (or with a new computer as an OEM version at customer request). It is not available through retail channels. ----- Original Message ----- From: "Radovan Skolnik" <Radovan_Skolnik(a)tempest.sk> To: <ros-dev(a)reactos.com> Sent: Saturday, March 12, 2005 1:40 PM Subject: RE: [ros-dev] Idea to save time in future - Language Support AndUse inReactos > Hello guuys (and girls if any out there)! > > Until now I have been watching the development of ReactOS with great > interest but as a not-so-great C/C++ programmer (especially for kernel > stuff) I felt no urge to add my (for you would be worthless) comments :-) > However the discussion about localizing ReactOS struck me because I think > there's one thing in/for M$ Windows/Office you probably don't know about > that already handles this. It is called MUI (Multilingual User Interface > Pack) - read about it here: > http://www.microsoft.com/globaldev/DrIntl/faqs/MUIFaq.mspx What it does is > that it adds another combo box to Regional Settings in Control Panel and > each user can choose language to its liking (from those installed of > course). I can have a look at install media for few languages but as far as > I remember it is only bunch of .inf & .dll (probably resources) files. So I > believe there is indeed an API to achieve this. So if you're aiming for > maximum compatibility with original Windows (whatever version) you should > probably consider this approach. I'm home and sick now with flu but when I > get well I'll research the MUI media in more detailed way and let you > know... > > Best regards > > Radovan Skolnik > > ----- Original Message ----- > From: Magnus Olsen magnus at itkonsult-olsen.com > > I want see driffnet langues in the dll and change langues on fly > instead compile a dll file for each langues. I am mising that feturtuer in > windows. > If you look at Amiga OS (Workbench 2.0 or higher) you can change the hole > os > langues > when it was running. in windows you are stuck with one langues. > > So I think it is good idea to compile all langues into all dll file. > then select in the os wich langues you want use. > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-dev _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev

1 0

Re: [ros-dev] Idea to save time in future - Language Support AndUse inReactos
by Radovan Skolnik 12 Mar '05

12 Mar '05

1 0

RE: [ros-dev] Idea to save time in future - Language Support AndUse in Reactos
by Radovan Skolnik 12 Mar '05

12 Mar '05

Hello guuys (and girls if any out there)! Until now I have been watching the development of ReactOS with great interest but as a not-so-great C/C++ programmer (especially for kernel stuff) I felt no urge to add my (for you would be worthless) comments :-) However the discussion about localizing ReactOS struck me because I think there's one thing in/for M$ Windows/Office you probably don't know about that already handles this. It is called MUI (Multilingual User Interface Pack) - read about it here: http://www.microsoft.com/globaldev/DrIntl/faqs/MUIFaq.mspx What it does is that it adds another combo box to Regional Settings in Control Panel and each user can choose language to its liking (from those installed of course). I can have a look at install media for few languages but as far as I remember it is only bunch of .inf & .dll (probably resources) files. So I believe there is indeed an API to achieve this. So if you're aiming for maximum compatibility with original Windows (whatever version) you should probably consider this approach. I'm home and sick now with flu but when I get well I'll research the MUI media in more detailed way and let you know... Best regards Radovan Skolnik ----- Original Message ----- From: Magnus Olsen magnus at itkonsult-olsen.com I want see driffnet langues in the dll and change langues on fly instead compile a dll file for each langues. I am mising that feturtuer in windows. If you look at Amiga OS (Workbench 2.0 or higher) you can change the hole os langues when it was running. in windows you are stuck with one langues. So I think it is good idea to compile all langues into all dll file. then select in the os wich langues you want use.

2 1

Re: AW: [ros-dev] Saying To All
by Thomas Larsen 12 Mar '05

12 Mar '05

--- Rouven We�ling <rouven(a)rouvenwessling.de> wrote: Thomas Larsen schrieb: >4. Disam shell32 and scsiport.sys Theire where lot of places where it where identical > > >The M$ compiler and gcc is very different. If you compare the assembler >code which is compiled from the same source, you can found the same >functions bodies, but inside the functions there are many differences. >Some time ago, I've ported a simple driver for an eprom programer from >M$ tools to the ReactOS build system. At the start it hasn't worked, >because I forgot the stdcall attributes for some functions. The >reassembled code was very different. Their are not that big difference agre that scsiport is in c code when you compile it you get machine code right when you compare the "C CODE from scsiport.sys from REACTOS" with microsoft asm from ida pro it will list the functions used and the params used and what cases it used around in the code what internal function their are called not so hard BUT if you compare GNU Asm Vs. Ms Asm their will be a big diff. >5. Microsoft Source leak my friend just downloaded it i got parts of the >code what could be on my >1,33 mb floppy > > >If you was interessted to compare the ros and M$ code, >you have neverworked with a floppy. It is too simple to burn a cd or dvd. If i want to use a floppy i use a fucking floppy the parts i wanted to find out where small sections from shell32 and scsiport.sys just to get some invidence from winnt4.0 and i got those thing one my so simple floppy i could use a dvd a cdrom a harddisk but why i could be on my floppy >6. Saw scsiport.sys where 90% identical i layout and code and alittel of >shell32 > > >Some parts of scsiport are from me. I've never seen the scsiport sources >from M$. I'm not sure which code from M$ you know. Our scsiport is more >compatible with the NT4.0 one. I've test many scsi controller with its >NT 4.0 drivers (adaptect 2940, ataptec on asus p2d, dmx3194uw, diamond >fireport, tekram dc390, initio a100, some with different lsi chipset, >some with initio 950 chip set). I think M$ has lost the W2K sourcesand >not the NT4.0 one. Our scsiport is very different from W2k and it is >different from NT4.0. I've add a list of imported functions. Some >functions are very specific for the implemention. ReactOS doesn't use >IoFreeMdl, IoFreeIrp, the DeviceQueu functions and some others. Many >things may nearly the same, bcause they must implement the some >functions. Our implementation is different from M$. The different >imported functions shows this. You cannot find 90% identical, if you >compare our source with the M$ source. 1. You point is GNU Asm / Microsoft Asm is Different - SO 2. I Dont use a cdrom or other media when its so easy - SO i still use floppy for small items dont think you know that in denmark their are taxes on the cdroms 3. Saying that microsoft uses some function witch reactos dont; i leave up to you to take an asm program Ida Pro 4.7 remember debug info is a good start see the exports in Winnt 4.0 Scsiport Driver and the imports and come back to me.. then you can open your mouth once again.- else its it would be a waste of time writing to me Thomas __________ __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

Re: [ros-dev] Saying To All
by Thomas Larsen 12 Mar '05

12 Mar '05

My english is sometimes poor For the first i give a shit public or not 1. One day i found reactos 2. Where looking on how you made reactos drivers and got (exiting=happy dont know how to spell) 3. Got Ida Disam in demo version 4. Disam shell32 and scsiport.sys Theire where lot of places where it where identical 5. Microsoft Source leak my friend just downloaded it i got parts of the code what could be on my 1,33 mb floppy 6. Saw scsiport.sys where 90% identical i layout and code and alittel of shell32 7. Wrote one mail or two dont remember saying it should newer have done so 8. Got many really unhappy ppl. email answers (they want to see the source and No i dident) 9. Talked with alot of ppl and i discover that i where not right 10. Worked on with reactos 11. The mail today ;I'm not quite sure what you're driving at, but are you saying you ;posess(ed) the leaked sources? And - by comparing it with ReactOS/WINE - ;we must have been tainted with it? I really hope I mistook that. i dident possess (in my word book its is "showing" the source) And no that where not what i meant to say Im Saying that i could just have changed email and name (NO Worry i dident do that) And my point only where give me a chance the only thing i want to is to help reactos.. but it seems that their are no chance so saying goodbye.. sry.. Thomas __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

4 3

Re: AW: [ros-dev] Saying To All
by Steven Edwards 12 Mar '05

12 Mar '05

Hi, --- Thomas Larsen <sikker2004(a)yahoo.com> wrote: > If i want to use a floppy > i use a fucking floppy the parts i wanted to find out where small sections from shell32 and > scsiport.sys just to get some invidence from winnt4.0 and i got those thing one my so simple > floppy i could use a dvd a cdrom a harddisk but why i could be on my floppy If I am reading this right, he is saying that he has looked at Microsoft source code and compared it to ReactOS. Is that right? Or just compared disassembled functions? In anycase, if Microsoft thinks there is a copyright violation in ReactOS please have them contact us and stop spaming the list. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

Re: Re: [ros-dev] Idea to save time in future - Language Support AndUse in Reactos
by rlangschultz＠cox.net 12 Mar '05

12 Mar '05

The Problem with this would be that the dll files or perhaps any compiled file would be large. Think of all the words that the German, English, French, portuguese, etc languages have. Doing this would make a binary executable be extremely large. I know that i only can use a limited amount of space with my vmware, bochs, and qemu images. about 256mbs is all. even if ReactOS did something like shell32.us-en.dll or shell32.us-es.dll or perhaps even shell32.1033.dll would be difficult because some executables come precompiled to use a staticly named dll file. I would think that adding every language would be very time consuming, and tax your disk space. > > From: "Magnus Olsen" <magnus(a)itkonsult-olsen.com> > Date: 2005/03/11 Fri PM 01:08:08 EST > To: "ReactOS Development List" <ros-dev(a)reactos.com> > Subject: Re: [ros-dev] Idea to save time in future - Language Support AndUse > in Reactos > > I want see driffnet langues in the dll and change langues on fly > instead compile a dll file for each langues. I am mising that feturtuer in > windows. > If you look at Amiga OS (Workbench 2.0 or higher) you can change the hole os > langues > when it was running. in windows you are stuck with one langues. > > So I think it is good idea to compile all langues into all dll file. > then select in the os wich langues you want use. > > > ----- Original Message ----- > From: "Thomas Weidenmueller" <w3seek(a)reactos.com> > To: "ReactOS Development List" <ros-dev(a)reactos.com> > Sent: Friday, March 11, 2005 11:16 AM > Subject: Re: [ros-dev] Idea to save time in future - Language Support AndUse > in Reactos > > > > Thomas Larsen wrote: > > > > >Language Support And Use in Reactos > > > > > >Idea: Split the files by using config and only include whats needed by > dev and end user > > >goal: Saves time in compiling and get smaller fil sizes. > > > > > > > > Resource files usually compile pretty fast and are usually not that big > > unless they contain large bitmaps. > > > > >If not done imagine 256 languages in each file getting included then we > would get pretty large > > >files just see shell32.dll and its a waste both for the end users and us > it takes a while extra to > > >include all those extra langs > > > > > > > > I wouldn't consider it as a waste of space, applications that use other > > locales then work correctly and dialogs etc work in all the same > > language. It's been bugging me that for instance german applications > > that run on an english system are completely german except the message > > box buttons, common controls, .... > > > > >The Config File i Reactos Root path > > ># Which default language would you like to use > > ># Select Between: English:En, Danish:Dk, France:Fr etc. > > >DEFAULTOSLANG=Dk > > > > > >The Ressource.rc file in each paths > > >#if DEFAULTLANG > > >#include %DEFAULTLANG%.rc // Need to test if exist if not include en.rc a > littel app could check > > >for this it would be pretty fast else include english res > > >#else > > >#include "En.rc" > > >#endif > > > > > >Just an idea.. Thomas > > > > > > > > Specifying a default language is indeed good, however I don't think it's > > good to compile just with this chosen language. But that's just my > > personal opinion. > > > > Best Regards, > > Thomas > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev(a)reactos.com > > http://reactos.com:8080/mailman/listinfo/ros-dev > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-dev >

2 1

Idea to save time in future - Language Support And Use in Reactos
by Thomas Larsen 11 Mar '05

11 Mar '05

Language Support And Use in Reactos Idea: Split the files by using config and only include whats needed by dev and end user goal: Saves time in compiling and get smaller fil sizes. If not done imagine 256 languages in each file getting included then we would get pretty large files just see shell32.dll and its a waste both for the end users and us it takes a while extra to include all those extra langs The Config File i Reactos Root path # Which default language would you like to use # Select Between: English:En, Danish:Dk, France:Fr etc. DEFAULTOSLANG=Dk The Ressource.rc file in each paths #if DEFAULTLANG #include %DEFAULTLANG%.rc // Need to test if exist if not include en.rc a littel app could check for this it would be pretty fast else include english res #else #include "En.rc" #endif Just an idea.. Thomas Ps. alot of patches new files and translation on bugzilla if any want to use it. :-) __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

3 2

Re: [ros-dev] Maybe Its All About Nothing
by Thomas Larsen 11 Mar '05

11 Mar '05

I Where pist that day from my point Illegal code in reactos in project i want to be in to Angry a took some maybe lille fast conclusions you just love to take old things up... or what.. Thomas __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

2 1

RE: [ros-cvs] CVS Update: rosapps
by Casper Hornstrup 11 Mar '05

11 Mar '05

> -----Original Message----- > From: ros-cvs-bounces(a)reactos.com > [mailto:ros-cvs-bounces@reactos.com] On Behalf Of Emanuele Aliberti > Sent: 1. december 2004 15:00 > To: ros-cvs(a)reactos.com > Subject: [ros-cvs] CVS Update: rosapps > > CVSROOT: /CVS/ReactOS > Module name: rosapps > Repository: rosapps/calc/ > Changes by: ea(a)mok.osexperts.com 04/12/01 14:59:52 > > Added files: > rosapps/calc/: .cvsignore > > Log message: Is it a CVS trick? Casper

11 20

Saying To All
by Thomas Larsen 11 Mar '05

11 Mar '05

Its a long time ago now Geldorp i no longer got the source code yes i look at it but only because some drivers and shell code where extreme close to microsofts old ones and i dident want to work on a project if it gets closed but now i know you and wine dident.. still sry for the accousing but i can do anything execpt saying that im sry And i could have changed e-mail and called me bob if it where that but i dident just to give you some to think about.. Im not mad or angry i where not clear about the policy back their and it where just to help you and reactos.. Thomas Larsen __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

3 2

Re: [ros-svn] [ion] 13832: - FreeLdr Part II (ntoskrnl is now relocated, removes 3GB compiler flag). Note that there is a bug in LD which Filip and I are examining, so do not try this yet.
by James Tabor 11 Mar '05

11 Mar '05

BugCheck Alert! ion(a)svn.reactos.com wrote: > - FreeLdr Part II (ntoskrnl is now relocated, removes 3GB compiler flag). Note that there is a bug in LD which Filip and I are examining, so do not try this yet. > - Fix Registry ObRef/ObDeref bug -- Hartmut > - Fix SID Capture Bug -- Thomas > - Use KPRCB pointer properly (results in more portable and much faster code) > (ob/object.c:1034) Object 81d6ad68/81d6ad90 has invalid handle count (-858993460 ) KeBugCheck at ob/object.c:1035 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. The bug code is undefined. Please use an existing code instead. Technical information: *** STOP: 0x00000000 (0x00000000,0x00000000,0x00000000,0x00000000) Frames: <ntoskrnl.exe: bf15 (ke/bug.c:425 (KeBugCheckEx))> <ntoskrnl.exe: bf51 (ke/bug.c:445 (KeBugCheck))> <ntoskrnl.exe: a98ba (ob/object.c:1035 (ObfDereferenceObject))> <ntoskrnl.exe: a7310 (ob/handle.c:959 (NtClose))> <ntoskrnl.exe: 33c2 (/tmp/cch6Lxn6.s:178 (KiSystemService))> <658D9845> <win32k.sys: 4b9bc (objects/text.c:2928 (TextIntRealizeFont))> <win32k.sys: 3811d (objects/dc.c:1867 (NtGdiSelectObject))> <ntoskrnl.exe: 33c2 (/tmp/cch6Lxn6.s:178 (KiSystemService))> <user32.dll: 3be70 (controls/edit.c:2977 (EDIT_EM_PosFromChar))> Entered debugger on exception number 3 (Breakpoint) Entered kernel debugger (type "help" for a list of commands) kdb:> bt Frames: <ntoskrnl.exe: 50d7 (ke/i386/brkpoint.c:50 (DbgBreakPointWithStatus))> <ntoskrnl.exe: be64 (ke/bug.c:397 (KeBugCheckWithTf))> <ntoskrnl.exe: bf15 (ke/bug.c:425 (KeBugCheckEx))> <ntoskrnl.exe: bf51 (ke/bug.c:445 (KeBugCheck))> <ntoskrnl.exe: a98ba (ob/object.c:1035 (ObfDereferenceObject))> <ntoskrnl.exe: a7310 (ob/handle.c:959 (NtClose))> <ntoskrnl.exe: 33c2 (/tmp/cch6Lxn6.s:178 (KiSystemService))> <win32k.sys: 4b9bc (objects/text.c:2928 (TextIntRealizeFont))> <win32k.sys: 3811d (objects/dc.c:1867 (NtGdiSelectObject))> <ntoskrnl.exe: 33c2 (/tmp/cch6Lxn6.s:178 (KiSystemService))> <user32.dll: 3be70 (controls/edit.c:2977 (EDIT_EM_PosFromChar))> <user32.dll: 3c2e0 (controls/edit.c:1583 (EDIT_GetLineRect))> <user32.dll: 3dd6e (controls/edit.c:1711 (EDIT_InvalidateText))> <user32.dll: 3f927 (controls/edit.c:4791 (EDIT_WM_SetText))> <user32.dll: 41a88 (controls/edit.c:1002 (EditWndProc_common))> <user32.dll: 42636 (controls/edit.c:1064 (EditWndProcW))> <user32.dll: 11ea1 (windows/message.c:964 (IntCallWindowProcW))> <user32.dll: 13207 (windows/message.c:1868 (User32CallWindowProcFromKernel))> <ntdll.dll: 9124 (rtl/callback.c:36 (KiUserCallbackDispatcher))> <user32.dll: 1df55 (windows/dialog.c:528 (DIALOG_DoDialogBox))> <user32.dll: 1e0f2 (windows/dialog.c:1632 (DialogBoxParamA))> <taskmgr.exe: fa62 (taskmgr.c:109 (WinMain))> <taskmgr.exe: 1242a (graphctl.c:605 (GraphCtrl_WndProc))> <taskmgr.exe: 11e7> <taskmgr.exe: 1258> <kernel32.dll: 26562 (process/create.c:339 (BaseProcessStart))> kdb:> regs CS:EIP 0008:800050d7, EAX 00000004 EBX 00000000 ECX 8013aa10 EDX 00000000 ESI 00000000 EDI 00000000 EBP 9e9eba38 SS:ESP be64:9e9eba78 EFLAGS: IF IOPL0 kdb:> dregs Trap : DR0 00000000 DR1 00000000 DR2 00000000 DR3 00000000 DR6 ffff0ff0 DR7 00 000400 kdb:> cregs CR0: PE MP TS NE WP PG CR1 00000000 CR2 000bf000 CR3 3aa57000 CR4 00000680 TR 9e9eb9c4 LDTR 00000000 kdb:> plist Process list: 308 taskmgr.296 ctm.EXE284 cmd.exe 268 cmd.exe256 explorer244 userinit224 umpnpmgr 208 eventlog192 services160 winlogon132 csrss.ex 104 smss.exe4 System Wow! James

8 20

Re: [ros-dev] makefile naming conventions ( particularly re xml build system )...
by Sylvain Petreolle 11 Mar '05

11 Mar '05

--- Royce Mitchell III <royce3(a)ev1.net> wrote: > Someone mentioned recently that we should name all the xml build system > files makefile.rbuild, or something to that effect. > > I didn't have an opinion at the time, but I have recently developed a > very strong one... > > If all the build system's files are named the same, and if you have 3 of > them open in notepad, you can't tell which is which from the window's > title. This is IMNSHO a bad thing. What do you do when you have 3 "makefile" open in notepad then ? Kind regards, Usurp (aka Sylvain Petreolle) humans are like computers, yesterday the BIOS was all - today its just a word

2 1

makefile naming conventions ( particularly re xml build system )...
by Royce Mitchell III 11 Mar '05

11 Mar '05

Someone mentioned recently that we should name all the xml build system files makefile.rbuild, or something to that effect. I didn't have an opinion at the time, but I have recently developed a very strong one... If all the build system's files are named the same, and if you have 3 of them open in notepad, you can't tell which is which from the window's title. This is IMNSHO a bad thing. Furthermore, in order to be able to invoke make from any directory, instead of just the top-level one, I need to put a "makefile" ( I'm forced to have same name here ) in each directory that punts to the top-level one. Therefore, some of the bootstrap makefiles will need to be renamed out of the way. My plan is to name the bootstrap makefiles thus: tools/tools.mak tools/unicode/unicode.mak ...you get the idea... If we want to rename all the xml files to *.rbuild, that's fine, but I think making them all "makefile.rbuild" is baaaaad. Peace

1 0

0.2.6 Branch
by Robert Köpferl 10 Mar '05

10 Mar '05

Hi, I am looking forward to do a branch next time to release the v0.2.6. There's however still at least one issue pending. The patch from Alex_Ionescu's branch. So we will still wait for a few days. Please tell what else issues there are to not do the branch. And of course when they are resolved.

1 0

Explanation needed on TryToTranslateChar...
by Johannes Olofsson 10 Mar '05

10 Mar '05

Hi! Could somebody help me out and explain how the TryToTranslateChar function in \reactos\subsys\win32k\ntuser\keyboard.c is supposed to work... First there is the following definition: shift = keyLayout->pCharModifiers->ModNumber[ModBits]; which is later used in: CapsMod = shift | ((CapsState & CAPITAL_BIT) ? vkPtr->Attributes : 0); which is used for the translation: *pwcTranslatedChar = vkPtr->wch[CapsMod]; Doesn't shift contain the index for the VK_TO_CHARSx table in the keyboard layout data structure? Why is it then |:ed with vkPtr->Attributes , which I suppose corresponds to the CAPS/NOCAPS constants in the keyboard layout files ? Shouldn't it be something like: shift = keyLayout->pCharModifiers->ModNumber[ModBits ^ ((CapsState & CAPITAL_BIT) ? vkPtr->Attributes : 0]; Regards Johannes Olofsson 10 Gigabyte Mailbox - http://mail.spray.se

2 1

[PATCH] Add full search functionality to ROS regedit
by Jan Schiefer 10 Mar '05

10 Mar '05

This is a full implementation of the regedit search function. :D English and German language available, with other languages the "Find" and "Find next" menu points are still disabled. Come, get some!! :) :) Greetings, Jan Schiefer!

2 7

Re: [ros-dev] Registry and ObjectManager (was FreeLdr Part II)
by Steven Edwards 10 Mar '05

10 Mar '05

Hi, --- Alex Ionescu <ionucu(a)videotron.ca> wrote: > Once again, I hope nobody takes this personally, but I wanted to clear > up the situation. Also I would like everyone to note that I was not trying to be critical of Alex for maintaining his branch. There was a miscommunication about the merge -> branch for 0.2.6 and I should have sent another note to Alex about it before posting here. The lack of merges is in part because of stablity testing and our miscommuication about when would be the best time. Thanks Steven __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/

3 3

Re: [ros-dev] RE: [ros-svn] [sedwards] 13904: imported catch-22 solclone withauthors permission
by Steven Edwards 10 Mar '05

10 Mar '05

Hi, --- Casper Hornstrup <ch(a)csh-consult.dk> wrote: > If it's not going on the cd, why do we need it then? As Gedi said, mainly for releases. We still ship a rosapps package during release time and most of the people I meet at expos always joke about ReactOS needing its own solitaire replacement. For us on the dev teams its not worth the hassle of rebuilding sol everytime we rebuild the source tree. Once rbuild is in place with PCH I will look at importing solitaire to the main module. It may have to wait till gcc-4.x as I really don't want to add more time to the build process than needed. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Sports - Sign up for Fantasy Baseball. http://baseball.fantasysports.yahoo.com/

1 0

RE: [ros-dev] RE: [ros-svn] [sedwards] 13904: imported catch-22 s olclone withauthors permission
by Murphy, Ged (Bolton) 10 Mar '05

10 Mar '05

Can we not just include it into release builds but keep out of /reactos HEAD. It's definitely needed for release builds, but putting it in HEAD just slows down the compile process too much, and unnecessarily, as Steven said. In which case, apps is probably the best place for it. Gedi. -----Original Message----- From: Casper Hornstrup [mailto:ch@csh-consult.dk] Sent: 10 March 2005 16:07 To: 'ReactOS Development List' Subject: [ros-dev] RE: [ros-svn] [sedwards] 13904: imported catch-22 solclone withauthors permission If it's not going on the cd, why do we need it then? Casper ************************************************************************ 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

Re: [ros-dev] RE: [ros-svn] [sedwards] 13904: imported catch-22 sol clone withauthors permission
by Steven Edwards 10 Mar '05

10 Mar '05

Hi, --- Casper Hornstrup <ch(a)csh-consult.dk> wrote: > Doesn't WINE already have one we can share? No it does not. > Why isn't it imported to reactos module so it can get onto the cd? Because it and cardlib are written in C++ and it will add at least another two mins to the build time. If you want to convert it to C be my guest at importing it to the reactos module. > It should be imported as a vendor drop and merged to trunk so we can > track local changes to it and upgrade it easier. The current author has made very little changes to the code in many years. It was just a example of how to used cards.dll using his C++ wrapper "cardlib". Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

RE: [ros-svn] [sedwards] 13904: imported catch-22 sol clone withauthors permission
by Casper Hornstrup 10 Mar '05

10 Mar '05

Doesn't WINE already have one we can share? Why isn't it imported to reactos module so it can get onto the cd? It should be imported as a vendor drop and merged to trunk so we can track local changes to it and upgrade it easier. Casper > -----Original Message----- > From: ros-svn-bounces(a)reactos.com > [mailto:ros-svn-bounces@reactos.com] On Behalf Of > sedwards(a)svn.reactos.com > Sent: 10. marts 2005 05:05 > To: ros-svn(a)reactos.com > Subject: [ros-svn] [sedwards] 13904: imported catch-22 sol > clone withauthors permission > > imported catch-22 sol clone with authors permission

1 0

Bug#492 - Nvidia " IoConnectInterrupt" - Conflict with RTL8139 driver
by Gge 10 Mar '05

10 Mar '05

Hello, After disabling the realtek8139 driver in hivesys.inf , the Nvidia driver can load successfully . Log of the boot available at : http://edou4ever.free.fr/gge/reactos/Nvidia_irq_log_without_RTL8139.txt Please may somebody help on this problem ? Best regards Gerard

1 0

RE: [ros-dev] Registry and ObjectManager (was FreeLdr Part II)
by Steven Edwards 09 Mar '05

09 Mar '05

Hi Casper, --- Casper Hornstrup <ch(a)csh-consult.dk> wrote: > Basicly we have the following situation (and please correct me if I'm wrong). Hartmut spends > some time examining the registry and > object manager problems. Alex has partially rewritten the object manager to fix the problems, > but can't get get further because he > needs to wait for Thomas to finish his handle table implementation. Meanwhile, Thomas seems to > be doing everything but finishing his > handle table implementation. Alex keeps an increasing number of bugfixes (not only bugfixes for > the object manager) on his private > miscelanea branch and thus keeping these bugfixes away from 25 developers and whatever number of > testers we have. The 25 developers > and testers will have to live with these bugs until the branch is merged to trunk which appears > to be several weeks away. Hartmut > seems to be willing to fix the object manager and registry manager bugs on trunk, but if he now > did, he would be duplicating work. I agree 100%. I wanted to branch to 0.2.6 but because these fixes are still not on the trunk I cannot do that. If the fixes are not merged on the trunk so then I propose we go ahead and branch it for 0.2.6 and let the testers have at it. Thanks Steven __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/

1 0

[Fwd: [ros-svn] [navaraf] 13895: Fix failure case in IoConnectInterrupt. - Nvidia driver crash
by Gge 09 Mar '05

09 Mar '05

Filip, I do not know if this patch is related to my nvidia driver 66.93 crash (interrupt registration conflict) but i tested it and no change ... To remember about this problem , i created the bug #522 => May I have feedback from Nvidia users ? Note : The driver version 43.45 worked ok several months ago on my video card. Regards Gerard

1 0

french sysdm translation and some fixes in rc files
by Sylvain Petreolle 09 Mar '05

09 Mar '05

french sysdm translation and some fixes in rc files Kind regards, Usurp (aka Sylvain Petreolle) humans are like computers, yesterday the BIOS was all - today its just a word

1 0

Userland services
by art yerkes 08 Mar '05

08 Mar '05

What are our current options for creating userland services in reactos? We don't seem to have an svchost, so should I make my service a standalone exe for now? Is anybody working on service support? -- 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

4 4

wrc.exe and widl.exe for download
by Boaz Harrosh 08 Mar '05

08 Mar '05

Sorry to be nudging about this but: Will the newly ported wrc.exe & widl.exe be a part of the binutils (Binary & Source) packages available on SourceForge.net ReactOS project? Free Life Boaz

1 0

Assertion in /objects/dc.c
by dolphin_＠gmx.net 08 Mar '05

08 Mar '05

Hello! I have just updates to the latest SVN version and now I have the problem, that I cannot install ReactOS anymore. At the first reboot after installation, I get the following Assertion (cut from debug output): (devinst.c:1008:SetupDiInstallClassW) Assertion 'NewDC->DMW.dmBitsPerPel == BitsPerFormat(SurfObj->iBitmapFormat)' fai led at objects/dc.c line 808 Entered debugger on embedded INT3 at 0x0008:0x80006243. When I ignore this Assertion (by continuing), I can do so serveral times, after that my PC reboots. The error occurs on both QEMU and real HW. I guess this error has something to do with the latest changes. Perhaps someone can verify/fix this (GvG ?). I discoverd one or two other problems too (that have nothing to do with the latest SVN build), but I have to recheck them to ensure they still exist. This is what I've done: I have clicked wildly with the right mouse button on the Desktop background to open the context menu and randomly used the context menu of the Explorer to move the Explorer windows arround in between. When I do this for a couple of seconds, ReactOS crashes. (I posted a BSOD yesterday in IRC, but I guess nobody noticed it, here is the link: http://www.rafb.net/paste/results/kxur3L28.html As I said, I will recheck this in the evening today. Perhaps someone else will have a look on this too. Best regards, Dolphin

2 2

new build system: informal performance test
by Royce Mitchell III 07 Mar '05

07 Mar '05

each test was run from a "mingw32-make clean" or "make clean" tree with KDBG=0 DBG=0 old build system build command: mingw32-make mingw32-make bootcd 21 minutes new build system: make bootcd 11 minutes new build system: make -j 5 bootcd 13 minutes I built the old build system with two separate commands because last time I tried, you could do a "mingw32-make bootcd" from a clean tree. So, besides the other benefits outlined when we started this project, the new build system is cutting build time in half. Now to just fix the remaining bug(s) ;)

7 9

Proposed change to usermode exception reporting
by art yerkes 07 Mar '05

07 Mar '05

I want to change the usermode exception reporter to make stack traces in this form: (KERNEL32:except/except.c:184) 6dc00000+cb991 C:\dl\libgtk-0.dll rather than this from: (KERNEL32:except/except.c:184) 6dccb991 C:\dl\libgtk-0.dll My form is less compact but gives more information (namely, the offset in the target module). It's a simple change but I wanted to see if anyone objected strongly. -- 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

2 1

0.2.6 branch
by Steven Edwards 06 Mar '05

06 Mar '05

Hi, Robert if you are out there I think we want to try to branch for 0.2.6 sometime in the middle of the coming week. Alex is going to merge his changes in to the trunk and then we should be mostly ready. If Robert is not free and no one else wants to do it then I will plan on branching on Wednesday. I expect we can let the 0.2.6 branch run for about a week so lets plan on shipping 0.2.6-final on 2005/03/16. Thanks Steven __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/

1 0

Re: [ros-diffs] [ekohl] 13825: Fix calls to ReadFile and WriteFile for asynchronous I/O.
by Hartmut Birr 06 Mar '05

06 Mar '05

Hi, you should send this mail to the Ros-Dev list because some people with a deal-up connection dosn't read the Ros-Diffs list. - Hartmut Gunnar Dalsnes schrieb: > Eric: Ping? > > Gunnar Dalsnes wrote: > >> From MSDN OVERLAPPED: "Functions such as WriteFile set the event to >> the nonsignaled state before they begin an I/O operation" >> >> So the ResetEvent additions are meaningless... Why did you add them? >> >> Gunnar >> >> ekohl(a)svn.reactos.com wrote: >> >>> Fix calls to ReadFile and WriteFile for asynchronous I/O. >>> >>> Modified: trunk/reactos/lib/rpcrt4/rpc_message.c >>> >>> ------------------------------------------------------------------------ >>> >>> *Modified: trunk/reactos/lib/rpcrt4/rpc_message.c* >>> >>> --- trunk/reactos/lib/rpcrt4/rpc_message.c 2005-03-05 11:27:15 >>> UTC (rev 13824) >>> +++ trunk/reactos/lib/rpcrt4/rpc_message.c 2005-03-05 11:38:48 >>> UTC (rev 13825) >>> @@ -265,10 +265,15 @@ >>> >>> } >>> >>> /* transmit packet header */ >>> >>> - if (!WriteFile(Connection->conn, Header, hdr_size, &count, >>> NULL)) { >>> >>> + ResetEvent(Connection->ovl.hEvent); >>> + if (!WriteFile(Connection->conn, Header, hdr_size, &count, >>> &Connection->ovl)) { >>> >>> WARN("WriteFile failed with error %ld\n", GetLastError()); >>> return GetLastError(); >>> } >>> >>> + if (!GetOverlappedResult(Connection->conn, &Connection->ovl, >>> &count, TRUE)) { >>> + WARN("GetOverlappedResult failed with error %ld\n", >>> GetLastError()); >>> + return GetLastError(); >>> + } >>> >>> >>> /* fragment consisted of header only and is the last one */ >>> if (hdr_size == Header->common.frag_len && >>> @@ -277,10 +282,15 @@ >>> >>> } >>> >>> /* send the fragment data */ >>> >>> - if (!WriteFile(Connection->conn, buffer_pos, >>> Header->common.frag_len - hdr_size, &count, NULL)) { >>> >>> + ResetEvent(Connection->ovl.hEvent); >>> + if (!WriteFile(Connection->conn, buffer_pos, >>> Header->common.frag_len - hdr_size, &count, &Connection->ovl)) { >>> >>> WARN("WriteFile failed with error %ld\n", GetLastError()); >>> return GetLastError(); >>> } >>> >>> + if (!GetOverlappedResult(Connection->conn, &Connection->ovl, >>> &count, TRUE)) { >>> + WARN("GetOverlappedResult failed with error %ld\n", >>> GetLastError()); >>> + return GetLastError(); >>> + } >>> >>> >>> Header->common.flags &= ~RPC_FLG_FIRST; >>> } >>> @@ -309,9 +319,15 @@ >>> >>> TRACE("(%p, %p, %p)\n", Connection, Header, pMsg); >>> >>> /* read packet common header */ >>> >>> - if (!ReadFile(Connection->conn, &common_hdr, sizeof(common_hdr), >>> &dwRead, NULL)) { >>> >>> + ResetEvent(Connection->ovl.hEvent); >>> + if (!ReadFile(Connection->conn, &common_hdr, sizeof(common_hdr), >>> &dwRead, &Connection->ovl)) { >>> + WARN("ReadFile failed with error %ld\n", GetLastError()); >>> + status = RPC_S_PROTOCOL_ERROR; >>> + goto fail; >>> + } >>> + if (!GetOverlappedResult(Connection->conn, &Connection->ovl, >>> &dwRead, TRUE)) { >>> >>> if (GetLastError() != ERROR_MORE_DATA) { >>> >>> - WARN("ReadFile failed with error %ld\n", GetLastError()); >>> >>> + WARN("GetOverlappedResult failed with error %ld\n", >>> GetLastError()); >>> >>> status = RPC_S_PROTOCOL_ERROR; >>> goto fail; >>> } >>> @@ -339,10 +355,16 @@ >>> >>> memcpy(*Header, &common_hdr, sizeof(common_hdr)); >>> >>> /* read the rest of packet header */ >>> >>> + ResetEvent(Connection->ovl.hEvent); >>> >>> if (!ReadFile(Connection->conn, &(*Header)->common + 1, >>> >>> - hdr_length - sizeof(common_hdr), &dwRead, NULL)) { >>> >>> + hdr_length - sizeof(common_hdr), &dwRead, >>> &Connection->ovl)) { >>> + WARN("ReadFile failed with error %ld\n", GetLastError()); >>> + status = RPC_S_PROTOCOL_ERROR; >>> + goto fail; >>> + } >>> + if (!GetOverlappedResult(Connection->conn, &Connection->ovl, >>> &dwRead, TRUE)) { >>> >>> if (GetLastError() != ERROR_MORE_DATA) { >>> >>> - WARN("ReadFile failed with error %ld\n", GetLastError()); >>> >>> + WARN("GetOverlappedResult failed with error %ld\n", >>> GetLastError()); >>> >>> status = RPC_S_PROTOCOL_ERROR; >>> goto fail; >>> } >>> @@ -352,6 +374,7 @@ >>> >>> goto fail; >>> } >>> >>> >>> + >>> >>> /* read packet body */ >>> switch (common_hdr.ptype) { >>> case PKT_RESPONSE: >>> @@ -379,13 +402,20 @@ >>> >>> goto fail; >>> } >>> >>> >>> - if (data_length == 0) dwRead = 0; else >>> - if (!ReadFile(Connection->conn, buffer_ptr, data_length, >>> &dwRead, NULL)) { >>> - if (GetLastError() != ERROR_MORE_DATA) { >>> >>> + if (data_length == 0) dwRead = 0; else { >>> + ResetEvent(Connection->ovl.hEvent); >>> + if (!ReadFile(Connection->conn, buffer_ptr, data_length, >>> &dwRead, &Connection->ovl)) { >>> >>> WARN("ReadFile failed with error %ld\n", GetLastError()); >>> status = RPC_S_PROTOCOL_ERROR; >>> goto fail; >>> } >>> >>> + if (!GetOverlappedResult(Connection->conn, &Connection->ovl, >>> &dwRead, TRUE)) { >>> + if (GetLastError() != ERROR_MORE_DATA) { >>> + WARN("GetOverlappedResult failed with error %ld\n", >>> GetLastError()); >>> + status = RPC_S_PROTOCOL_ERROR; >>> + goto fail; >>> + } >>> + } >>> >>> } >>> if (dwRead != data_length) { >>> status = RPC_S_PROTOCOL_ERROR; >>> @@ -403,10 +433,16 @@ >>> >>> TRACE("next header\n"); >>> >>> /* read the header of next packet */ >>> >>> - if (!ReadFile(Connection->conn, *Header, hdr_length, &dwRead, >>> NULL)) { >>> >>> + ResetEvent(Connection->ovl.hEvent); >>> + if (!ReadFile(Connection->conn, *Header, hdr_length, &dwRead, >>> &Connection->ovl)) { >>> + WARN("ReadFile failed with error %ld\n", GetLastError()); >>> + status = GetLastError(); >>> + goto fail; >>> + } >>> + if (!GetOverlappedResult(Connection->conn, &Connection->ovl, >>> &dwRead, TRUE)) { >>> >>> if (GetLastError() != ERROR_MORE_DATA) { >>> >>> - WARN("ReadFile failed with error %ld\n", GetLastError()); >>> - status = GetLastError(); >>> >>> + WARN("GetOverlappedResult failed with error %ld\n", >>> GetLastError()); >>> + status = RPC_S_PROTOCOL_ERROR; >>> >>> goto fail; >>> } >>> } >>> >>> >>> ------------------------------------------------------------------------ >>> >>>

2 1

Re: [ros-svn] [ion] 13847: Merge with 13846. Fixes QEMU+KDBG problem.
by James Tabor 06 Mar '05

06 Mar '05

Hi! ion(a)svn.reactos.com wrote: > Merge with 13846. Fixes QEMU+KDBG problem. > > > Added files: > branches/alex_devel_branch/reactos/media/drivers/etc/KDBinit > > Updated files: > branches/alex_devel_branch/reactos/Makefile > branches/alex_devel_branch/reactos/ntoskrnl/dbg/kdb.h > branches/alex_devel_branch/reactos/ntoskrnl/dbg/kdb_cli.c > branches/alex_devel_branch/reactos/ntoskrnl/dbg/kdb_keyboard.c > branches/alex_devel_branch/reactos/ntoskrnl/dbg/kdb_serial.c > > Deleted files: > branches/alex_devel_branch/reactos/media/drivers/etc/KDB.init > I think is is caused by blight patch. Gcc 3.4.2 bin utils 2.15.94. ntoskrnl: [CC] dbg/kdb_cli.c dbg/kdb_cli.c: In function `KdbpPrint': dbg/kdb_cli.c:1721: warning: implicit declaration of function `isalpha' make[1]: *** [dbg/kdb_cli.o] Error 1 make: *** [ntoskrnl] Error 2 Thanks, James

2 3

Build ros on ros is broken
by Hartmut Birr 06 Mar '05

06 Mar '05

Hi, since my last svn update, I'm not able to compile ros on ros. It seems that something is wrong with the pipes. - Hartmut f:\Sandbox\Ros\ReactOS>_make ReactOS Build Number Generator Current date : 2005-03-06 ROS Version : 0.3-CVS (build 20050306) ar: creating zlib.host.a ntoskrnl: [DLLTOOL] libntoskrnl.a hal: [CC] hal.c gcc: pipe: Invalid argument (EINVAL) _make[1]: *** [hal.o] Error 1 _make: *** [hallib] Error 2

2 5

Re: Re: Re: [ros-dev] added a proposed patch to bugzilla
by Roman Hoegg 06 Mar '05

06 Mar '05

1 0

Re: [ros-svn] [blight] 13841: Little KDB update ; -) If you have any problems and/or questions let me know. I hope it was tested enough and works well enough for everybody.
by Hartmut Birr 06 Mar '05

06 Mar '05

Hi, compiling fails if KDBG = 0 and DBG = 1. objects/ke.o: In function `InitializeListHead': M:/Sandbox/ros_work/reactos/ntoskrnl/../include/ntos/rtl.h:96: undefined reference to `KdbInit' objects/ps.o: In function `PsUnlockProcess': M:/Sandbox/ros_work/reactos/ntoskrnl/ps/process.c:2973: undefined reference to `KdbDeleteProcessHook' collect2: ld returned 1 exit status _make[1]: *** [ntoskrnl.nostrip.exe] Error 1 _make: *** [ntoskrnl] Error 2 - Hartmut blight(a)svn.reactos.com schrieb: >Little KDB update ;-) If you have any problems and/or questions let me know. I hope it was tested enough and works well enough for everybody. > > >Added files: >trunk/reactos/media/drivers/etc/KDB.init >trunk/reactos/ntoskrnl/dbg/i386/longjmp.S >trunk/reactos/ntoskrnl/dbg/i386/setjmp.S >trunk/reactos/ntoskrnl/dbg/kdb_cli.c >trunk/reactos/ntoskrnl/dbg/kdb_expr.c >trunk/reactos/ntoskrnl/dbg/kdb_string.c > >Updated files: >trunk/reactos/Makefile >trunk/reactos/drivers/input/keyboard/keyboard.c >trunk/reactos/ntoskrnl/Makefile >trunk/reactos/ntoskrnl/dbg/i386/i386-dis.c >trunk/reactos/ntoskrnl/dbg/i386/kdb_help.S >trunk/reactos/ntoskrnl/dbg/kdb.c >trunk/reactos/ntoskrnl/dbg/kdb.h >trunk/reactos/ntoskrnl/dbg/kdb_keyboard.c >trunk/reactos/ntoskrnl/dbg/kdb_serial.c >trunk/reactos/ntoskrnl/dbg/kdb_symbols.c >trunk/reactos/ntoskrnl/include/internal/i386/ke.h >trunk/reactos/ntoskrnl/include/internal/kd.h >trunk/reactos/ntoskrnl/ke/catch.c >trunk/reactos/ntoskrnl/ke/i386/trap.s >trunk/reactos/ntoskrnl/ke/i386/tskswitch.S >trunk/reactos/ntoskrnl/ke/kthread.c >trunk/reactos/ntoskrnl/ke/main.c >trunk/reactos/ntoskrnl/ps/w32call.c > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > > >

1 0

ATTN CASPER: case-conflicts in svn
by Royce Mitchell III 06 Mar '05

06 Mar '05

Casper: could we please have this hook installed in the svn server?: http://svn.collab.net/viewcvs/svn/trunk/contrib/hook-scripts/check-case-ins…

1 0

Boot Failure after Merging...
by Alex Ionescu 06 Mar '05

06 Mar '05

I'm getting this after merging... Filip/Eric, this seems to be related to your changes...any clue? Assertion Irp->CancelRoutine == NULL failed at io/irp.c:310 Best regards, Alex Ionescu

2 1

Re: [ros-svn] [ion] 13842: Merge with blight's rewrite
by James Tabor 06 Mar '05

06 Mar '05

Hi Alex! Good job! I let the testing go on through the night (23 hours) and started testing your last commit, it's running great! ion(a)svn.reactos.com wrote: > Merge with blight's rewrite > > > Added files: > branches/alex_devel_branch/reactos/media/drivers/etc/KDB.init > branches/alex_devel_branch/reactos/ntoskrnl/dbg/i386/longjmp.S > branches/alex_devel_branch/reactos/ntoskrnl/dbg/i386/setjmp.S > branches/alex_devel_branch/reactos/ntoskrnl/dbg/kdb_cli.c > branches/alex_devel_branch/reactos/ntoskrnl/dbg/kdb_expr.c > branches/alex_devel_branch/reactos/ntoskrnl/dbg/kdb_string.c > > Updated files: > branches/alex_devel_branch/reactos/Makefile > branches/alex_devel_branch/reactos/drivers/input/keyboard/keyboard.c > branches/alex_devel_branch/reactos/ntoskrnl/Makefile > branches/alex_devel_branch/reactos/ntoskrnl/dbg/i386/i386-dis.c > branches/alex_devel_branch/reactos/ntoskrnl/dbg/i386/kdb_help.S > branches/alex_devel_branch/reactos/ntoskrnl/dbg/kdb.c > branches/alex_devel_branch/reactos/ntoskrnl/dbg/kdb.h > branches/alex_devel_branch/reactos/ntoskrnl/dbg/kdb_keyboard.c > branches/alex_devel_branch/reactos/ntoskrnl/dbg/kdb_serial.c > branches/alex_devel_branch/reactos/ntoskrnl/dbg/kdb_symbols.c > branches/alex_devel_branch/reactos/ntoskrnl/include/internal/i386/ke.h > branches/alex_devel_branch/reactos/ntoskrnl/include/internal/kd.h > branches/alex_devel_branch/reactos/ntoskrnl/io/iomgr.c > branches/alex_devel_branch/reactos/ntoskrnl/ke/catch.c > branches/alex_devel_branch/reactos/ntoskrnl/ke/i386/trap.s > branches/alex_devel_branch/reactos/ntoskrnl/ke/i386/tskswitch.S > branches/alex_devel_branch/reactos/ntoskrnl/ke/kthread.c > branches/alex_devel_branch/reactos/ntoskrnl/ke/main.c > branches/alex_devel_branch/reactos/ntoskrnl/ps/w32call.c > BTW, I'm getting this; ntoskrnl: [CC] ke/kthread.c ke/kthread.c: In function `KeInitializeThread': ke/kthread.c:254: error: too many arguments to function `RtlZeroMemory' ke/kthread.c:266: error: too many arguments to function `RtlZeroMemory' ke/kthread.c:267: error: too many arguments to function `RtlZeroMemory' make[1]: *** [ke/kthread.o] Error 1 make: *** [ntoskrnl] Error 2 Thanks, James

1 0

Are there any plans for apache + svn?
by Waldo Alvarez Cañizares 05 Mar '05

05 Mar '05

Hi guys: I was reading about subversion an in fact installed one svn server because I think that I could benefict from using a versioning system even doing non collaborative programming. Now the part that is related with ReactOS is that svn can be used locally, lite svnserve and (apache + svn modules) concurrently. I beleive you are using only or mostly: svn://svn.reactos.com/ Are there any chances for us the firewalled to get an apache 2.x listening on port 80? I know you are using apache 1.3.x in www.reactos.com but the configuration should be very similar. I never mentioned anything like this when CVS because it was probably too wuch work for those administrating CVS but hey SVN is modern so it comes ready for it with little effort. So it won´t affect those using the subversion protocol directly. I always had intention to collaborate but never got the chance. I could never do proper checkouts from CVS using tunnels but this way will be direct so probably this could be my chance to get in and maybe get write acces after learning more about svn using it locally on my machine. Thanks in advance Regards Waldo Alvarez

3 2

RE: [ros-svn] [mf] 13830: add ibrowser to XML build
by Casper Hornstrup 05 Mar '05

05 Mar '05

There is no need to update this branch since I'll merge changes from trunk once in a while. Also, always be sure to use svn merge to merge changes from trunk to the branches so subversion knows where the changes comes from. If done, then we are less likely to get conflicts in a future merge. Casper > -----Original Message----- > From: ros-svn-bounces(a)reactos.com > [mailto:ros-svn-bounces@reactos.com] On Behalf Of mf(a)svn.reactos.com > Sent: 5. marts 2005 18:52 > To: ros-svn(a)reactos.com > Subject: [ros-svn] [mf] 13830: add ibrowser to XML build > > add ibrowser to XML build > > > > Added files: > branches/xmlbuildsystem/reactos/subsys/system/ibrowser/ibrowser.xml > > Updated files: > branches/xmlbuildsystem/reactos/bootdata/packages/reactos.dff > branches/xmlbuildsystem/reactos/subsys/system/directory.xml > branches/xmlbuildsystem/reactos/subsys/system/ibrowser/Makefile > > _______________________________________________ > Ros-svn mailing list > Ros-svn(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-svn

2 2

Re: [ros-svn] [mf] 13828: tag ReactOS 0.2.5 release
by Jason Filby 05 Mar '05

05 Mar '05

Thanks - but this should be 0.2.6 shouldn't it? Jason On Sat, 5 Mar 2005 16:38:22 +0100, mf(a)svn.reactos.com <mf(a)svn.reactos.com> wrote: > tag ReactOS 0.2.5 release > > Added files: > tags/ReactOS-0.2.5/

2 1

Alex has fixed the laptop problem
by Steven Edwards 05 Mar '05

05 Mar '05

When he merges with the tip I am really ready for 0.2.6 Thanks Steven __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/

5 16

make clean compiles wpp/unicode everytime
by Sylvain Petreolle 05 Mar '05

05 Mar '05

make clean needs unicode and wpp atm, this is why it does : unicode&wpp compilation [clean process] but at the ends it does: wpp&unicode clean Every time you run make clean, unicode& wpp are removed & compiled, even if you didnt compile anything else ! Sh(C)ouldnt we avoid this ? ===== Usurp (aka Sylvain Petreolle) humans are like computers, yesterday the BIOS was all - today its just a word

1 0

ACPI loading when ACPI=0
by Jason Filby 05 Mar '05

05 Mar '05

Hi all I have a situation, under QEMU, when ACPI loading when ACPI=0 is specified in the config file. The problem is that the acpi.sys driver is crashing. When booting from the boot CD everything works properly (not sure if acpi.sys is loaded) and ReactOS installs. But booting from that installation sees the failed acpi.sys. Is there something about our installation process that ignores ACPI=0 in the config file? Thanks Jason

1 0

Re: [ros-svn] [royce] 13823: per-module clean rules, make cabman more *nix/msys friendly
by Royce Mitchell III 05 Mar '05

05 Mar '05

royce(a)svn.reactos.com wrote: >per-module clean rules, make cabman more *nix/msys friendly >This fix made it so I was able to successfully build a 22.4MB ReactOS.iso from the xmlbuildsystem branch! ( now to test it... ) > > The bootcd fails to boot because freeldr.sys and setupldr.sys are missing out of the LOADER block of the ISO. I'm sure we're just not passing the right parameters, but I'm going to bed, so if someone gets a chance to look at it... we may have a working bootcd from the xml build system before the end of this weekend. Kudos to Casper!!!

1 0

Patch - fix my stupid mistake
by Steven Edwards 05 Mar '05

05 Mar '05

at the time I did not know what /BOOTLOG did vs /DEBUGPORT=FILE This patch corrects it. Its verses Alexs tree as my main ReactOS tree is hosed. Someone please apply to the trunk. Thanks Steven __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/

2 1

RE: [ros-dev] Changelog 0.2.6 Release.
by Waldo Alvarez Cañizares 04 Mar '05

04 Mar '05

Hi Harmunt: I remember the solution for this was Bochs + Hardisk images using sparse files. From: ros-dev-bounces(a)reactos.com on behalf of Hartmut Birr Sent: Wed 3/2/2005 3:01 PM To: ReactOS Development List Subject: Re: [ros-dev] Changelog 0.2.6 Release. michael(a)fritscher.net schrieb: >Hmm, I think we shouldn't release 0.2.6 until ros can boot from the first >128 GB from a over 128 GB HDD again, because I think that's a big >regression > > Hi, I can implement the large LBA addressing mode in atapi. But I cannot test it, because my largest ide disk is only 120GB. - Hartmut

1 0

Re: Re: Re: [ros-dev] added a proposed patch to bugzilla
by Johannes Olofsson 04 Mar '05

04 Mar '05

Hi! What is the output (with the changed line) when the key is pressed, whithout a modifier key, with shift, with caps lock, with caps lock + shift and with alt gr? Regards Johannes Olofsson > Från: Roman Hoegg <roman.hoegg(a)unisg.ch> > Till: ReactOS Development List <ros-dev(a)reactos.com> > Rubrik: Re: Re: [ros-dev] added a proposed patch to bugzilla > Datum: Wed, 2 Mar 2005 20:58:46 +0100 > Try to change the line : > /* none, shift, ctrl-alt, ctrl, ctrl-shift */ > { VK_OEM_7, NOCAPS, 0xe4, 0xe0, 0x7b, WCH_NONE, 0x00 }, /* ä à { */ > to: > { VK_OEM_7, KCTRL, 'code for ä', 'code for à', 0x7b, 'code for Ä', 'code for À }, /* ä à { */ > in order to use the ctrl and ctrl-shift states for caps lock for this key. thanks for the help. What you suggest here actually works (I've just tested it). However, what it does is it makes Ctrl to behave the way CapsLock should behave and turns CapsLock into AltGr (strange...). That's not how my keyboard acts on other OS'. I really think there should be a way to differentiate between CapsLock and Shift. I'm sure that there will also be other keyboards that need that in the future. thanks! Roman Högg_______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev Otur i kärlek - http://www.spray.se/spel Tur i kärlek - http://www.spraydate.com

1 0

Re: [ros-diffs] [arty] 13810: Some warning suppression. Read the<rant/>.
by d_layer 04 Mar '05

04 Mar '05

Hi, Actually this is a designed behavior of -Wconversion and not a bug. http://gcc.gnu.org/ml/gcc/2002-12/msg01431.html -- d_layer arty(a)svn.reactos.com wrote: > + * <rant> > + * These fix the following warning in GCC: > + * warning: passing arg 1 of `ntohs' with different width due to > prototype > + * > + * Even if you declare an unsigned char or unsigned short variable and > pass > + * it to htons or ntohs, this warning will be generated. I believe > this is > + * a gcc bug. You can try to reproduce the bug like this: > + * > + * u_short foo(u_short bar) { > + * return htons(bar); > + * } > + * > + * Using the reactos compiler settings this generates the error. > Unless I'm > + * missing something, the active prototypes for htons and ntohs are: > + * > + * u_short PASCAL htons(u_short); > + * u_short PASCAL ntohs(u_short); > + * > + * From winsock2.h. Since the function above has exactly the same > signature > + * as htons except for the required PASCAL (__stdcall) decoration, gcc > is > + * erroneously detecting a narrowed value. > + * </rant>

2 1

Re: [ros-diffs] [ion] 13813: Fix queue item not being cleaned. Thank you Jim
by Filip Navara 04 Mar '05

04 Mar '05

ion(a)svn.reactos.com wrote: >Fix queue item not being cleaned. Thank you Jim > >Modified: branches/alex_devel_branch/reactos/ntoskrnl/ke/queue.c > > > ------------------------------------------------------------------------ > *Modified: branches/alex_devel_branch/reactos/ntoskrnl/ke/queue.c* > >--- branches/alex_devel_branch/reactos/ntoskrnl/ke/queue.c 2005-03-04 04:10:03 UTC (rev 13812) >+++ branches/alex_devel_branch/reactos/ntoskrnl/ke/queue.c 2005-03-04 04:15:46 UTC (rev 13813) >@@ -207,7 +207,7 @@ > > > /* Remove the Entry */ > RemoveEntryList(ListEntry); > > >- Entry->Flink = NULL; > > >+ ListEntry->Flink = NULL; > > > > /* Nothing to wait on */ > break; > > This looks wrong. You should never clean list item this way, instead you should use "InitializeListHead(ListEntry);". - Filip

2 2

Mission X03-02: Recover Ancient Cutler Artifact
by Alex Ionescu 04 Mar '05

04 Mar '05

2 1

atapi patch for test / review
by Hartmut Birr 04 Mar '05

04 Mar '05

Hi, I've add 48bit support to atapi. I cannot test the 48bit support. Please test it. Be careful. If something is wrong, atapi can corrupt other partitions on the same disk. - Hartmut M:\Sandbox\ros_work\reactos>set SVN_EDITOR=notepad M:\Sandbox\ros_work\reactos>d:\programme\subversion\bin\svn.exe diff drivers\storage\atapi Index: drivers/storage/atapi/atapi.c =================================================================== --- drivers/storage/atapi/atapi.c (revision 13795) +++ drivers/storage/atapi/atapi.c (working copy) @@ -1327,6 +1327,8 @@ DrvParms->TMSectorCountHi, DrvParms->TMSectorCountLo, (ULONG)((DrvParms->TMSectorCountHi << 16) + DrvParms->TMSectorCountLo)); + DPRINT1("SupportedFeatures83: %x, SupportedFeatures84 %x\n", DrvParms->SupportedFeatures83, DrvParms->SupportedFeatures84); + DPRINT1("Max48BitAddress: %I64d\n", *(PULONGLONG)DrvParms->Max48BitAddress); if (DrvParms->TMFieldsValid & 0x0004) { if ((DrvParms->UltraDmaModes >> 8) && (DrvParms->UltraDmaModes & 0xff)) @@ -1952,7 +1954,7 @@ { PREAD_CAPACITY_DATA CapacityData; PIDE_DRIVE_IDENTIFY DeviceParams; - ULONG LastSector; + LARGE_INTEGER LastSector; DPRINT("SCSIOP_READ_CAPACITY: TargetId: %lu\n", Srb->TargetId); CapacityData = (PREAD_CAPACITY_DATA)Srb->DataBuffer; @@ -1964,15 +1966,34 @@ /* Calculate last sector (big-endian). */ if (DeviceParams->Capabilities & IDE_DRID_LBA_SUPPORTED) { - LastSector = (ULONG)((DeviceParams->TMSectorCountHi << 16) + - DeviceParams->TMSectorCountLo) - 1; + if (DeviceExtension->DeviceFlags[Srb->TargetId] & DEVICE_48BIT_ADDRESS) + { + ((PUSHORT)&LastSector)[0] = DeviceParams->Max48BitAddress[0]; + ((PUSHORT)&LastSector)[1] = DeviceParams->Max48BitAddress[1]; + ((PUSHORT)&LastSector)[2] = DeviceParams->Max48BitAddress[2]; + ((PUSHORT)&LastSector)[3] = DeviceParams->Max48BitAddress[3]; + LastSector.QuadPart -= 1; + + } + else + { + LastSector.u.HighPart = 0; + LastSector.u.LowPart = (ULONG)((DeviceParams->TMSectorCountHi << 16) + + DeviceParams->TMSectorCountLo)-1; + } } else { - LastSector = (ULONG)(DeviceParams->LogicalCyls * - DeviceParams->LogicalHeads * - DeviceParams->SectorsPerTrack)-1; + LastSector.u.HighPart = 0; + LastSector.u.LowPart = (ULONG)(DeviceParams->LogicalCyls * + DeviceParams->LogicalHeads * + DeviceParams->SectorsPerTrack)-1; } + if (LastSector.u.HighPart) + { + DPRINT1("Disk is too large for our implementation (%I64d sectors\n", LastSector.QuadPart); + KEBUGCHECK(0); + } CapacityData->LogicalBlockAddress = (((PUCHAR)&LastSector)[0] << 24) | (((PUCHAR)&LastSector)[1] << 16) | @@ -2003,6 +2024,7 @@ UCHAR Command; ULONG Retries; UCHAR Status; + UCHAR Regs[10]; BOOLEAN FASTCALL (*Handler)(PATAPI_MINIPORT_EXTENSION DevExt); DPRINT("AtapiReadWrite() called!\n"); @@ -2027,12 +2049,28 @@ if (DeviceParams->Capabilities & IDE_DRID_LBA_SUPPORTED) { - SectorNumber = StartingSector & 0xff; - CylinderLow = (StartingSector >> 8) & 0xff; - CylinderHigh = (StartingSector >> 16) & 0xff; - DrvHead = ((StartingSector >> 24) & 0x0f) | - (Srb->TargetId ? IDE_DH_DRV1 : 0) | - IDE_DH_LBA; + if (DeviceExtension->DeviceFlags[Srb->TargetId] & DEVICE_48BIT_ADDRESS) + { + Regs[0] = 0; + Regs[1] = 0; + Regs[2] = SectorCount & 0xff; + Regs[3] = (SectorCount >> 8) & 0xff; + Regs[4] = StartingSector & 0xff; + Regs[5] = (StartingSector >> 8) & 0xff; + Regs[6] = (StartingSector >> 16) & 0xff; + Regs[7] = (StartingSector >> 24) & 0xff; + Regs[8] = 0; + Regs[9] = 0; + } + else + { + SectorNumber = StartingSector & 0xff; + CylinderLow = (StartingSector >> 8) & 0xff; + CylinderHigh = (StartingSector >> 16) & 0xff; + DrvHead = ((StartingSector >> 24) & 0x0f) | + (Srb->TargetId ? IDE_DH_DRV1 : 0) | + IDE_DH_LBA; + } } else { @@ -2119,13 +2157,33 @@ #endif /* Setup command parameters */ - IDEWritePrecomp(DeviceExtension->CommandPortBase, 0); - IDEWriteSectorCount(DeviceExtension->CommandPortBase, SectorCount); - IDEWriteSectorNum(DeviceExtension->CommandPortBase, SectorNumber); - IDEWriteCylinderHigh(DeviceExtension->CommandPortBase, CylinderHigh); - IDEWriteCylinderLow(DeviceExtension->CommandPortBase, CylinderLow); - IDEWriteDriveHead(DeviceExtension->CommandPortBase, IDE_DH_FIXED | DrvHead); + if (DeviceExtension->DeviceFlags[Srb->TargetId] & DEVICE_48BIT_ADDRESS) + { + IDEWritePrecomp(DeviceExtension->CommandPortBase, Regs[1]); + IDEWriteSectorCount(DeviceExtension->CommandPortBase, Regs[3]); + IDEWriteSectorNum(DeviceExtension->CommandPortBase, Regs[7]); + IDEWriteCylinderLow(DeviceExtension->CommandPortBase, Regs[8]); + IDEWriteCylinderHigh(DeviceExtension->CommandPortBase, Regs[9]); + IDEWritePrecomp(DeviceExtension->CommandPortBase, Regs[0]); + IDEWriteSectorCount(DeviceExtension->CommandPortBase, Regs[2]); + IDEWriteSectorNum(DeviceExtension->CommandPortBase, Regs[4]); + IDEWriteCylinderLow(DeviceExtension->CommandPortBase, Regs[5]); + IDEWriteCylinderHigh(DeviceExtension->CommandPortBase, Regs[6]); + + IDEWriteDriveHead(DeviceExtension->CommandPortBase, IDE_DH_FIXED); + + } + else + { + IDEWritePrecomp(DeviceExtension->CommandPortBase, 0); + IDEWriteSectorCount(DeviceExtension->CommandPortBase, SectorCount); + IDEWriteSectorNum(DeviceExtension->CommandPortBase, SectorNumber); + IDEWriteCylinderHigh(DeviceExtension->CommandPortBase, CylinderHigh); + IDEWriteCylinderLow(DeviceExtension->CommandPortBase, CylinderLow); + IDEWriteDriveHead(DeviceExtension->CommandPortBase, IDE_DH_FIXED | DrvHead); + } + #ifdef ENABLE_DMA if (DeviceExtension->PRDTable && DeviceExtension->DeviceFlags[Srb->TargetId] & DEVICE_DMA_CMD) @@ -2135,7 +2193,14 @@ if (DeviceExtension->UseDma) { Handler = AtapiDmaInterrupt; - Command = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? IDE_CMD_READ_DMA : IDE_CMD_WRITE_DMA; + if (DeviceExtension->DeviceFlags[Srb->TargetId] & DEVICE_48BIT_ADDRESS) + { + Command = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? IDE_CMD_READ_DMA_EXT : IDE_CMD_WRITE_DMA_EXT; + } + else + { + Command = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? IDE_CMD_READ_DMA : IDE_CMD_WRITE_DMA; + } } else #endif @@ -2143,11 +2208,25 @@ Handler = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? AtapiReadInterrupt : AtapiWriteInterrupt; if (DeviceExtension->DeviceFlags[Srb->TargetId] & DEVICE_MULTI_SECTOR_CMD) { - Command = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? IDE_CMD_READ_MULTIPLE : IDE_CMD_WRITE_MULTIPLE; + if (DeviceExtension->DeviceFlags[Srb->TargetId] & DEVICE_48BIT_ADDRESS) + { + Command = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? IDE_CMD_READ_MULTIPLE_EXT : IDE_CMD_WRITE_MULTIPLE_EXT; + } + else + { + Command = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? IDE_CMD_READ_MULTIPLE : IDE_CMD_WRITE_MULTIPLE; + } } else { - Command = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? IDE_CMD_READ : IDE_CMD_WRITE; + if (DeviceExtension->DeviceFlags[Srb->TargetId] & DEVICE_48BIT_ADDRESS) + { + Command = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? IDE_CMD_READ_EXT : IDE_CMD_WRITE_EXT; + } + else + { + Command = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? IDE_CMD_READ : IDE_CMD_WRITE; + } } } @@ -2274,7 +2353,9 @@ ScsiPortStallExecution(10); /* Issue command to drive */ - AtapiExecuteCommand(DeviceExtension, IDE_CMD_FLUSH_CACHE, AtapiNoDataInterrupt); + AtapiExecuteCommand(DeviceExtension, + DeviceExtension->DeviceFlags[Srb->TargetId] & DEVICE_48BIT_ADDRESS ? IDE_CMD_FLUSH_CACHE_EXT : IDE_CMD_FLUSH_CACHE, + AtapiNoDataInterrupt); /* Wait for controller ready */ for (Retries = 0; Retries < IDE_MAX_WRITE_RETRIES; Retries++) Index: drivers/storage/atapi/atapi.h =================================================================== --- drivers/storage/atapi/atapi.h (revision 13795) +++ drivers/storage/atapi/atapi.h (working copy) @@ -64,21 +64,27 @@ #define IDE_REG_COMMAND 0x0007 /* IDE/ATA commands */ -#define IDE_CMD_RESET 0x08 -#define IDE_CMD_READ 0x20 -#define IDE_CMD_READ_RETRY 0x21 -#define IDE_CMD_WRITE 0x30 -#define IDE_CMD_WRITE_RETRY 0x31 -#define IDE_CMD_PACKET 0xA0 -#define IDE_CMD_READ_MULTIPLE 0xC4 -#define IDE_CMD_WRITE_MULTIPLE 0xC5 -#define IDE_CMD_READ_DMA 0xC8 -#define IDE_CMD_WRITE_DMA 0xCA -#define IDE_CMD_FLUSH_CACHE 0xE7 -#define IDE_CMD_FLUSH_CACHE_EXT 0xEA -#define IDE_CMD_IDENT_ATA_DRV 0xEC -#define IDE_CMD_IDENT_ATAPI_DRV 0xA1 -#define IDE_CMD_GET_MEDIA_STATUS 0xDA +#define IDE_CMD_RESET 0x08 +#define IDE_CMD_READ 0x20 +#define IDE_CMD_READ_ONCE 0x21 +#define IDE_CMD_READ_EXT 0x24 /* 48 bit */ +#define IDE_CMD_READ_DMA_EXT 0x25 /* 48 bit */ +#define IDE_CMD_READ_MULTIPLE_EXT 0x29 /* 48 bit */ +#define IDE_CMD_WRITE 0x30 +#define IDE_CMD_WRITE_ONCE 0x31 +#define IDE_CMD_WRITE_EXT 0x34 /* 48 bit */ +#define IDE_CMD_WRITE_DMA_EXT 0x35 /* 48 bit */ +#define IDE_CMD_WRITE_MULTIPLE_EXT 0x39 /* 48 bit */ +#define IDE_CMD_PACKET 0xA0 +#define IDE_CMD_READ_MULTIPLE 0xC4 +#define IDE_CMD_WRITE_MULTIPLE 0xC5 +#define IDE_CMD_READ_DMA 0xC8 +#define IDE_CMD_WRITE_DMA 0xCA +#define IDE_CMD_FLUSH_CACHE 0xE7 +#define IDE_CMD_FLUSH_CACHE_EXT 0xEA /* 48 bit */ +#define IDE_CMD_IDENT_ATA_DRV 0xEC +#define IDE_CMD_IDENT_ATAPI_DRV 0xA1 +#define IDE_CMD_GET_MEDIA_STATUS 0xDA // // Access macros for command registers

2 5

[Fwd: Re: [ros-dev] atapi patch for test / review - failure]
by Hartmut Birr 04 Mar '05

04 Mar '05

Send it again with the correct date... Hi, I've fixed the problem. Please try it again. - Hartmut Hartmut Birr schrieb: >michael(a)fritscher.net schrieb: > > > >>Seems to be a bug betweeb VMware 4.5.2 and ros, because on real HW it >>works well (almost, because I get a BSOD during the reboot after be second >>stage install, yust after clicking the reboot-botton) >> >> >> >> >> >It's not a bug in vmware. I've made a little mistake. The drive head >register isn't set correctly in 48bit mode. I've update my old vmware >beta. I will send a new patch if it works in vmware. > >- Hartmut > > > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-dev > > > > M:\Sandbox\ros_work\reactos>set SVN_EDITOR=notepad M:\Sandbox\ros_work\reactos>d:\programme\subversion\bin\svn.exe diff drivers\storage\atapi Index: drivers/storage/atapi/atapi.c =================================================================== --- drivers/storage/atapi/atapi.c (revision 13806) +++ drivers/storage/atapi/atapi.c (working copy) @@ -1327,6 +1327,8 @@ DrvParms->TMSectorCountHi, DrvParms->TMSectorCountLo, (ULONG)((DrvParms->TMSectorCountHi << 16) + DrvParms->TMSectorCountLo)); + DPRINT1("SupportedFeatures83: %x, EnabledFeatures86 %x\n", DrvParms->SupportedFeatures83, DrvParms->EnabledFeatures86); + DPRINT1("Max48BitAddress: %I64d\n", *(PULONGLONG)DrvParms->Max48BitAddress); if (DrvParms->TMFieldsValid & 0x0004) { if ((DrvParms->UltraDmaModes >> 8) && (DrvParms->UltraDmaModes & 0xff)) @@ -1952,7 +1954,7 @@ { PREAD_CAPACITY_DATA CapacityData; PIDE_DRIVE_IDENTIFY DeviceParams; - ULONG LastSector; + LARGE_INTEGER LastSector; DPRINT("SCSIOP_READ_CAPACITY: TargetId: %lu\n", Srb->TargetId); CapacityData = (PREAD_CAPACITY_DATA)Srb->DataBuffer; @@ -1964,15 +1966,34 @@ /* Calculate last sector (big-endian). */ if (DeviceParams->Capabilities & IDE_DRID_LBA_SUPPORTED) { - LastSector = (ULONG)((DeviceParams->TMSectorCountHi << 16) + - DeviceParams->TMSectorCountLo) - 1; + if (DeviceExtension->DeviceFlags[Srb->TargetId] & DEVICE_48BIT_ADDRESS) + { + ((PUSHORT)&LastSector)[0] = DeviceParams->Max48BitAddress[0]; + ((PUSHORT)&LastSector)[1] = DeviceParams->Max48BitAddress[1]; + ((PUSHORT)&LastSector)[2] = DeviceParams->Max48BitAddress[2]; + ((PUSHORT)&LastSector)[3] = DeviceParams->Max48BitAddress[3]; + LastSector.QuadPart -= 1; + + } + else + { + LastSector.u.HighPart = 0; + LastSector.u.LowPart = (ULONG)((DeviceParams->TMSectorCountHi << 16) + + DeviceParams->TMSectorCountLo)-1; + } } else { - LastSector = (ULONG)(DeviceParams->LogicalCyls * - DeviceParams->LogicalHeads * - DeviceParams->SectorsPerTrack)-1; + LastSector.u.HighPart = 0; + LastSector.u.LowPart = (ULONG)(DeviceParams->LogicalCyls * + DeviceParams->LogicalHeads * + DeviceParams->SectorsPerTrack)-1; } + if (LastSector.u.HighPart) + { + DPRINT1("Disk is too large for our implementation (%I64d sectors\n", LastSector.QuadPart); + KEBUGCHECK(0); + } CapacityData->LogicalBlockAddress = (((PUCHAR)&LastSector)[0] << 24) | (((PUCHAR)&LastSector)[1] << 16) | @@ -1996,10 +2017,8 @@ PIDE_DRIVE_IDENTIFY DeviceParams; ULONG StartingSector; ULONG SectorCount; - UCHAR CylinderHigh; - UCHAR CylinderLow; UCHAR DrvHead; - UCHAR SectorNumber; + UCHAR Regs[10]; UCHAR Command; ULONG Retries; UCHAR Status; @@ -2027,22 +2046,44 @@ if (DeviceParams->Capabilities & IDE_DRID_LBA_SUPPORTED) { - SectorNumber = StartingSector & 0xff; - CylinderLow = (StartingSector >> 8) & 0xff; - CylinderHigh = (StartingSector >> 16) & 0xff; - DrvHead = ((StartingSector >> 24) & 0x0f) | - (Srb->TargetId ? IDE_DH_DRV1 : 0) | - IDE_DH_LBA; + if (DeviceExtension->DeviceFlags[Srb->TargetId] & DEVICE_48BIT_ADDRESS) + { + Regs[1] = 0; + Regs[2] = SectorCount & 0xff; + Regs[3] = (SectorCount >> 8) & 0xff; + Regs[4] = StartingSector & 0xff; + Regs[5] = (StartingSector >> 8) & 0xff; + Regs[6] = (StartingSector >> 16) & 0xff; + Regs[7] = (StartingSector >> 24) & 0xff; + Regs[8] = 0; + Regs[9] = 0; + DrvHead = ((StartingSector >> 24) & 0x0f) | + (Srb->TargetId ? IDE_DH_DRV1 : 0) | + IDE_DH_LBA; + } + else + { + Regs[0] = 0; + Regs[2] = SectorCount & 0xff; + Regs[4] = StartingSector & 0xff; + Regs[5] = (StartingSector >> 8) & 0xff; + Regs[6] = (StartingSector >> 16) & 0xff; + DrvHead = ((StartingSector >> 24) & 0x0f) | + (Srb->TargetId ? IDE_DH_DRV1 : 0) | + IDE_DH_LBA; + } } else { - SectorNumber = (StartingSector % DeviceParams->SectorsPerTrack) + 1; + Regs[0] = 0; + Regs[2] = SectorCount & 0xff; + Regs[4] = (StartingSector % DeviceParams->SectorsPerTrack) + 1; StartingSector /= DeviceParams->SectorsPerTrack; DrvHead = (StartingSector % DeviceParams->LogicalHeads) | (Srb->TargetId ? IDE_DH_DRV1 : 0); StartingSector /= DeviceParams->LogicalHeads; - CylinderLow = StartingSector & 0xff; - CylinderHigh = StartingSector >> 8; + Regs[5] = StartingSector & 0xff; + Regs[6] = StartingSector >> 8; } if (DrvHead & IDE_DH_LBA) @@ -2052,7 +2093,7 @@ DeviceExtension->CommandPortBase, DrvHead & IDE_DH_DRV1 ? 1 : 0, ((DrvHead & 0x0f) << 24) + - (CylinderHigh << 16) + (CylinderLow << 8) + SectorNumber, + (Regs[6] << 16) + (Regs[5] << 8) + Regs[4], SectorCount, Command); } @@ -2062,10 +2103,10 @@ (Srb->SrbFlags & SRB_FLAGS_DATA_IN) ? "READ" : "WRITE", DeviceExtension->CommandPortBase, DrvHead & IDE_DH_DRV1 ? 1 : 0, - CylinderHigh, - CylinderLow, + Regs[6], + Regs[5], DrvHead & 0x0f, - SectorNumber, + Regs[4], SectorCount, Command); } @@ -2119,13 +2160,23 @@ #endif /* Setup command parameters */ - IDEWritePrecomp(DeviceExtension->CommandPortBase, 0); - IDEWriteSectorCount(DeviceExtension->CommandPortBase, SectorCount); - IDEWriteSectorNum(DeviceExtension->CommandPortBase, SectorNumber); - IDEWriteCylinderHigh(DeviceExtension->CommandPortBase, CylinderHigh); - IDEWriteCylinderLow(DeviceExtension->CommandPortBase, CylinderLow); - IDEWriteDriveHead(DeviceExtension->CommandPortBase, IDE_DH_FIXED | DrvHead); + if (DeviceExtension->DeviceFlags[Srb->TargetId] & DEVICE_48BIT_ADDRESS) + { + IDEWritePrecomp(DeviceExtension->CommandPortBase, Regs[1]); + IDEWriteSectorCount(DeviceExtension->CommandPortBase, Regs[3]); + IDEWriteSectorNum(DeviceExtension->CommandPortBase, Regs[7]); + IDEWriteCylinderLow(DeviceExtension->CommandPortBase, Regs[8]); + IDEWriteCylinderHigh(DeviceExtension->CommandPortBase, Regs[9]); + } + IDEWritePrecomp(DeviceExtension->CommandPortBase, Regs[0]); + IDEWriteSectorCount(DeviceExtension->CommandPortBase, Regs[2]); + IDEWriteSectorNum(DeviceExtension->CommandPortBase, Regs[4]); + IDEWriteCylinderLow(DeviceExtension->CommandPortBase, Regs[5]); + IDEWriteCylinderHigh(DeviceExtension->CommandPortBase, Regs[6]); + + IDEWriteDriveHead(DeviceExtension->CommandPortBase, IDE_DH_FIXED|DrvHead); + #ifdef ENABLE_DMA if (DeviceExtension->PRDTable && DeviceExtension->DeviceFlags[Srb->TargetId] & DEVICE_DMA_CMD) @@ -2135,7 +2186,14 @@ if (DeviceExtension->UseDma) { Handler = AtapiDmaInterrupt; - Command = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? IDE_CMD_READ_DMA : IDE_CMD_WRITE_DMA; + if (DeviceExtension->DeviceFlags[Srb->TargetId] & DEVICE_48BIT_ADDRESS) + { + Command = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? IDE_CMD_READ_DMA_EXT : IDE_CMD_WRITE_DMA_EXT; + } + else + { + Command = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? IDE_CMD_READ_DMA : IDE_CMD_WRITE_DMA; + } } else #endif @@ -2143,11 +2201,25 @@ Handler = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? AtapiReadInterrupt : AtapiWriteInterrupt; if (DeviceExtension->DeviceFlags[Srb->TargetId] & DEVICE_MULTI_SECTOR_CMD) { - Command = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? IDE_CMD_READ_MULTIPLE : IDE_CMD_WRITE_MULTIPLE; + if (DeviceExtension->DeviceFlags[Srb->TargetId] & DEVICE_48BIT_ADDRESS) + { + Command = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? IDE_CMD_READ_MULTIPLE_EXT : IDE_CMD_WRITE_MULTIPLE_EXT; + } + else + { + Command = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? IDE_CMD_READ_MULTIPLE : IDE_CMD_WRITE_MULTIPLE; + } } else { - Command = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? IDE_CMD_READ : IDE_CMD_WRITE; + if (DeviceExtension->DeviceFlags[Srb->TargetId] & DEVICE_48BIT_ADDRESS) + { + Command = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? IDE_CMD_READ_EXT : IDE_CMD_WRITE_EXT; + } + else + { + Command = Srb->SrbFlags & SRB_FLAGS_DATA_IN ? IDE_CMD_READ : IDE_CMD_WRITE; + } } } @@ -2274,7 +2346,9 @@ ScsiPortStallExecution(10); /* Issue command to drive */ - AtapiExecuteCommand(DeviceExtension, IDE_CMD_FLUSH_CACHE, AtapiNoDataInterrupt); + AtapiExecuteCommand(DeviceExtension, + DeviceExtension->DeviceFlags[Srb->TargetId] & DEVICE_48BIT_ADDRESS ? IDE_CMD_FLUSH_CACHE_EXT : IDE_CMD_FLUSH_CACHE, + AtapiNoDataInterrupt); /* Wait for controller ready */ for (Retries = 0; Retries < IDE_MAX_WRITE_RETRIES; Retries++) Index: drivers/storage/atapi/atapi.h =================================================================== --- drivers/storage/atapi/atapi.h (revision 13806) +++ drivers/storage/atapi/atapi.h (working copy) @@ -64,21 +64,27 @@ #define IDE_REG_COMMAND 0x0007 /* IDE/ATA commands */ -#define IDE_CMD_RESET 0x08 -#define IDE_CMD_READ 0x20 -#define IDE_CMD_READ_RETRY 0x21 -#define IDE_CMD_WRITE 0x30 -#define IDE_CMD_WRITE_RETRY 0x31 -#define IDE_CMD_PACKET 0xA0 -#define IDE_CMD_READ_MULTIPLE 0xC4 -#define IDE_CMD_WRITE_MULTIPLE 0xC5 -#define IDE_CMD_READ_DMA 0xC8 -#define IDE_CMD_WRITE_DMA 0xCA -#define IDE_CMD_FLUSH_CACHE 0xE7 -#define IDE_CMD_FLUSH_CACHE_EXT 0xEA -#define IDE_CMD_IDENT_ATA_DRV 0xEC -#define IDE_CMD_IDENT_ATAPI_DRV 0xA1 -#define IDE_CMD_GET_MEDIA_STATUS 0xDA +#define IDE_CMD_RESET 0x08 +#define IDE_CMD_READ 0x20 +#define IDE_CMD_READ_ONCE 0x21 +#define IDE_CMD_READ_EXT 0x24 /* 48 bit */ +#define IDE_CMD_READ_DMA_EXT 0x25 /* 48 bit */ +#define IDE_CMD_READ_MULTIPLE_EXT 0x29 /* 48 bit */ +#define IDE_CMD_WRITE 0x30 +#define IDE_CMD_WRITE_ONCE 0x31 +#define IDE_CMD_WRITE_EXT 0x34 /* 48 bit */ +#define IDE_CMD_WRITE_DMA_EXT 0x35 /* 48 bit */ +#define IDE_CMD_WRITE_MULTIPLE_EXT 0x39 /* 48 bit */ +#define IDE_CMD_PACKET 0xA0 +#define IDE_CMD_READ_MULTIPLE 0xC4 +#define IDE_CMD_WRITE_MULTIPLE 0xC5 +#define IDE_CMD_READ_DMA 0xC8 +#define IDE_CMD_WRITE_DMA 0xCA +#define IDE_CMD_FLUSH_CACHE 0xE7 +#define IDE_CMD_FLUSH_CACHE_EXT 0xEA /* 48 bit */ +#define IDE_CMD_IDENT_ATA_DRV 0xEC +#define IDE_CMD_IDENT_ATAPI_DRV 0xA1 +#define IDE_CMD_GET_MEDIA_STATUS 0xDA // // Access macros for command registers

1 0

RE: [ros-dev] Alex has fixed the laptop problem
by Murphy, Ged (Bolton) 03 Mar '05

03 Mar '05

> -----Original Message----- > From: Casper Hornstrup [mailto:ch@csh-consult.dk] > Sent: 03 March 2005 12:36 > To: 'ReactOS Development List' > Subject: RE: [ros-dev] Alex has fixed the laptop problem > > > > -----Original Message----- > > From: ros-dev-bounces(a)reactos.com > > [mailto:ros-dev-bounces@reactos.com] On Behalf Of Murphy, Ged (Bolton) > > Sent: 3. marts 2005 09:25 > > To: 'ReactOS Development List' > > Subject: RE: [ros-dev] Alex has fixed the laptop problem > > > > Alex Ionescu wrote: > > > > > Do you want to delay 0.2.6 until I merge with tip? Else it > > will be for > > > 0.3.x/0.2.7 > > > > > > Best regards, > > > Alex Ionescu > > > > What is tip ? > > He means trunk. Tip (or HEAD) is the latest revision in the repository. > Alex, when will you be ready to merge ? ************************************************************************ 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: [ros-dev] Alex has fixed the laptop problem
by Murphy, Ged (Bolton) 03 Mar '05

03 Mar '05

Alex Ionescu wrote: > Do you want to delay 0.2.6 until I merge with tip? Else it will be for > 0.3.x/0.2.7 > > Best regards, > Alex Ionescu What is tip ? ************************************************************************ 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: [ros-diffs] [ea] 13792: Fix SM\Subsystems\Required andSM\Subsystems\Optional.
by Casper Hornstrup 03 Mar '05

03 Mar '05

Why is it needed to expand the unicode characters to hex? ________________________________ Modified: trunk/reactos/bootdata/hivesys.inf --- trunk/reactos/bootdata/hivesys.inf 2005-03-01 22:22:56 UTC (rev 13791) +++ trunk/reactos/bootdata/hivesys.inf 2005-03-01 22:56:51 UTC (rev 13792) @@ -257,10 +257,10 @@ ; Subsystems HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Subsystems","Debug",0x00020000,"" HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Subsystems","Kmode",0x00020000,"%SystemRoot%\system32\win32k.sys" -HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Subsystems","Optional",0x00070000,"Posix Os2" +HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Subsystems","Optional",0x00070001,50,00,6f,00,73,00,69,00,78,00,00,00,4f,00,73,00,32,00,00,00,00,00 HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Subsystems","Os2",0x00020000,"%SystemRoot%\system32\os2ss.exe" HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Subsystems","Posix",0x00020000,"%SystemRoot%\system32\psxss.exe" -HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Subsystems","Required",0x00070000,"Debug Windows" +HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Subsystems","Required",0x00070001,44,00,65,00,62,00,75,00,67,00,00,00,57,00,69,00,6e,00,64,00,6f,00,77,00,73,00,00,00,00,00 HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Subsystems","Windows",0x00020000,"%SystemRoot%\system32\csrss.exe" ; 3Com 3c905 Driver

4 5

Changelog 0.2.6 Release.
by Steven Edwards 03 Mar '05

03 Mar '05

Hi, I guess now or never eh? If no one does it in the next few days I will branch and do a build. http://reactos.com/wiki/index.php/ChangeLog-0.2.6 Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Sports - Sign up for Fantasy Baseball. http://baseball.fantasysports.yahoo.com/

4 3

Re: [ros-svn] [navaraf] 13802: Fix W->A conversions in EnumDisplaySettingsExA. This is dedicated to Caroline!
by Alex Ionescu 03 Mar '05

03 Mar '05

navaraf(a)svn.reactos.com wrote: >Fix W->A conversions in EnumDisplaySettingsExA. This is dedicated to Caroline! > > >Updated files: >trunk/reactos/lib/user32/misc/display.c > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > > http://www.relsoft.net/mplayer.jpg

1 0

win32k crash on shutdown details
by Royce Mitchell III 03 Mar '05

03 Mar '05

FWIW, Alex is also experiencing this problem... Basically while shutting down for reboot, I hit Ctrl+Alt on the keyboard, and it crashed. Here's the dump: (smss.c:85) SM: Process terminated! (ke/error.c:54) Hard error c000021a (ke/catch.c:142) Unhandled UserMode exception, terminating thread KeBugCheckWithTf at ke/catch.c:177 Bug detected (code 1e param 0 0 0 0) KMODE_EXCEPTION_NOT_HANDLED Page Fault Exception: 14(0) Processor: 0 CS:EIP 8:9d5b40ef <win32k.sys: 180ef> cr2 cdcdcef1 cr3 27000 Proc: 8048d8e0 Pid: 4 <System> Thrd: 80670050 Tid: 78 DS 10 ES 10 FS 30 GS 10 EAX: cdcdcdcd EBX: 9d5b3db2 ECX: 80593a50 EDX: 80670084 EBP: 9d70fdd8 ESI: 00000000 ESP: 9d70fcbc EDI: 00000000 EFLAGS: 00000282 kESP 9d70fcbc kernel stack base 9d70d000 Frames: <ntoskrnl.exe: 33f0> here's the assembly instruction where we crashed: <win32k.sys: 180ef> cmpl $0x0,0x124(%eax) here's what addr2line gives: C:\cvs\reactos\subsys\win32k>a 180ef C:/cvs/reactos/subsys/win32k/ntuser/input.c:380 subsys/win32k/ntuser/input.c:380: if (FocusThread && FocusThread->Tcb.Win32Thread && so FocusThread is 0xcdcdcdcd, which means that the FocusQueue holding it is getting deleted out from under us. after initial examination, we aren't ref counting the desktop or the queue when we obtain it via IntGetFocusMessageQueue(). as this bug is occuring on shutdown, I think the most proper solution is to reference the msgqueue until we're done with it there in ntuser/input.c. However, in order to safely reference the msgqueue, it seems we really need to reference the desktop at least long enough to obtain the msgqueue pointer and reference it. This sounds very slow, so I'm wondering if there's a better fix than that... I was thinking we could add a "shutdown hack" for this, by at the very least killing InputDesktop sooner, but it seems that might not help in situations where we're killing one of many desktops. Anyways, I'm not confident what should be done in this case, so I'm passing this information to the list in hopes that someone more familiar with the msgqueue code can fix it. Thanks, Royce Mitchell III <ntoskrnl.exe: 33f0>

1 0

Memory Manager Patch to allow mapping of device memory into UserMode - please review.
by Gregor Anich 03 Mar '05

03 Mar '05

Hi! I have changed the memory manager to allow mapping of sections from \Device\PhysicalMemory which are outside of RAM - this gets NVIDIA OpenGL working. I hope my changes are correct (according to Hartmuts suggestions in this mail: http://reactos.com:8080/archives/public/ros-kernel/2004-August/004444.html) I changed MmProbeAndLockPages to set MDL_IO_SPACE in the MdlFlags of the Mdl if one of the Pfns described in the MDL is outside of the RAM (>= MmPageArraySize) which is then used in MmMapLockedPagesSpecifyCache to decide wether to call MmCreateVirtualMapping or MmCreateVirtualMappingUnsafe (in order to prevent bugchecks in mm/freelist.c when Pfns are checked against MmPageArraySize) - blight Index: include/internal/mm.h =================================================================== --- include/internal/mm.h (revision 13428) +++ include/internal/mm.h (working copy) @@ -626,6 +626,7 @@ VOID MmSetLRULastPage(PFN_TYPE Page); VOID MmLockPage(PFN_TYPE Page); +VOID MmLockPageUnsafe(PFN_TYPE Page); VOID MmUnlockPage(PFN_TYPE Page); @@ -710,6 +711,7 @@ VOID MmDereferencePage(PFN_TYPE Page); VOID MmReferencePage(PFN_TYPE Page); +VOID MmReferencePageUnsafe(PFN_TYPE Page); BOOLEAN MmIsAccessedAndResetAccessPage(struct _EPROCESS* Process, PVOID Address); Index: mm/section.c =================================================================== --- mm/section.c (revision 13428) +++ mm/section.c (working copy) @@ -721,6 +721,9 @@ MmSharePageEntrySectionSegment(Segment, Offset); + /* FIXME: Should we call MmCreateVirtualMappingUnsafe if + * (Section->AllocationAttributes & SEC_PHYSICALMEMORY) is true? + */ Status = MmCreateVirtualMapping(MemoryArea->Process, Address, Attributes, @@ -823,14 +826,14 @@ * Just map the desired physical page */ Page = (Offset + MemoryArea->Data.SectionData.ViewOffset) >> PAGE_SHIFT; - Status = MmCreateVirtualMapping(AddressSpace->Process, - Address, - Region->Protect, - &Page, - 1); + Status = MmCreateVirtualMappingUnsafe(AddressSpace->Process, + Address, + Region->Protect, + &Page, + 1); if (!NT_SUCCESS(Status)) { - DPRINT("MmCreateVirtualMapping failed, not out of memory\n"); + DPRINT("MmCreateVirtualMappingUnsafe failed, not out of memory\n"); KEBUGCHECK(0); return(Status); } @@ -840,7 +843,7 @@ */ if (Locked) { - MmLockPage(Page); + MmLockPageUnsafe(Page); } /* Index: mm/mdl.c =================================================================== --- mm/mdl.c (revision 13428) +++ mm/mdl.c (working copy) @@ -29,7 +29,7 @@ /* MDL Flags desc. -MDL_PAGES_LOCKED MmProbelAndLockPages has been called for this mdl +MDL_PAGES_LOCKED MmProbeAndLockPages has been called for this mdl MDL_SOURCE_IS_NONPAGED_POOL mdl has been build by MmBuildMdlForNonPagedPool MDL_PARTIAL mdl has been built by IoBuildPartialMdl MDL_MAPPING_CAN_FAIL in case of an error, MmMapLockedPages will return NULL instead of to bugcheck @@ -300,7 +300,7 @@ { memcpy(Mdl + 1, Pages, sizeof(PFN_TYPE) * (PAGE_ROUND_UP(Mdl->ByteOffset+Mdl->ByteCount)/PAGE_SIZE)); - //FIXME: this flag should be set by the caller perhaps? + /* FIXME: this flag should be set by the caller perhaps? */ Mdl->MdlFlags |= MDL_IO_PAGE_READ; } @@ -374,8 +374,8 @@ ASSERT(NrPages <= (Mdl->Size - sizeof(MDL))/sizeof(PFN_TYPE)); - if (Mdl->StartVa >= (PVOID)KERNEL_BASE && - MmGetPfnForProcess(NULL, Mdl->StartVa) > MmPageArraySize) + if (Mdl->StartVa >= (PVOID)KERNEL_BASE && + MmGetPfnForProcess(NULL, Mdl->StartVa) >= MmPageArraySize) { /* phys addr is not phys memory so this must be io memory */ @@ -391,13 +391,13 @@ if (Mdl->StartVa >= (PVOID)KERNEL_BASE) { - //FIXME: why isn't AccessMode used? + /* FIXME: why isn't AccessMode used? */ Mode = KernelMode; Mdl->Process = NULL; } else { - //FIXME: why isn't AccessMode used? + /* FIXME: why isn't AccessMode used? */ Mode = UserMode; Mdl->Process = CurrentProcess; } @@ -455,7 +455,10 @@ } Page = MmGetPfnForProcess(NULL, Address); MdlPages[i] = Page; - MmReferencePage(Page); + if (Page >= MmPageArraySize) + Mdl->MdlFlags |= MDL_IO_SPACE; + else + MmReferencePage(Page); } MmUnlockAddressSpace(&CurrentProcess->AddressSpace); @@ -848,11 +851,18 @@ Protect |= PAGE_NOCACHE; else if (CacheType == MmWriteCombined) DPRINT("CacheType MmWriteCombined not supported!\n"); - Status = MmCreateVirtualMapping(CurrentProcess, - Base, - Protect, - MdlPages, - PageCount); + if (Mdl->MdlFlags & MDL_IO_SPACE) + Status = MmCreateVirtualMappingUnsafe(CurrentProcess, + Base, + Protect, + MdlPages, + PageCount); + else + Status = MmCreateVirtualMapping(CurrentProcess, + Base, + Protect, + MdlPages, + PageCount); if (!NT_SUCCESS(Status)) { DbgPrint("Unable to create virtual mapping\n"); Index: mm/freelist.c =================================================================== --- mm/freelist.c (revision 13428) +++ mm/freelist.c (working copy) @@ -612,15 +612,15 @@ } VOID -MmReferencePage(PFN_TYPE Pfn) +MmReferencePageUnsafe(PFN_TYPE Pfn) { KIRQL oldIrql; - DPRINT("MmReferencePage(PysicalAddress %x)\n", Pfn << PAGE_SHIFT); + DPRINT("MmReferencePageUnsafe(PysicalAddress %x)\n", Pfn << PAGE_SHIFT); if (Pfn == 0 || Pfn >= MmPageArraySize) { - KEBUGCHECK(0); + return; } KeAcquireSpinLock(&PageListLock, &oldIrql); @@ -635,6 +635,19 @@ KeReleaseSpinLock(&PageListLock, oldIrql); } +VOID +MmReferencePage(PFN_TYPE Pfn) +{ + DPRINT("MmReferencePage(PysicalAddress %x)\n", Pfn << PAGE_SHIFT); + + if (Pfn == 0 || Pfn >= MmPageArraySize) + { + KEBUGCHECK(0); + } + + MmReferencePageUnsafe(Pfn); +} + ULONG MmGetReferenceCountPage(PFN_TYPE Pfn) { @@ -781,15 +794,15 @@ } VOID -MmLockPage(PFN_TYPE Pfn) +MmLockPageUnsafe(PFN_TYPE Pfn) { KIRQL oldIrql; - DPRINT("MmLockPage(PhysicalAddress %x)\n", Pfn << PAGE_SHIFT); + DPRINT("MmLockPageUnsafe(PhysicalAddress %x)\n", Pfn << PAGE_SHIFT); if (Pfn == 0 || Pfn >= MmPageArraySize) { - KEBUGCHECK(0); + return; } KeAcquireSpinLock(&PageListLock, &oldIrql); @@ -805,6 +818,19 @@ } VOID +MmLockPage(PFN_TYPE Pfn) +{ + DPRINT("MmLockPage(PhysicalAddress %x)\n", Pfn << PAGE_SHIFT); + + if (Pfn == 0 || Pfn >= MmPageArraySize) + { + KEBUGCHECK(0); + } + + MmLockPageUnsafe(Pfn); +} + +VOID MmUnlockPage(PFN_TYPE Pfn) { KIRQL oldIrql;

2 2

Re: Re: [ros-dev] added a proposed patch to bugzilla
by Roman Hoegg 02 Mar '05

02 Mar '05

1 0

Re: Re: [ros-dev] added a proposed patch to bugzilla
by Johannes Olofsson 02 Mar '05

02 Mar '05

Hi! The CAPS constant is defined to be KSHIFT, which if I understand this correct means that the shifted value is used when caps lock is used. Try to change the line : /* none, shift, ctrl-alt, ctrl, ctrl-shift */ { VK_OEM_7, NOCAPS, 0xe4, 0xe0, 0x7b, WCH_NONE, 0x00 }, /* ä à { */ to: { VK_OEM_7, KCTRL, 'code for ä', 'code for à', 0x7b, 'code for Ä', 'code for À }, /* ä à { */ in order to use the ctrl and ctrl-shift states for caps lock for this key. I don't have a test environment set up at the moment to test this, but it is possible that windows uses something like this. Regards Johannes Olofsson > Från: art yerkes <ayerkes(a)speakeasy.net> > Till: ReactOS Development List <ros-dev(a)reactos.com> > Rubrik: Re: [ros-dev] added a proposed patch to bugzilla > Datum: Tue, 1 Mar 2005 12:23:52 -0600 > <pre>On Thu, 24 Feb 2005 15:51:38 +0100 > Roman Hoegg <roman.hoegg(a)unisg.ch> wrote: > > > > > > > > as NOCAPS in your layout file > > > > yes that's true but I did that for a reason. I had two choices. Either > > can't set differentiate between SHIFT and CAPS LOCK. > > I wasn't aware that NOCAPS could be different from SHIFT, so NOCAPS always > implies shift in our current model. I'll try to fix it. > -- 10 Gigabyte Mailbox - http://mail.spray.se

1 0

Re:[ros-dev] RE: [ros-diffs] [ea] 13792: Fix SMSubsystemsRequired andSMSubsystemsOptional.
by ea＠iol.it 02 Mar '05

02 Mar '05

Date : Wed, 2 Mar 2005 12:46:30 +0100 Subject : [ros-dev] RE: [ros-diffs] [ea] 13792: Fix SM\Subsystems\Required andSM\Subsystems\Optional. Casper> Why is it needed to expand the unicode characters to hex? With value type 0x00070000 I get garbage from the SM when I pick up the Required names. If there is a way to make a REG_MULTI_SZ with a string, I'd be happy. ea ____________________________________________________________ Navighi a 2 MEGA e i primi 3 mesi sono GRATIS. Scegli Libero Adsl Flat senza limiti su http://www.libero.it

1 0

SysInternals Process Explorer
by James Tabor 02 Mar '05

02 Mar '05

Hi all! http://www.sysinternals.com/ntw2k/freeware/procexp.shtml Debug output from execution of procexp on ROS, (api/handle.c:71) CsrGetObject returning invalid handle (NTDLL:ldr/utils.c:2092) Relocating (76260000 -> 700000) C:\ReactOS\system32\ole aut32.dll (NTDLL:ldr/utils.c:2092) Relocating (77800000 -> 4e1000) C:\ReactOS\system32\win spool.drv 0 bytes requested - initiating pool verification 0 bytes requested - initiating pool verification FIXME: CopyImage doesn't support IMAGE_ICON correctly! 0 bytes requested - initiating pool verification 0 bytes requested - initiating pool verification (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find mxdMessage (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find auxMessage (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find mxdMessage (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find midMessage (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find modMessage (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find widMessage (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find wodMessage (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find auxMessage (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find mxdMessage (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find midMessage (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find widMessage (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find wodMessage (cm/ntfunc.c:379) NtDeleteKey(KeyHandle dc) called (cm/ntfunc.c:418) PointerCount 1 (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find AllocateAndGetTcpE xTableFromStack (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find AllocateAndGetUdpE xTableFromStack (NTDLL:ldr/utils.c:2034) Failed to create or open dll section of '.dll' (Status c0000135) (NTDLL:ldr/utils.c:2092) Relocating (76160000 -> db1000) C:\ReactOS\system32\dbg help.dll (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find NtSuspendProcess (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find NtResumeProcess (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find EnumServicesStatus ExA (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find QueryServiceConfig 2A (NTDLL:ldr/utils.c:2034) Failed to create or open dll section of 'winsta.dll' (S tatus c0000135) (NTDLL:ldr/utils.c:1091) LdrGetExportByName(): no export directory! (NTDLL:ldr/utils.c:2034) Failed to create or open dll section of 'uxtheme.dll' ( Status c0000135) (NTDLL:ldr/utils.c:1091) LdrGetExportByName(): no export directory! (NTDLL:ldr/utils.c:1091) LdrGetExportByName(): no export directory! (NTDLL:ldr/utils.c:1091) LdrGetExportByName(): no export directory! (fsctl.c:277) SysType (KERNEL32:mem/global.c:412) Memory Load: 4 *My little hack* (ex/sysinfo.c:827) NtQuerySystemInformation - SystemHandleInformation (ex/sysinfo.c:835) SystemHandleInformation 1 (ex/sysinfo.c:854) SystemHandleInformation 2 (ex/sysinfo.c:872) SystemHandleInformation 4 (sec/lsa.c:221) LsaOpenPolicy - stub (sec/lsa.c:32) (ffffffff):LsaClose stub (NTDLL:ldr/utils.c:2034) Failed to create or open dll section of 'Powrprof.dll' (Status c0000135) (NTDLL:ldr/utils.c:1091) LdrGetExportByName(): no export directory! (ex/sysinfo.c:1046) NtQuerySystemInformation - SystemInterruptInformation not im plemented (sec/lsa.c:221) LsaOpenPolicy - stub (sec/lsa.c:32) (ffffffff):LsaClose stub *Here again* (ex/sysinfo.c:827) NtQuerySystemInformation - SystemHandleInformation (ex/sysinfo.c:835) SystemHandleInformation 1 (ex/sysinfo.c:854) SystemHandleInformation 2 (ex/sysinfo.c:872) SystemHandleInformation 4 (sec/lsa.c:221) LsaOpenPolicy - stub (sec/lsa.c:32) (ffffffff):LsaClose stub (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (sec/lsa.c:221) LsaOpenPolicy - stub (sec/lsa.c:32) (ffffffff):LsaClose stub (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (sec/lsa.c:221) LsaOpenPolicy - stub (sec/lsa.c:32) (ffffffff):LsaClose stub (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (sec/lsa.c:221) LsaOpenPolicy - stub (sec/lsa.c:32) (ffffffff):LsaClose stub (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (sec/lsa.c:221) LsaOpenPolicy - stub (sec/lsa.c:32) (ffffffff):LsaClose stub (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (sec/lsa.c:221) LsaOpenPolicy - stub (sec/lsa.c:32) (ffffffff):LsaClose stub (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (sec/lsa.c:221) LsaOpenPolicy - stub (sec/lsa.c:32) (ffffffff):LsaClose stub (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (sec/lsa.c:221) LsaOpenPolicy - stub (sec/lsa.c:32) (ffffffff):LsaClose stub (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (sec/lsa.c:221) LsaOpenPolicy - stub (sec/lsa.c:32) (ffffffff):LsaClose stub (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (KERNEL32:misc/stubs.c:1457) GetLongPathNameA() is UNIMPLEMENTED! (sec/lsa.c:221) LsaOpenPolicy - stub (sec/lsa.c:32) (ffffffff):LsaClose stub KeBugCheckWithTf at ke/catch.c:177 Bug detected (code 1e param 0 0 0 0) KMODE_EXCEPTION_NOT_HANDLED Page Fault Exception: 14(0) Processor: 0 CS:EIP 8:8009f441 <ntoskrnl.exe: 9f441> cr2 4ea000 cr3 3b854000 Proc: 80c246b8 Pid: 130 <procexp.> Thrd: 80cc2af0 Tid: 1 34 DS 10 ES 10 FS 30 GS 23 EAX: 80c246b8 EBX: 0000009b ECX: 00001800 EDX: 00010000 EBP: 9e2d7cf8 ESI: 004ea000 ESP: 9e2d7c7c EDI: 005e8424 EFLAGS: 00010216 kESP 9e2d7c7c kernel stack base 9e2d5000 Frames: <ntoskrnl.exe: 72801> <ntoskrnl.exe: 399b> <7FFE0304>

4 5

Re: [ros-svn] [gdalsnes] 13791: tcharize a couple of routines
by Royce Mitchell III 02 Mar '05

02 Mar '05

shouldn't _tfopen() be a #define?

2 1

Re: [ros-dev] added a proposed patch to bugzilla
by Johannes Olofsson 01 Mar '05

01 Mar '05

Hi! What about the ö and ä keys? Should they behave the same way? (note that these keys and the ü key are marked as NOCAPS in your layout file). Regards Johannes Olofsson > Från: Roman Hoegg <roman.hoegg(a)unisg.ch> > Till: ros-dev(a)reactos.com > Rubrik: [ros-dev] added a proposed patch to bugzilla > Datum: Wed, 23 Feb 2005 22:58:02 +0100 Hello everybody! I've been a long time lurker and have decided to finaly contribute something to this wonderful project. quick introduction: 29, male, research assistent at the University of St. Gallen (Switzerland), some C/C++ knowledge (but not enough for serious contributions to an OS) I'm in the process of creating a keyboard layout (it's nearly finished) and have run into a problem which I posted in bugzilla. I was told on #reactos that this is the way to do it. http://reactos.com/bugzilla/show_bug.cgi?id=509 would be cool if someone with experience with keyboard layouts could give me a tip. thanks! Roman Hoegg (RomanH)_______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev Otur i kärlek - http://www.spray.se/spel Tur i kärlek - http://www.spraydate.com

3 2

RE: [ros-svn] [ion] 13776: Test commit. Not official branch release --it will follow shortly in 15 minutes. If this ends up in HEADi will revert immediately (i have svn switched so it shouldn't)
by Casper Hornstrup 28 Feb '05

28 Feb '05

There is no need to commit to check that. You can use "svn info". Casper > -----Original Message----- > From: ros-svn-bounces(a)reactos.com > [mailto:ros-svn-bounces@reactos.com] On Behalf Of ion(a)svn.reactos.com > Sent: 28. februar 2005 17:45 > To: ros-svn(a)reactos.com > Subject: [ros-svn] [ion] 13776: Test commit. Not official > branch release --it will follow shortly in 15 minutes. If > this ends up in HEADi will revert immediately (i have svn > switched so it shouldn't) > > Test commit. Not official branch release -- it will follow > shortly in 15 minutes. If this ends up in HEAD i will revert > immediately (i have svn switched so it shouldn't)

2 1

Uptime.exe
by James Tabor 28 Feb '05

28 Feb '05

Hi, I had this for a long time, Org unknown, Good luck, James

1 0

Explorer in XP and Wallpaper changing...
by Alex Ionescu 28 Feb '05

28 Feb '05

Hi everyone, Firstly, it seems our explorer doesn't load in WXP anymore. Looks like we are directly importing NtGdiBitBlt (undocumented function) instead of relying on BitBlt. I don't see any need to use undocumented native API in explorer... I've also heard that it's impossible to built it with msvc because of numerous (43) template errors. Bizzeh on IRC knows more about this. Secondly, I've tried out the new wallpaper changing, and it crashes on my build, inside win32k. I am running qemu + optimized build...can anyone else repro? I will try other BMPs to make sure mine isn't corrupted (which still means there' s a bug). Best regards, Alex Ionescu

4 3

Re: [ros-svn] [ion] 13776: Test commit. Not official branch release -- it will follow shortly in 15 minutes. If this ends up in HEAD i will revert immediately (i have svn switched so it shouldn't)
by Alex Ionescu 28 Feb '05

28 Feb '05

SVN messed up... do not update to 13776... I will revert. ion(a)svn.reactos.com wrote: >Test commit. Not official branch release -- it will follow shortly in 15 minutes. If this ends up in HEAD i will revert immediately (i have svn switched so it shouldn't) > > >Added files: >trunk/reactos/ntoskrnl/ex/error.c >trunk/reactos/ntoskrnl/ob/wait.c > >Updated files: >trunk/reactos/config >trunk/reactos/drivers/storage/floppy/floppy.c >trunk/reactos/include/ddk/extypes.h >trunk/reactos/include/ddk/iotypes.h >trunk/reactos/include/ddk/ketypes.h >trunk/reactos/include/ntos/zwtypes.h >trunk/reactos/lib/ntdll/def/ntdll.def >trunk/reactos/ntoskrnl/Makefile >trunk/reactos/ntoskrnl/cm/registry.c >trunk/reactos/ntoskrnl/ex/event.c >trunk/reactos/ntoskrnl/ex/evtpair.c >trunk/reactos/ntoskrnl/ex/init.c >trunk/reactos/ntoskrnl/ex/mutant.c >trunk/reactos/ntoskrnl/ex/rundown.c >trunk/reactos/ntoskrnl/ex/sem.c >trunk/reactos/ntoskrnl/ex/sysinfo.c >trunk/reactos/ntoskrnl/ex/timer.c >trunk/reactos/ntoskrnl/ex/work.c >trunk/reactos/ntoskrnl/include/internal/ex.h >trunk/reactos/ntoskrnl/include/internal/id.h >trunk/reactos/ntoskrnl/include/internal/io.h >trunk/reactos/ntoskrnl/include/internal/ke.h >trunk/reactos/ntoskrnl/include/internal/nls.h >trunk/reactos/ntoskrnl/include/internal/ntoskrnl.h >trunk/reactos/ntoskrnl/include/internal/ps.h >trunk/reactos/ntoskrnl/io/bootlog.c >trunk/reactos/ntoskrnl/io/create.c >trunk/reactos/ntoskrnl/io/driver.c >trunk/reactos/ntoskrnl/io/iocomp.c >trunk/reactos/ntoskrnl/io/iomgr.c >trunk/reactos/ntoskrnl/io/wmi.c >trunk/reactos/ntoskrnl/ke/apc.c >trunk/reactos/ntoskrnl/ke/bug.c >trunk/reactos/ntoskrnl/ke/catch.c >trunk/reactos/ntoskrnl/ke/dpc.c >trunk/reactos/ntoskrnl/ke/event.c >trunk/reactos/ntoskrnl/ke/i386/tskswitch.S >trunk/reactos/ntoskrnl/ke/kthread.c >trunk/reactos/ntoskrnl/ke/main.c >trunk/reactos/ntoskrnl/ke/mutex.c >trunk/reactos/ntoskrnl/ke/queue.c >trunk/reactos/ntoskrnl/ke/sem.c >trunk/reactos/ntoskrnl/ke/timer.c >trunk/reactos/ntoskrnl/ke/wait.c >trunk/reactos/ntoskrnl/ntoskrnl.def >trunk/reactos/ntoskrnl/ntoskrnl.mc >trunk/reactos/ntoskrnl/ps/kill.c >trunk/reactos/ntoskrnl/ps/process.c >trunk/reactos/ntoskrnl/ps/thread.c >trunk/reactos/ntoskrnl/rtl/nls.c >trunk/reactos/tools/nci/sysfuncs.lst > >Deleted files: >trunk/reactos/ntoskrnl/ke/alert.c >trunk/reactos/ntoskrnl/ke/critical.c >trunk/reactos/ntoskrnl/ke/error.c > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > >

1 0

RE: [ros-svn] [sedwards] 13772: merge in Winehq changes to reduce noise
by Casper Hornstrup 28 Feb '05

28 Feb '05

You need to revert that change and merge the wine changes to the vendor branch instead and then merge them back to trunk. This is so we keep wine and ReactOS changes separate from each other. GvG has a tutorial somewhere I believe? Casper > -----Original Message----- > From: ros-svn-bounces(a)reactos.com > [mailto:ros-svn-bounces@reactos.com] On Behalf Of > sedwards(a)svn.reactos.com > Sent: 27. februar 2005 23:56 > To: ros-svn(a)reactos.com > Subject: [ros-svn] [sedwards] 13772: merge in Winehq > changes to reduce noise > > merge in Winehq changes to reduce noise > > > Updated files: > trunk/reactos/tools/widl/ChangeLog > trunk/reactos/tools/widl/parser.y > trunk/reactos/tools/widl/server.c > trunk/reactos/tools/widl/typelib.c > trunk/reactos/tools/widl/widl.c > trunk/reactos/tools/widl/widl.h > trunk/reactos/tools/widl/y.tab.c > > Deleted files: > trunk/reactos/tools/widl/client.h > trunk/reactos/tools/widl/proxy.h > trunk/reactos/tools/widl/server.h > > _______________________________________________ > Ros-svn mailing list > Ros-svn(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-svn

2 1

Re: [ros-diffs] [weiden] 13775: German translation fixes by Rouven Wessling
by Hartmut Birr 28 Feb '05

28 Feb '05

Are you sure that this changes are correct? - Hartmut weiden(a)svn.reactos.com schrieb: >German translation fixes by Rouven Wessling > >Modified: trunk/reactos/lib/cpl/desk/de.rc > > > *Modified: trunk/reactos/lib/cpl/desk/de.rc* > >--- trunk/reactos/lib/cpl/desk/de.rc 2005-02-28 04:43:30 UTC (rev 13774) >+++ trunk/reactos/lib/cpl/desk/de.rc 2005-02-28 14:38:02 UTC (rev 13775) >@@ -1,5 +1,46 @@ > > LANGUAGE LANG_GERMAN, SUBLANG_DEFAULT > > > >+IDM_MAINMENU MENU DISCARDABLE >+BEGIN >+ POPUP "&Optionen" >+ BEGIN >+ MENUITEM "&Eigenschaften", IDC_PROPERTIES >+ MENUITEM "Erweiterte Ein&stellungen", IDC_ADVANCED_CONTROLS >+ MENUITEM SEPARATOR >+ MENUITEM "&Beenden", IDC_EXIT >+ END >+ POPUP "&?" >+ BEGIN >+ MENUITEM "&Hilfethemen", IDC_HELP_TOPICS >+ MENUITEM SEPARATOR >+ MENUITEM "&Info", IDC_ABOUT >+ END >+END >+ >+STRINGTABLE DISCARDABLE >+BEGIN >+ IDS_SNDVOL32 "Lautstõrke Einstellungen" >+ IDS_NOMIXERDEVICES "Es sind keine aktivien Mixer vorhanden! Die Anwendung wird jetzt beendet." >+END >+ >+IDD_PREFERENCES DIALOGEX 0, 0, 224, 250 >+STYLE DS_MODALFRAME | DS_CONTEXTHELP | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU >+CAPTION "Eigenschaften" >+FONT 8, "MS Shell Dlg", 0, 0, 0x0 >+BEGIN >+ LTEXT "&Mixer:", -1, 7,8,48,9 >+ COMBOBOX IDC_MIXERDEVICE, 55,8,162,80, CBS_DROPDOWNLIST | WS_TABSTOP >+ GROUPBOX "Lautstõrke regeln f³r:", -1, 7,25,211,77 >+ PUSHBUTTON "Wie&dergabe", IDC_PLAYBACK, 13,43,47,8, BS_AUTORADIOBUTTON >+ PUSHBUTTON "&Aufnahme", IDC_RECORDING, 13,61,47,8, BS_AUTORADIOBUTTON >+ PUSHBUTTON "A&ndere:", IDC_OTHER, 13,80,42,8, BS_AUTORADIOBUTTON | WS_DISABLED >+ COMBOBOX IDC_LINE, 55,80,155,50, CBS_DROPDOWNLIST | WS_TABSTOP | WS_DISABLED >+ >+ PUSHBUTTON "OK", IDOK, 114,226,50,14 >+ PUSHBUTTON "Abbrechen", IDCANCEL, 168,226,50,14 >+END >+LANGUAGE LANG_GERMAN, SUBLANG_DEFAULT >+ > > > IDD_BACKGROUND DIALOGEX DISCARDABLE 0, 0, 246, 228 > STYLE DS_SHELLFONT | WS_CHILD | WS_DISABLED | WS_CAPTION > CAPTION "Desktop" > > > ------------------------------------------------------------------------

1 0

compile error
by Wesley Parish 28 Feb '05

28 Feb '05

I was compiling ReactOS 0.2.5 today. I typed "make" and it went swimmingly when it threw this up at me: kernel32: [CC] misc/console.c make (e=2): The system cannot find the file specified. make [1]: ***[misc/time.o] Error 2 make: ***[kernel32] Error 2 The system's a Compaq Deskpro 4000, with C: being a 1.25 GB hard-drive and with 64 MB. What do people suggest I do? (Besides updating to 0.2.6?) Wesley Parish -- Clinersterton beademung, with all of love - RIP James Blish ----- Mau e ki, he aha te mea nui? You ask, what is the most important thing? Maku e ki, he tangata, he tangata, he tangata. I reply, it is people, it is people, it is people.

1 0

Floppy Disk
by James Tabor 28 Feb '05

28 Feb '05

Hi all, When did the floppy detection stop working? I can not read the floppy driver. Thanks, James PS, I lost 2/3 of my email, I have no references atm.

1 0

CSR plug-ins: docs?
by ea 26 Feb '05

26 Feb '05

Is there somewhere a doc that explains how our CSR plug-ins work? ea

1 0

subversion problem
by Hartmut Birr 26 Feb '05

26 Feb '05

Hi, I would update the cache_manager_rewrite branch with all changes from the main tree. I'm using the merge command to add the changes to my local tree. It fails allways with revision 13667. I can merge all changes up to revision 13666. But I get an error with revision 13667: E:\Sandbox\ros_cache\reactos\tools>d:\programme\subversion\bin\svn.exe merge -r13566:13667 svn://svn.reactos.com/trunk/reactos/tools D winebuild\res32.c D winebuild\spec32.c D winebuild\res16.c D winebuild\utils.c D winebuild\Makefile.in D winebuild\spec16.c D winebuild\mkstemps.c D winebuild\build.h D winebuild\import.c D winebuild\relay.c D winebuild\winehq2ros.patch D winebuild\winglue.h D winebuild\winebuild.man.in D winebuild\main.c D winebuild\parser.c D winebuild\Makefile D winebuild svn: Revision 13667 doesn't match existing revision 13567 in 'winebuild' What can I do to solve this problem? - Hartmut

2 1

RE: [ros-dev] Release 0.2.6
by Murphy, Ged (Bolton) 26 Feb '05

26 Feb '05

Agreed. It'll be good for publicity too. Regular minor releases are better than infrequent major releases. Gedi. -----Original Message----- From: Jason Filby [mailto:jason.filby@gmail.com] Sent: 23 February 2005 17:57 To: ReactOS Development List Subject: [ros-dev] Release 0.2.6 Hi all The consensus on IRC appears to be that we need another 0.2.x release. The reason is that 0.3 is our "network" release and there's still some work to do to justify this. Everyone agree? Cheers Jason _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev ************************************************************************ 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

9 12

ReactOS Wallpaper List
by Klemens Friedl 26 Feb '05

26 Feb '05

ReactOS Wallpapers List (suggestion): ReactOS Wallpapers for Version 0.2.6: * ReactOS Wallpaper (original with new text; GNU GPL) http://reactosde.re.funpic.de/mediadetail.php?sec=Graphic%20arts&cat=wallp&… * ReactOS Computer Wallpaper #1 (GNU GPL) http://reactosde.re.funpic.de/mediadetail.php?sec=Graphic%20arts&cat=wallp&… * hill and water (BSD-license) http://reactosde.re.funpic.de/mediadetail.php?sec=Graphic%20arts&cat=wallp&… * ReactOS wallpaper - 3d with holes (GNU LGPL) http://reactosde.re.funpic.de/mediadetail.php?sec=Graphic%20arts&cat=wallp&… * ReactOS Wallpapers (Earth) http://reactosde.re.funpic.de/mediadetail.php?sec=Graphic%20arts&cat=wallp&… GPL Wallpapers from kde-look.org: * Nature #1 (Fruit) http://www.kde-look.org/content/files/16183-green.jpg * Nature #2 (Wood) http://www.kde-look.org/content/files/10274-p1010076.jpg * Nature #3 (Sea) http://arg0.net/users/vgough/images/2007-taupo.png * Nature #4 (Bees #1) http://kdelook.org/content/files/16382-img_0511c1_xga.jpg * Nature #5 (Bees #2) http://www.kde-look.org/content/files/16498-Beon.jpg * Nature #6 (Bees #3) http://www.kde-look.org/content/files/6524-Bee%20in%20Flower.jpg * Nature #7 (Summer) http://www.kde-look.org/content/files/20979-altabadia_summer_1200.jpg Some useful links: * GNOME-LOOK.ORG http://www.gnome-look.org * KDE-LOOK.ORG http://www.kde-look.org/ * Frik85's ReactOS Fanpage http://frik85.reactos.at (-> http://reactosde.re.funpic.de/mediagroup.php?sec=Graphic%20arts) History: 2005-02-25 Klemens Friedl Best regards, Klemens Friedl -- Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail

3 5

ntoskrnl issue on my Dell Latitude C610
by Steven Edwards 25 Feb '05

25 Feb '05

Hi, A little background info. I have a dell Latitude c610 with a P3m 1ghz CPU, 256Megs of Ram and a 20 Gig hard disk. ATI Mobile Radeon Graphics chip with 16megs of Vram. When I try to boot ReactOS the screen always go black after freeldr loads the drivers and everything even if /NOGUIBOOT is selected and bootvid.sys is removed from the system. The screen never goes blue and the kernel never gets a point where HalDisplayString or the kernel debugger will work. I have added a function to my ke\main.c to manually write to the screen in text mode and have been using that to try to debug the boot process. The problem is that it never consistantly crashes at one line of code. It always seems to be around a call to KeLowerIrql but depending on where I stick my debug statements it will change. Whats odd is that it will fail 100% of the time in the same place depending on where I move my debug statements. The only thing I can figure is that but writting to the display its interupting which is changing the failure location. The farthest in the boot process I can get is the call to KeLowerIrql that happens around the calls to SeInit1 and SeInit2. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250

2 2

RE: [ros-dev] Release 0.2.6
by Casper Hornstrup 24 Feb '05

24 Feb '05

> -----Original Message----- > From: ros-dev-bounces(a)reactos.com > [mailto:ros-dev-bounces@reactos.com] On Behalf Of Karim Liman-Tinguiri > Sent: 24. februar 2005 12:34 > To: ReactOS Development List > Subject: Re: [ros-dev] Release 0.2.6 > > Greetings everyone, > > I totally agree with Murphy and I believe we should launch another > 0.2.x release before the next 0.3 release. I think before we can > launch a 0.3 release, we need to have a solid support for Win32 > drivers: networking doesn't limit to LAN-Ethernet, but it also > includes PPP and modem connection (analogic and broadband). > > With the growing amounts of winmodems, Win32 driver support must > definitely be implemented before claiming "networking > support": this is one of the weaker points of Linux: driver > compatibility (though lots of efforts are being made by manufacturers > and hackers), many drivers are still only available on the windows > platform. It'd be much cheaper, programming-effort wise, to natively > support windows driver than try to port them to ReactOS, (I'm not even > mentionning the case of closed-source drivers and undocumented > hardware). > > As is stated in the status page of the library "Driver Support At the > moment, work to support 3rd party drivers (Microsoft Windows > compatible) is restricted. The focus is more on only basic drivers > that are written in conjunction with the various kernel facilities." ; > there's not much 3rd party Microsft Driver support. It'd definitely > have to be implemented before > 0.3 release. That would be nice, but it's not practical since nobody has volunteered to work on it and thus it will not get implemented any time soon. If you will work on it or can find someone who will and can give a rough timeframe for its completion (say 5-6 months), I might vote for a delay of a 0.3 release. Casper

2 1

Re: [ros-dev] RE: Collection of wine tools on windows
by Boaz Harrosh 24 Feb '05

24 Feb '05

Rolf Kalbermatter wrote: >This is rubish. > Yes ^ 3 ( that is Yes cubed) Let us all get back on track of this discussion. Must ReactOS and MinGW use the Wine set of headers. 1. ReactOS & MinGW are by themselves GPL, So they are more strict than Wine's header set 2. Headers are out of the scope for License as Rolf explained. Or to be more precise they are the boundary put by the License. "From this API down you are in Library territory". The header is the Line drawn by the Library writer, as what is public API. A GPL program is an LGPL library with the trivial public header of: <c> int main(int argc ,char* argc[]) ; // use only </c> 3. Wine Headers are description of the Win32 API by Microsoft, so what the hell are you talking about. And back to the subject. I have proved that Wine-headers are not only, nice-to-have, but a must in a gcc compilation environment on Windows, like MinGW or Cygwin. Could/did any one see if ReactOS has every thing they need in wine-headers and if not patch in the diff. So is it accepted than! Free Life Boaz

6 5

RE: [ros-dev] Release 0.2.6
by Murphy, Ged (Bolton) 24 Feb '05

24 Feb '05

Jonathan Wilson wrote: > (do we have a DHCP client yet? If not, how hard would > writing one be?) I'm hoping to get started on one very soon. Gedi _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev ************************************************************************ 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

Release 0.2.6
by Jason Filby 24 Feb '05

24 Feb '05

Hi all The consensus on IRC appears to be that we need another 0.2.x release. The reason is that 0.3 is our "network" release and there's still some work to do to justify this. Everyone agree? Cheers Jason

5 5

added a proposed patch to bugzilla
by Roman Hoegg 23 Feb '05

23 Feb '05

Hello everybody! I've been a long time lurker and have decided to finaly contribute something to this wonderful project. quick introduction: 29, male, research assistent at the University of St. Gallen (Switzerland), some C/C++ knowledge (but not enough for serious contributions to an OS) I'm in the process of creating a keyboard layout (it's nearly finished) and have run into a problem which I posted in bugzilla. I was told on #reactos that this is the way to do it. http://reactos.com/bugzilla/show_bug.cgi?id=509 would be cool if someone with experience with keyboard layouts could give me a tip. thanks! Roman Hoegg (RomanH)

1 0

Build is now VERBOSE=yes
by WaxDragon 22 Feb '05

22 Feb '05

ekohl commited some variables into rules.mak for his 13704 change, are all these correct? --- /trunk/reactos/rules.mak 2005/02/21 11:01:32 13703 +++ trunk/reactos/rules.mak 2005/02/21 12:38:50 13704 @@ -1,3 +1,7 @@ +export VERBOSE = yes +export BUILD_MAP = yes +export BUILD_SYM = no + # Default to half-verbose mode ifeq ($(VERBOSE),no) Q = @ @@ -163,6 +167,7 @@ export XSLTPROC = $(Q)xsltproc export MS2PS = $(Q)$(TOOLS_PATH)/ms2ps/ms2ps export WRC = $(Q)$(TOOLS_PATH)/wrc/wrc +export WIDL = $(Q)$(TOOLS_PATH)/widl/widl export STD_CFLAGS = -I$(PATH_TO_TOP)/include -I$(W32API_PATH)/include -pipe -march=$(OARCH) -D_M_IX86 export STD_CPPFLAGS = $(STD_CFLAGS) Andrew -- The cheese stands alone.

3 2

State of the WIDL
by Eric Kohl 22 Feb '05

22 Feb '05

Hi all, there is some good news to tell about WIDL. It is able to build the header file, client stub file and server stub file for _very_ simple rpc applications. I got a slightly modified version of the hello example from MSDN working. There are still a lot of features missing from WIDL but it is able to create stubs for simple functions that don't take any arguments and return no or basic type values. Returning pointers is not supported yet. So, supported functions look like that: void My1stRpcFunc(void); int My2ndRpcFunc(void); unsingned long My3rdRpcFunc(void); Another restriction is the handling of implicit binding handles. These binding handles are usually declared in an ACF file. But since ACF files are not supported yet the declaration must take place in the IDL file. MIDL supports this as well if you use the '/app_config' option. Explicit binding handles are not supported yet. Finally, WIDL does not support MIDLs '/oldnames' option. This option is used to enable the old naming conventions for interface handles. This is a minor issue because the MSDN examples use the old naming conventions. Next, I want to implement support for basic type function arguments. The whole source code to WIDL is published under the LGPL so feel free to contribute it to WINE. Regards, Eric

4 7

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

22 Feb '05

> They are used internally by some other functions inside msvcrt so they must be somewhere > what is going on now is that internally a stically linked library is used but anything referencing those functions > from the outside are being redirected to ntdll. > > What I mean is: If you are forwarding them, why you don´t import them too instead of the static link? > If you are statically linking then why forward them? First: it was not me who added those forwards to ntdll. But it can't see anything wrong with it either. Sure they are all right. In fact I proposed something similar a long time ago. Ask Hyperion :) However the final solution was better. It seems none of the forwarded functions are implemented/duplicated in crt and they are not called from within crt either thus none of the forwarded routines are imported from ntdll by msvcrt/crtdll. Gunnar Maybe I'm out of sync by far or maybe I'm wrong. Snapshots do no work anymore since the move to subversion I guess. I will check again using the old sources and will tell in such case so if you have a chance check it on the most recent ones. In the last snapshot I was able to download there was a libary strings.a statically linked with several components of ReactOS such as ntoskrnl, ntdll, crtdll.dll and msvcrt.dll that means that there are/were at least 4 copies in RAM of the same set of routines. This can be easily ckecked if for example you pick one of the functions and do a binary search on the ROS tree. I think that there could be only one If both crtdll and msvcrt forward them to ntdll and ntdll import them from ntoskrnl and they are set as executable ring0 <-> ring3. But maybe that's to ask a lot for now. I beleive that just taking away the duplicated code crtdll/msvcrt and in case that I'm right import those from ntdll will help more and will be alot easier than the last one. Regards Waldo

1 0

Implementing a help system
by Karim Liman-Tinguiri 22 Feb '05

22 Feb '05

Hello, I've recently joined the ReactOS project (1) where I intend to work as a coder primarily. After downloading the LiveCD and trying it out, I found out it lacks (amongst many) a help system. I believe it should be added amongst the urgent TO-DOs checklist now that the OS runs, provides a minimal GUI, and is stable. Built-in user assistance is essential since the React Operating System is intended for the large audience; not only for hackers. Therefore I am wondering if there is a current project started to code one. If not, I plan to code an open-source version of the winhlp32.exe file located in the system folder able to open and show windows .hlp files. The goal is to have a winhlp32.exe that runs and behaves exactly like (or very close to) that of the Microsoft copyrighted winhlp32.exe. It should therefore be able to serve existing windows apps with a help server without any modification to the program. I've verified the dependencies of winhlp32.exe; all of them have already been implemented in ReactOS, so it should not be a big deal to code it from scratch. Despite the fact that the .hlp file format isn't officially documented, it has already been reverse engineered and its documentation can be found on the web (2). However, if there already is a help support project up and running, I intend to join it. Besides, as soon as this is ready (why not before ?), I advise we convert all documentation on the reactos.com's library (and all further documentation) to the DocBook (SGML) format: it has the advantage of being easily converted on-the-fly to pdf, html, post-script and many others. A tool chain to convert it to .hlp will however have to be created (meanwhile we can use the standard tools for compiling .hlp files). (1) I'm referring to the developer mailing list (2) http://www.geocities.com/mwinterhoff/helpfile.htm

4 6

RE: Collection of wine tools on windows
by Casper Hornstrup 21 Feb '05

21 Feb '05

> -----Original Message----- > From: wine-devel-admin(a)winehq.org > [mailto:wine-devel-admin@winehq.org] On Behalf Of Ivan Leo Puoti > Sent: 21. februar 2005 09:26 > To: wine-devel(a)winehq.com > Cc: ros-dev(a)reactos.com > Subject: Re: Collection of wine tools on windows > > Dimitrie O. Paun wrote: > > Heh, the MinGW folks seem to have some strange > requirements for their > > headers, I don't think they'll drop theirs. But we can > start by having > > ReactOS adopt our headers. > > > > We should also offer our headers as a separate package that > works out > > of the box as a replacement for the MinGW ones. This way people can > > just get our headers if they are better than the MinGW ones. > > Can't the win32api package headers be used to replace the > mingw headers? > > Ivan. W32api IS the MinGW headers. I might vote for using WINE headers in ReactOS if WINE relicensed its headers to a w32api or BSD like license that will allow use in a non-free application. What I would like to see most though, is for all three projects to share w32api. Casper

3 4

Weekend Coder Project - Object Manager Shell Namespace Extension
by Steven Edwards 21 Feb '05

21 Feb '05

Pinging any weekend coders! Currently the ReactOS Explorer implements a browse button for the Object Manager FS and the Registry FS. It would be nice if rather than being hard coded in to explorer this was done via a shell extension that could be used in the Windows explorer or the ReactOS explorer. There example code for creating a Shell Namespace using a Unix filesystem at the following Url. http://www.winehq.org/hypermail/wine-devel/2005/02/0606.html There is example code on how to read the object manager in the following source file. http://svn.reactos.com/viewcvs/trunk/reactos/subsys/system/explorer/shell/n… Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250

1 0

RE: [ros-dev] Implementing a help system
by Casper Hornstrup 21 Feb '05

21 Feb '05

> -----Original Message----- > From: ros-dev-bounces(a)reactos.com > [mailto:ros-dev-bounces@reactos.com] On Behalf Of Karim Liman-Tinguiri > Sent: 21. februar 2005 16:09 > To: ros-dev(a)reactos.com > Subject: [ros-dev] Implementing a help system > > Hello, > > Therefore I am wondering if there is a current project started to code > one. If not, I plan to code an open-source version of the winhlp32.exe > file located in the system folder able to open and show windows .hlp > files. The goal is to have a winhlp32.exe that runs and behaves > exactly like (or very close to) that of the Microsoft copyrighted > winhlp32.exe. It should therefore be able to serve existing windows > apps with a help server without any modification to the program. I've > verified the dependencies of winhlp32.exe; all of them have already > been implemented in ReactOS, so it should not be a big deal to code it > from scratch. Despite the fact that the .hlp file format isn't > officially documented, it has already been reverse engineered and its > documentation can be found on the web (2). However, if there already > is a help support project up and running, I intend to join it. Winhelp is obviously needed for compatibility, but a MS Help clone would be better to use for ReactOS online documentation due to its flexibility. There is a GPL CHM library at: http://freshmeat.net/projects/chmlib/. > Besides, as soon as this is ready (why not before ?), I advise we > convert all documentation on the reactos.com's library (and all > further documentation) to the DocBook (SGML) > format: it has the advantage of being easily converted on-the-fly to > pdf, html, post-script and many others. A tool chain to convert it to > .hlp will however have to be created (meanwhile we can use the > standard tools for compiling .hlp files). See http://svn.reactos.com/viewcvs/trunk/rosdocs/ Casper

2 1

Re: [ros-svn] [ekohl] 13704: Add basic support for creating client and server stub files.
by James Tabor 21 Feb '05

21 Feb '05

ekohl(a)svn.reactos.com wrote: > Add basic support for creating client and server stub files. > > > Added files: > trunk/reactos/tools/widl/client.c > trunk/reactos/tools/widl/client.h > trunk/reactos/tools/widl/server.c > trunk/reactos/tools/widl/server.h > > Updated files: > trunk/reactos/rules.mak > trunk/reactos/tools/widl/Makefile > trunk/reactos/tools/widl/Makefile.in > trunk/reactos/tools/widl/parser.y > trunk/reactos/tools/widl/widl.c > trunk/reactos/tools/widl/widl.h > trunk/reactos/tools/widl/y.tab.c > darkstar:/home/ros/reactos/tools/widl# make gcc -DYYDEBUG=1 -DINT16=SHORT -D__USE_W32API -I../wpp -I../../include/wine -I../../include -c utils.c -o utils.o In file included from ../../include/getopt.h:1, from /usr/include/unistd.h:744, from ../../include/wine/port.h:44, from utils.c:23: ../../include/tgetopt.h:38: error: parse error before '*' token ../../include/tgetopt.h:53: error: parse error before '*' token ../../include/tgetopt.h:57: error: parse error before '}' token ../../include/tgetopt.h:69: error: parse error before "wchar_t" ../../include/tgetopt.h:70: error: parse error before "wchar_t" ../../include/tgetopt.h:72: error: parse error before "wchar_t" ../../include/tgetopt.h:80: error: parse error before "wchar_t" make: *** [utils.o] Error 1 My _mingw.h version 3.7. Do I need this patch to make this work? http://rafb.net/paste/results/WmmE6n90.html Doh! navaraf * r13706 reactos/tools/widl/ (11 files): Fix build on Linux. Never mind, James

1 0

Collection of wine tools on windows
by Boaz Harrosh 21 Feb '05

21 Feb '05

There is a question at the end. Background: I'm putting up a Web-corner with ATL & MFC for other (gcc for now) Compilers. It will include tools, links, documentation, example makefiles, and so on to let people take an MSVC project and compile it under GCC. (+Winelib on other than windows platforms) My first release target is Windows/ReactOS MinGW-PE. What I did is take the work I've done on Linux and port it back to MinGW. At first, as I expected, it did not work at all. So what I did without hesitation is fetch the Wine headers set, + (yes) wine-msvcrt. Completely removed MinGW originally supplied headers put Wine on the Include path, and voila It was compiling Just like on Linux. (Well it didn't link, than it didn't run, because of the weak symbols thing but I fixed all that). I find 3 things bad about MinGW headers. (Please don't take this as flame. I have all the admiration for all involved and no offense is intended) 1) MinGW header-set are Evil - Because they are ugly, with this, no variables names, and all this style for machines guide. This I already carry for 10 years so here it is off my chest. 2) Win32 is not complete - I would say that MFC and ATL/WTL are a very good exercise for the completeness of the Win32 API. Well the wine stuff have every thing we need, MinGW does not 3) msvcrt - msvcrt compatibility is far from satisfactory on MinGW. Wine, since they had to re-implement msvcrt.dll had to have all these funny MS permutations of the c run time. Compiling on MinGW is almost like using wine without MBCS defined. MinGW headers are mainly derived from GCC c-runtime, with a few adjustments for the -mno-cygwin mode. But they are greatly missing all the esoteric stuff that is needed by MFC and ATL. Wine is perfect, thanks to CodeWeavers, need to run all these MFC apps out there. 4) (I know I said 3) It is time, that all projects collaborate on ONE set of headers and ReactOS is the bridge to that - It is a long time do, that Wine's Set of headers are adopted by all projects. MinGW concentrates on PE gcc compilers, and pass the Win32 project to wine. Wine will release a headers only package for every body to use. (This is what I'll do on first release of my project) [Question to the ReactOS team] The windres utility is insufficient for Most of the projects out there. For example one reason my project is not already on the air. (And hence my post) is that it refuses to compile my Toolbar resource tag. (And what is an MFC app with out a toolbar). I have seen some work done on porting wrc to PE is that work done and will you have a pre-compiled binary package for use to use on windows/ReactOS. Same applies to widl. ReactOS should adopt all these Wine tools as part of their regular tools portfolio. MinGW should adopt Wine's / ReactOS's leadership on all these technologies and supply-link to them by default. Go duplicate all these goodies the wine guys are preparing for us with widl. Again guys please let the passed be gone. And put our differences behind us. There are grate things happening, clearly Wine is the Leader here, lets do this sooner than later. Dimi I need your help here Free Life Boaz

4 4

Welcome Herve
by Alex Ionescu 21 Feb '05

21 Feb '05

Finally Mr. Poussineau gets commit! Congrats and welcome to the team, I've been waiting for this on a long time. Amuse toi bien ;) Best regards, Alex Ionescu

2 1

Re: [ros-svn] [navaraf] 13697: I shouldn't commit at night...never!
by Richard Campbell 20 Feb '05

20 Feb '05

You and me both buddy...hehe. Yeah (unfortunately) i'm still around...I've a bad case of code burnout though, and a VERY bad case of WoW addiction. Richard navaraf(a)svn.reactos.com wrote: >I shouldn't commit at night...never! > > >Updated files: >trunk/reactos/w32api/include/ddk/winddk.h > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > >

1 0

Re: [ros-svn] [gvg] 13652: Import Wine Resource Compiler and use it for winedll's
by Eric Kohl 20 Feb '05

20 Feb '05

gvg(a)svn.reactos.com wrote: > Import Wine Resource Compiler and use it for winedll's > Gé, wouldn't it be better to import the wpp and unicode libraries into separate directories within the tools directory? This way wmc could also use the unicode library and support all known codepages. I also have a modified widl in my source tree which can build simple client and server stub files. Widl requires wpp, so sharing wpp and unicode would be useful. Could you also create a vendor drop of widl in tools/widl? Regards, Eric

2 2

Excuse me. What way...?
by ea＠iol.it 20 Feb '05

20 Feb '05

Hi all! I post this message, because I would like to read you comments and opinions about the way to take to implement multiuser support in the Win32 subsystem of ReactOS. Multiuser support for Win32 is, in fact, named "terminal services". There are, as you know, two possible ways. Microsoft was at the same crossroad, when they had to make Win32 in NT 4.0 multiuser. a) make multiuser compliant csrss.exe+win32k.sys b) load separate instances of csrss.exe+win32k.sys B is obviously less expensive, because you do not touch the code in csrss.exe and in win32k.sys and therefore you need no more debugging than regular single user Win32. It is a hack, but it sells very well. But Microsoft is committed to market. ReactOS isn't. Obviously, as I like challenges (otherwise why would you devote your time to a project like ReactOS?), and clean design in software, I vote for implementing (a). Please comment about: - easy/hard; - compatible/incompatible; - impact on current design; - huh? ____________________________________________________________ Navighi a 2 MEGA e i primi 3 mesi sono GRATIS. Scegli Libero Adsl Flat senza limiti su http://www.libero.it

4 3

RE: [weiden] 13639: 2. fixed GetVersionEx()
by Ge van Geldorp 20 Feb '05

20 Feb '05

> From: weiden(a)svn.reactos.com > > 2. fixed GetVersionEx() > > Updated files: > trunk/reactos/lib/kernel32/misc/env.c The part starting :/* append a reactos specific string to the szCSDVersion string */" is wrong. You've just appended the ReactOS version string to the existing szCSDVersion, but it should be added after the terminating null of the existing szCSDVersion, i.e. "Service Pack 6\0ReactOS 0.3-SVN (Build 20050219-r13360)\0". This way, ReactOS unaware apps will just get the standard CSDVersion (Service Pack 6), while ReactOS aware apps can get the ReactOS version. Discussed on the mailing list http://reactos.com:8080/archives/public/ros-dev/2004-December/001117.html and followups. Gé van Geldorp.

2 1

PeakMessage Crash
by Steven Edwards 20 Feb '05

20 Feb '05

Hi All, I have a 100% reproducable crash in Win32k due to a bad value being passed to PeakMessage. Run taskmgr and attempt to double click on the top left corner to close the application. Thanks Steven __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

2 1

Re: SM: subsystem registration (partial)
by Sylvain Petreolle 20 Feb '05

20 Feb '05

Hi ea, It seems this smss commit is actually missing some code. In client.c, you changed SmCreateClient. Now this file doesnt compile since you are using "SM_CONNECT_DATA_SIZE", which isnt defined anywhere in the tree. Just for a recall: you forgot to include <sm/helper.h> in smss.h (see 13663) ===== Usurp (aka Sylvain Petreolle) humans are like computers, yesterday the BIOS was all - today its just a word

1 0

[ros-svn] 13656: Don't use svn command line tool to getrevision number
by Ge van Geldorp 19 Feb '05

19 Feb '05

> From: gvg(a)svn.reactos.com > > Don't use svn command line tool to get revision number > XML code stolen from the xmlbuildsystem branch, we need > to merge this when merging the xmlbuildsystem back into trunk If you get weird error messages when svn up'ing in reactos/tools on Linux, remove reactos/tools/buildno. "reactos/tools/buildno" used to be an executable, now it's a directory. Doing a "make clean" first and then a "svn up" works ok. Windows shouldn't be a problem, there is no name conflict there as the old executable was named buildno.exe. Gé van Geldorp.

1 0

Recent SVN annoyances...
by Alex Ionescu 19 Feb '05

19 Feb '05

Hi, Some things that need to be fixed ASAP: 1) Gunnar's additions to ntdll's critical.c break cmd.exe. This is not his fault per-se, since his checks are legitimate. It seems cmd.exe is not intiailizing the CS before using it. Although I understand that his changes are needed, I would prefer devs to actually test their changes and fix the broken apps, and not just break them, since this is a regression in a way (much like Thomas's pseh fixes). 2) Thomas' recent patches flood debug output with an error about NtGdiCombineRgn. Once again, please either fix the broken apps which do this, or show the message only once. It makes debugging impossible. Best regards, Alex Ionescu

3 6

Re: [ros-svn] [hbirr] 13570: - Started the rewriting of the cache manger.
by Filip Navara 19 Feb '05

19 Feb '05

hbirr(a)svn.reactos.com wrote: >- Started the rewriting of the cache manger. >- The new cache manager uses section objects and maps the content of cached files > into the kernel address space for functions like CcCopyRead. >- The implementation isn't complete. It works for me to compile ros on ros if enough ram is available. > > Very good work! I tried it and needed the attached changes in order to boot... [cc02.diff] Don't try to map data past the end of file in VFAT. [cc03.diff] Fix incorrect check in CcMapData. Also I've patch which fixes fast mutex implementation and it's usage, which depends on these cache manager changes. Regards, Filip

2 4

RE: [ros-svn] [gvg] 13638: Include svn revision in build string
by Ge van Geldorp 18 Feb '05

18 Feb '05

> From: gvg(a)svn.reactos.com > > Include svn revision in build string It seems that there are quite some woosies out there who don't have the "svn" command line tool installed. I'll change buildno to not depend on svn, but this might take a little while. Gé van Geldorp.

1 0

Error Compiling
by James Tabor 18 Feb '05

18 Feb '05

crt: [CC] float/clearfp.c float/clearfp.c: In function `_clearfp': float/clearfp.c:8: warning: implicit declaration of function `_statusfp' make[1]: *** [float/clearfp.o] Error 1 make: *** [crt] Error 2 Here is a Oops! James

2 2

Problem synchronizing winmm.dll
by Ge van Geldorp 18 Feb '05

18 Feb '05

I'm running into a problem importing the latest Wine winmm sources. The resource file winmm_res.rc now contains Unicode strings (in the CORE and VIDEODISC resources). Windres from binutils 2.15.94 doesn't like those. I'm not sure how to solve this. Any ideas? Gé van Geldorp.

3 3

Something new...
by David Eckert 18 Feb '05

18 Feb '05

Hey, I was snooping around and found a nice program that boots FreeBSD in Windows itself, I have not tested it to see what it does exactly, but this may be a good thing to see if ReactOS can be booted from it ;) The link for the full source code and binary is below... http://ftp5.se.freebsd.org/FreeBSD-current/xperimnt/winboot/ -- -David W. Eckert

1 0

crt header removal+mingw+linux=problem
by Gunnar Dalsnes 17 Feb '05

17 Feb '05

I have modified crt to use native-mingw headers and deleted the ros-local copies. This works fine on windows but people are having problems on linux. It seem on linux the search order for header files are different from windows. On windows, mingw\include is searched first, then mingw\lib\gcc\mingw32\x.x.x\include, but on linux mingw/x.x.x/include is searched first, then mingw/include. This means that some mingw headers are never included in linux (those who exist both places), specially float.h. The mingw float.h has #include_next <float.h>, so its obvious that the mingw headers are supposed to go first. How do i fix this? Is this a mingw bug? Regards Gunnar

1 0

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

17 Feb '05

De: ros-dev-bounces(a)reactos.com en nombre de Gunnar Dalsnes Enviado el: Mar 2/1/2005 3:58 p.m. Para: ReactOS Development List Asunto: Re: [ros-dev] msvcrt/crtdll "merge" Waldo Alvarez Cañizares wrote: > 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. They are really forwarded. stuff=SOMEDLL.stuff means its forwarded. This is standard module-definition (.def) syntax and its nothing half baked about it. Forwarded functions are resolved by the loader thus they are not imported by the dll forwarding them. They are used internally by some other functions inside msvcrt so they must be somewhere what is going on now is that internally a stically linked library is used but anything referencing those functions from the outside are being redirected to ntdll. What I mean is: If you are forwarding them, why you don´t import them too instead of the static link? If you are statically linking then why forward them? > 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. What do you mean "not going to forward it"??? stuff=SOMEDLL.stuff means its forwarded!!! > > >>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. > Hmm, still dont understand:-/ Ntdll exports loads of functions that arent documented anywhere. But we better document that. Because we want to be compatible Right? And that probably means that at some degree WinCE and XP have common source code and maybe are not so far away one of each other as some ppl around think. Hey just some curiosity nothing more is like when win2k came out it inherited win98/Me 's explorer, it inherited the same bugs also, that´s why. At the end nothing important, well unless you try to reduce the code of some other library maybe. Best Regards Waldo Gunnar

4 3

stdio/wtmpnam.c: compile error
by ea＠iol.it 17 Feb '05

17 Feb '05

I get this error compiling with gcc 3.3.1: crt: [CC] stdio/wtmpnam.c stdio/wtmpnam.c:5:2: #import is obsolete, use an #ifndef wrapper in the header f ile make[1]: *** [stdio/wtmpnam.o] Error 1 make: *** [crt] Error 2 ____________________________________________________________ 6X velocizzare la tua navigazione a 56k? 6X Web Accelerator di Libero! Scaricalo su INTERNET GRATIS 6X http://www.libero.it

1 0

RE: [ros-dev] MISSING LINK
by Murphy, Ged (Bolton) 16 Feb '05

16 Feb '05

Looks good. Zip it up and upload it to the net and someone will pick it up. Would be good if you could also zip up the full source as I would be interested in going through it, and I don't have access to SVN from work so can't apply any patches. Ged. -----Original Message----- From: Thomas Larsen [mailto:sikker2004@yahoo.com] Sent: 15 February 2005 08:48 To: ReactOS Development List Subject: [ros-dev] MISSING LINK RosMine Missing uploader could anybody be ******* nice to upload this for me I Got Improved Sound Support - Included sounds New Icons better look Improved Code Help System Send Your E-mail and i would send it to U..... Thomas __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com ************************************************************************ 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 2

Re: [ros-dev] __attribute__((weak)) - in mingw
by Danny Smith 16 Feb '05

16 Feb '05

Boaz Harrosh wrote: > Danny Smith wrote: > > Will you have pre-compiled binaries with these patches for download on > ReactOS.org. No, I am a Mingw developer and I put binaries at mingw's SF site.. Please do, it is a very nice place to have them. And while > we are on the subject. GCC 3.4 is totally broken for ATL. It doesn't > even come close to even imagine to compile ATL. From some of the stuff I > saw it is breaking the standard. It took me 2 minutes to see that it has > no hope. So I have two things. 1 - please if you can keep a live version > of 3.3 with all above enhancements for us, poor, wrote millions of > Microsoft code, guys. 2 - Would you mine talking to me (on the list) > about what is broken in 3.4 and try to see what needs fixing on the > compiler side and what need to be done on the code side. I'll send you > examples of code and we can see what should be done for them and if such > changes are acceptable. > Please, if you want me to stay involved in this discusion,send posts to mingw-users(a)sourceforge.net. I have no intention of "fixing" gcc-3.3.x. My main interest is 4.0, but I will probably backport some changes from 4.0 branch into next gcc 3.4.4 mingw release. If you have specific examples of things that are broken on 3.4.x with mingw please submit a bug report. See http://www.mingw.org/bugs.shtml Danny > Free Life > Boaz > > P.S > My posts do not reach the List. At first I thought they don't go out at > all. But I see you got them. Any body got an Idea what can happen that > causes posts to get lost. Same thing happens to me with wine. Pretty > much consistent now. See if this goes threw

3 2

Re: [ros-svn] [weiden] 13576: 1. a few previous mode fixes
by Alex Ionescu 15 Feb '05

15 Feb '05

weiden(a)svn.reactos.com wrote: >1. a few previous mode fixes > > >Updated files: >trunk/reactos/ntoskrnl/ke/alert.c >trunk/reactos/ntoskrnl/ke/apc.c >trunk/reactos/ntoskrnl/ke/error.c > > > Please revert these "fixes". They are incorrect. Best regards, Alex Ionescu

5 4

Re: [ros-dev] __attribute__((weak)) - in mingw
by Danny Smith 15 Feb '05

15 Feb '05

Boaz Harrosh wrote: >> Danny Smith wrote: >> >>> Boaz Harrosh wrote: >>> >>> >>>> [Q] I'm (well ATL is) using __attribute__((weak)) (translated from >>>> __declspec( selectany) ) for instantiation of members and variables in >>>> headers. I had no problem with it On GCC in Linux (gcc 3.2.2). On MinGW >>>> >>>> >>> >>> IMAGE_COMDAT_SELECT_ANY is not quite same as PECOFF version of "weak" , but >>> AFAICT is equivalent to the GCC section flag ".linkonce discard". I don't >>> think there is a way for the user to specify that for data using an >>> attribute, but it could be done with asm statements. >>> >>> .weak directive is partially supported in current binutils CVS. >>> __attribute__((weak)) is not supported by GCC-3.4.x but will be in the next >>> major GCC release (4.0.0). >>> Sorry, that was unclear. I should have qualified with "on windows targets" >>> The semantics of weak for PECOFF differ from that on Linux.See the PECOFF60 >>> specs (Microsoft Portable Executable and Common Object File Format >>> Specification) section on weak externals >>> >>> Danny >>> >>> >> (binutils at sources dot redhat dot com please also cc me as I'm not on >> the list) >> >> Attached is a proof (See fooInt.h) that gcc (gcc version 3.2 (mingw >> special 20020817-1)) has support for weak symbols. Just not with the >> regular syntax. >> But when templates are used duplicate symbols are merged by the linker. >> >> What would be the assembler magic to cram into the __WEAK__ definition >> that would make this project link? >> I am currently testing a patch to GCC to add an __attribute__ ((selectany)) that would work the way it is discribed in MS docs and in the spec of IMAGE_COMDAT_SELECT_ANY in PECOFF doc. Basically it puts the symbol into its own section with ".linkonce discard" charcteristics. __declspec (selectany) int foo = 1; becomes: .globl _foo .section .data$foo,"w" .linkonce discard .align 4 _foo: .long 1 So far the only problem I've seen is that, although it works for global objects with non-trivial constructors eg: struct X { static int s; int m; X(int _i) : m(_i) { m++; } }; __declspec(selectany) int X::s = -1; // OK __declspec(selectany) X x(1); // This is OK but app will be bloated with // duplicate initialization code. . I haven't figured out how to get rid of the duplicated inititialization code I will submit the patch for comment once GCC trunk branches. Danny >> Free Life >> Boaz >> > >

1 0

Re: [ros-svn] [gvg] 13584: Fix ROUND_UP when N is a multiple of S. Proposed by unC0Rr.
by Hartmut Birr 15 Feb '05

15 Feb '05

gvg(a)svn.reactos.com schrieb: >Fix ROUND_UP when N is a multiple of S. Proposed by unC0Rr. > > > >Updated files: >trunk/reactos/tools/mkhive/binhive.c > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > > > Hi, I don't like this implemention (and the old one) of ROUND_UP and ROUND_DOWN. I would prefer: #define ROUND_UP(N,S) (((N) + (S) -1) & ~((S) -1)) #define ROUND_DOWN(N,S) ((N) & ~((S) - 1)) - Hartmut

2 1

msvcrt headers removal
by Gunnar Dalsnes 14 Feb '05

14 Feb '05

Hi. Does anyone know why ros duplicate the mingw msvcrt headers in include\msvcrt? If no one objects, I will remove those duplicates and use the mingw headers 100%. Gunnar

2 1

Re: [ros-svn] [fireball] 13520: Added cromwell's drivers into build/install process. Now we have two alternatives: usbport/usbXhci or usbcore/ohci.sys. With time they will be merged into one, or cromwell will be wasted and usbport/usbXhci will be written from scratch.
by Mark Tempel 14 Feb '05

14 Feb '05

fireball(a)svn.reactos.com wrote: >Added cromwell's drivers into build/install process. Now we have two alternatives: usbport/usbXhci or usbcore/ohci.sys. With time they will be merged into one, or cromwell will be wasted and usbport/usbXhci will be written from scratch. > > >Updated files: >trunk/reactos/drivers/usb/Makefile > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > > > I would expect that USBPORT/USBXXXHCI will just delegate to cromwell. That way we can use cromwell like we use wine or oskit tcp... --mark

1 0

typo in hivesys.inf
by netzimme＠netscape.net 14 Feb '05

14 Feb '05

Hi Here is a little patch for the typo: Index: hivesys.inf =================================================================== --- hivesys.inf (revision 13570) +++ hivesys.inf (working copy) @@ -11,7 +11,7 @@ HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E965-E325-11CE-BFC1-08002BE10318}",,0x00000000,"DVD/CD-ROM drives" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E965-E325-11CE-BFC1-08002BE10318}","Class",0x00000000,"CDROM" -HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}","EnumPropPages32",0x00000000,"MmSys.Cpl,MediaPropPageProvider" +HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E965-E325-11CE-BFC1-08002BE10318}","EnumPropPages32",0x00000000,"MmSys.Cpl,MediaPropPageProvider" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E965-E325-11CE-BFC1-08002BE10318}","Icon",0x00000000,"-20" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E965-E325-11CE-BFC1-08002BE10318}","NoInstallClass",0x00000000,"1" __________________________________________________________________ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp

1 0

Re: [ros-dev] NIC RTL8029 will work with NE2000
by netzimme＠netscape.net 14 Feb '05

14 Feb '05

James Tabor <jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> wrote: >netzimme(a)netscape.net wrote: >> Hi Ros-Dev >> >> I have a patch that let a RTL8029 based NIC work with >> the ne2000 driver and partiell with the original driver. >> The problem is when the 'size' is 0 and the queriy run in >> NDIS_STATUS_INVALID_LENGTH. Then the size is never set to >> the a new value. >> >Hi, >What was your hivesys.inf setup like? Hi James Add this entries : HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0001","Port",0x00000000,"B800" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0001","Irq",0x00000000,"A" This can you get when you run the DOS-Utility from the NIC to see the IRQ and Port Number. Under Windows 2000 there are difference entries. HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0001","BusType",0x00000000,"5" This is from the Registry from Windows 2000 HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0001","SlotNumber",0x00000000,"11" HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0001","BusNumber",0x00000000,"0" And this i get from the BIOS bootscreen. HKLM,"SYSTEM\CurrentControlSet\Services\Ne2000","Start",0x00010001,0x00000003 To start the ne2000 driver. Hope this helps Daniel __________________________________________________________________ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp

1 0

NIC RTL8029 will work with NE2000
by netzimme＠netscape.net 14 Feb '05

14 Feb '05

Hi Ros-Dev I have a patch that let a RTL8029 based NIC work with the ne2000 driver and partiell with the original driver. The problem is when the 'size' is 0 and the queriy run in NDIS_STATUS_INVALID_LENGTH. Then the size is never set to the a new value. Index: miniport.c =================================================================== --- miniport.c (revision 13495) +++ miniport.c (working copy) @@ -603,7 +603,7 @@ Adapter->NdisMiniportBlock.MiniportAdapterContext, Oid, Adapter->QueryBuffer, - Size, + Adapter->QueryBufferLength, BytesWritten, &BytesNeeded); } __________________________________________________________________ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp

2 1

__attribute__((weak)) - in mingw
by Boaz Harrosh 14 Feb '05

14 Feb '05

Hi List I'm finally on my ass trying to redo the ATL/MFC Job from a year ago. This time I decided to start on windows with MinGW than move the MinGW makefiles to be used with winegcc. It is a grate test for winegcc and the windows API in general. Well it turns out to be a very big test for MinGW as well. The headers are in a very bad shape. I had to use Wine headers to be able to compile. but I'll leave all that to a later e-mail. [Q] I'm (well ATL is) using __attribute__((weak)) (translated from __declspec( selectany) ) for instantiation of members and variables in headers. I had no problem with it On GCC in Linux (gcc 3.2.2). On MinGW I get below warning. And needless to say that I get a Linker duplicate symbol Error. Any Ideas on how to overcome this. Is this a g++ only bug? <g++ warning example> H:\Dinosaur\OneSource\MinGWStudio\msvc\atl\include\atlhost.h:56: warning: weak declaration of `UINT ATL::WM_ATLGETCONTROL' not supported </g++ warrning example> <linker error example> H:\Dinosaur\OneSource\MinGWStudio\msvc\atl\include\atlwin.h: multiple definition of `ATL::WM_ATLGETCONTROL' H:\Dinosaur\OneSource\MinGWStudio\Samples\AtlWB\Debug\aboutdlg.o(.bss+0x1c):H:\Dinosaur\OneSource\MinGWStudio\msvc\atl\include\atlwin.h: first defined here </linker error example> Please forgive me for sending it here and not to MinGW list. But I feel more at home here than there. ( :( ) Free Life Boaz

3 2

creating a branch
by Hartmut Birr 13 Feb '05

13 Feb '05

Hi, I would like to create a branch in our repository. I'm not sure what I have to do exactly. Is the following command correct? svn copy http://svn.reactos.com/trunk/reactos http://svn.reactos.com/branches/cache_manager_rewrite/reactos - Hartmut

3 8

Re: [ros-svn] [gvg] 13518: Sync to Wine-20050211
by Steven Edwards 13 Feb '05

13 Feb '05

--- gvg(a)svn.reactos.com wrote: > Sync to Wine-20050211 > - add support for Edit boxes in MSI dialogs ..... Just a short note. With this patch most installars using MSI might be able start on ReactOS but there seems to be some sort of communication issue when they try to tell services to load msiexec. I added a Windows Installer service here in my tree but still have not had much luck. If someone wants to sync msiexec.exe with winehq and have a look we can then see how far iTunes and Office will get. Thanks Steven __________________________________ Do you Yahoo!? All your favorites on one personal page � Try My Yahoo! http://my.yahoo.com

2 3

Re: [ros-svn] [gvg] 13518: Sync to Wine-20050211
by James Tabor 13 Feb '05

13 Feb '05

Hi! There are CR's in the files! James gvg(a)svn.reactos.com wrote: > Sync to Wine-20050211 snip.. > > > > Added files: > trunk/reactos/include/wine/msidefs.h > trunk/reactos/lib/msi/action.h > trunk/reactos/lib/msi/appsearch.c > trunk/reactos/lib/msi/custom.c > trunk/reactos/lib/msi/dialog.c > trunk/reactos/lib/msi/format.c > trunk/reactos/lib/msi/msi.rc > trunk/reactos/lib/msi/msi_En.rc > trunk/reactos/lib/msi/preview.c > trunk/reactos/lib/msi/registry.c > > Updated files: > trunk/reactos/include/wine/msi.h > trunk/reactos/lib/msi/Makefile.in > trunk/reactos/lib/msi/action.c > trunk/reactos/lib/msi/cond.tab.c > trunk/reactos/lib/msi/cond.tab.h > trunk/reactos/lib/msi/cond.y > trunk/reactos/lib/msi/create.c > trunk/reactos/lib/msi/distinct.c > trunk/reactos/lib/msi/handle.c > trunk/reactos/lib/msi/insert.c > trunk/reactos/lib/msi/msi.c > trunk/reactos/lib/msi/msi.spec > trunk/reactos/lib/msi/msipriv.h > trunk/reactos/lib/msi/msiquery.c > trunk/reactos/lib/msi/order.c > trunk/reactos/lib/msi/package.c > trunk/reactos/lib/msi/record.c > trunk/reactos/lib/msi/select.c > trunk/reactos/lib/msi/sql.tab.c > trunk/reactos/lib/msi/sql.y > trunk/reactos/lib/msi/string.c > trunk/reactos/lib/msi/suminfo.c > trunk/reactos/lib/msi/table.c > trunk/reactos/lib/msi/update.c > trunk/reactos/lib/msi/where.c >

1 0

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

Re: [ros-svn] [navaraf] 13369: Force non-inlining of ctype functions even in OPTIMIZED builds. Fixes bug #497.
by Alex Ionescu 31 Jan '05

31 Jan '05

navaraf(a)svn.reactos.com wrote: >Force non-inlining of ctype functions even in OPTIMIZED builds. Fixes bug #497. > > >Updated files: >trunk/reactos/lib/kjs/makefile > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > > Aren't you forcing non-inlining of EVERY function by doing this? Isn't it better to enable the special no ctype inline macro? Best regards, Alex Ionescu

2 2

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

30 Jan '05

Hi Gunnar: Great! less duplicated code == better code I had planning to report this about msvcrt/crtdll the first chance I could get to read my e-mail, but now that you talked then there's no better chance than this I think. I was playing with msvcrt dll a couple of days ago because I was trying to test some apps against it and to maybe find some of the multithreading issues it contains. Well I dropped it because I really had no time but one thing I noticed is that there are some entries in the .def file something like this strlen=ntdll.strlen only strings routines if I remember well. Now after I got the binary file (.dll) I was inspecting it with LordPE, a tool to sniff every detail of PE's and saw that actually those routines are not imported by crtdll (maybe because of the strings.a statically linked) also I saw that msvcrt.dll is importing functions from itself funny that is something I never saw before (Is ROS parsing the exports table before the imports one? Just curious). But worst there are 2 references to msvcrt with different functions that the -O flag when passed to the linker can't fix. I have seen this before in some applications compiled with mingw (freecraft for example. Could be this an unnoticed bug in mingw's linker? If It is, it doesn't harm but it sucks to not have it the better way you can if it is easy to do it). btw I was also looking for string routines exported by ntdll in order to squeeze a bit more both libraries and noticed in XP's ntdll some functions that at the beginning I thought were mistyped (It would not be the first time) but when I took a look at msdn Tada! WindowsCE functions, nothing about XP/2k... but there they ARE. Please do not forget to fix those problems with exports if you can, or anyone with a chance, those libraries stink a lot. I still don't understand every detail on how the whole thing works: build system, linker... so this is a "I don't know how to fix", at least for now. Best Regards Waldo Alvarez ________________________________ From: ros-dev-bounces(a)reactos.com on behalf of Gunnar Dalsnes Sent: Wed 1/26/2005 8:19 PM To: ReactOS Development List Subject: [ros-dev] msvcrt/crtdll "merge" Hi, I'm currently "merging" msvcrt and crtdll (again). I'll move msvcrt into a library lib\crt and have msvcrt and crtdll link against it. Only dllmain.c will be left in msvcrt/crtdll. Most of (99.9%) crtdll will be dropped. It all seems to work nicely. One problem thou: I ran into some header problems, where i relied on some stuff in include\msvcrt\string.h but no matter what, mingw\include\string.h were included instead (and they both defined _STRING_H_). After looking at the headers in inlcude\msvcrt they all seem to be ripped from mingw. Does anyone know why they were put in include\msvcrt when mingw has headers for all of this stuff? Can i just remove them (include\msvcrt)? I looked at many depends files and saw most files depend on many mingw headers. Is this correct? Should we depend on mingw headers at all? Gunnar _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev

4 3

Calling all enthusiasts! Become a JANITOR (Just A Newbie Intensively Training On ReactOS) today!
by Alex Ionescu 29 Jan '05

29 Jan '05

Dear ReactOS enthusiasts and friends, We are currently in dire need of motivated people to help us build the future OS of the masses. While our developers are busily creating new code and fixing bugs, there remain dozens, if not more, of things to take care of in our tree and in our code. I would like to extend an open invitation to anyone interested on becoming a JANITOR (Just A Newbie Intensively Training On ReactOS). As a JANITOR, you will join a team of people, which, just like you, want to see ReactOS succeed and have some spare time to help. You do NOT need any coding experience! Most of the time, only simple word processing skills are needed. Janitorial jobs will include cleaning up comment headers, standardizing the debug system, alphabetizing code and organizing files, compiling a list of fixmes, checking for spelling mistakes, etc. These jobs will be custom tailored to your abilities, and there will be no time limits (but you must commit to doing the job). Also, JANITORs will have access to an online collaboration site where the current top-priority jobs are presented, and where they can commit to one of them. You can also share the workload and work in teams, or however you work best. A status system will be available to monitor the progression of jobs, and many more tools will become available. So don't delay, and join the JANITOR program today! Send me an e-mail at alex(a)relsoft.net with your name, e-mail and contact availabily (MSN, ICQ, IRC (preferred)). A real-time communication tool will be preferred, but I can acustom to people demanding exclusively e-mail contact (since the JANITOR Project Site will have most of the information). I know that many of you want to help but that the current state of the outdatedness of the website and documentation, as well as the general lack of directions are discouraging you. This will be a unique experience to leave your mark in ReactOS. Best regards, Alex Ionescu ReactOS JANITOR Program Manager NOTE to Devs: The JANITOR Program is fully the child of my brain and is a personal project, and will not use the ReactOS bandwidth, site, or other resources unless explicit permission and agreement is made by all developers. You will not need to do any additional task or handle anything more and this will not affect your workload in any way.

4 6

Re: [ros-diffs] [weiden] 13346: 1. fixed InbvPutPixels() to save theebx register which caused bootvid to crash when built withoptimizations
by d_layer 28 Jan '05

28 Jan '05

Hello, weiden(a)svn.reactos.com wrote: > 1. fixed InbvPutPixels() to save the ebx register which caused bootvid > to crash when built with optimizations You need to save the esi register too. ebx, esi, edi, and ebp are callee-saved registers in win32/x86. VC++ and gcc expect external functions not to modify these registers. http://msdn.microsoft.com/library/en-us/vclang/html/_core_argument_passing_… | The compiler generates prolog and epilog code to save and restore | the ESI, EDI, EBX, and EBP registers, if they are used in the function. -- d_layer

2 1

multiboot.S patch in need of review, please
by Royce Mitchell III 28 Jan '05

28 Jan '05

I was in a strange mood and decided to try to implement something Alex wanted. I've done the leg-work on this, but need someone familiar with boot-up and particularly smp to review this patch. I do not have access to smp, and do not wish to break it. This patch implements the /3G switch from within multiboot.S, which is necessary in order to configure the page tables correctly. I noticed some code in _main() that was processing a 3G switch on the command-line, and I can't understand how it could possibly work because it's not readjusting the page tables, nor does it transition to the 0xC0000000 address space that I can see, so I don't think that code actually works. If it does, I'm glad to be proved wrong. The patch I've written makes an assumption that lowmem is available when application processors execute the code. I can't seem to figure out how or where the application processor(s) actually get told to start executing, so I don't know if this assumption is true. However, if it's not true, if someone could point me to the code that inits the application processors, I can configure them to pass the needed info via %ebp or something. Finally, I haven't actually tried booting this code. I wanted someone to review it first for obvious blunders, or to tell me, if necessary, that I've wasted my time ;) If I'm on the right track then, when I'm feeling motivated enough again, I will actually try booting it.

5 14

ROS crashes when installing vmware driver
by Gedi 28 Jan '05

28 Jan '05

This has only come about within the last few days for me. The build and install goes fine. As does the setup wizard. However, when running the wizard to install the VMware SVGA driver, it crashes. I've attached the log, anyone any ideas? Gedi Used memory 237568Kb (mm/virtual.c:214) FIXME: MEMORY_AREA_SYSTEM case incomplete (or possibly wrong) for NtQueryVirtualMemory() (ke/main.c:576) Module: 'ntoskrnl.exe' at 80000000, length 0x000de000 (ke/main.c:576) Module: 'HAL.DLL' at 800de000, length 0x00012c28 (ke/main.c:576) Module: 'SYSTEM' at 800f1000, length 0x00018000 (ke/main.c:576) Module: 'HARDWARE' at 80109000, length 0x00004000 (ke/main.c:576) Module: 'ansi.nls' at 8010d000, length 0x00010222 (ke/main.c:576) Module: 'oem.nls' at 8011e000, length 0x00010422 (ke/main.c:576) Module: 'casemap.nls' at 8012f000, length 0x00001306 (ke/main.c:576) Module: 'pci.sys' at 80131000, length 0x0000a123 (ke/main.c:576) Module: 'acpi.sys' at 8013c000, length 0x00033406 (ke/main.c:576) Module: 'scsiport.sys' at 80170000, length 0x0000e6fe (ke/main.c:576) Module: 'atapi.sys' at 8017f000, length 0x0000a18b (ke/main.c:576) Module: 'class2.sys' at 8018a000, length 0x0000c5b8 (ke/main.c:576) Module: 'disk.sys' at 80197000, length 0x0000b31e (ke/main.c:576) Module: 'vfatfs.sys' at 801a3000, length 0x0001b069 (ke/main.c:576) Module: 'bootvid.sys' at 801bf000, length 0x00020afb (ke/main.c:576) Module: 'ndis.sys' at 801e0000, length 0x00022fd3 (ke/main.c:600) Process system hive registry chunk at 800f1000 (ke/main.c:615) Process hardware hive registry chunk at 80109000 DriverBase for \SystemRoot\system32\drivers\pci.sys: 9cc86000 Peripheral Component Interconnect Bus Driver (ldr/loader.c:309) Could not open module file: \SystemRoot\system32\drivers\pcnet.sys (io/pnpmgr.c:1526) Initialization of service PCNet failed (Status c0000001) (io/pnpmgr.c:1526) Initialization of service vmx_svga failed (Status c0000001) (ldr/loader.c:309) Could not open module file: \SystemRoot\system32\drivers\usbuhci.sys (io/pnpmgr.c:1526) Initialization of service usbuhci failed (Status c0000001) (ldr/loader.c:309) Could not open module file: \SystemRoot\system32\drivers\pcnet.sys (io/pnpmgr.c:1526) Initialization of service PCNet failed (Status c0000001) (io/pnpmgr.c:1526) Initialization of service vmx_svga failed (Status c0000001) (ldr/loader.c:309) Could not open module file: \SystemRoot\system32\drivers\usbuhci.sys (io/pnpmgr.c:1526) Initialization of service usbuhci failed (Status c0000001) (io/pnpmgr.c:1526) Initialization of service Ne2000 failed (Status c0000001) DriverBase for acpi.sys: 9cc8f000 Advanced Configuration and Power Interface Bus Driver ACPI: System firmware supports: +------------------------------------------------------------ | Sx states: +S0 -S1 -S2 -S3 -S4 +S5 +------------------------------------------------------------ Power Button: found DriverBase for scsiport.sys: 9ccbe000 DriverBase for atapi.sys: 9ccc9000 DriverBase for class2.sys: 9ccd3000 DriverBase for disk.sys: 9ccdc000 DriverBase for vfatfs.sys: 9cce4000 DriverBase for bootvid.sys: 9ccf8000 DriverBase for ndis.sys: 9cd18000 (ke/main.c:676) CommandLine: multi(0)disk(0)rdisk(0)partition(1)\ReactOS /DEBUGPORT=COM1 /NOGUIBOOT (ke/main.c:677) MmSystemRangeStart: 0x80000000 DriverBase for \SystemRoot\system32\drivers\pcnet.sys: 9cd48000 (io/pnpmgr.c:1526) Initialization of service vmx_svga failed (Status c0000001) (ldr/loader.c:309) Could not open module file: \SystemRoot\system32\drivers\usbuhci.sys (io/pnpmgr.c:1526) Initialization of service usbuhci failed (Status c0000034) (io/pnpmgr.c:1526) Initialization of service Ne2000 failed (Status c0000001) DriverBase for \SystemRoot\system32\drivers\floppy.sys: 9cdbb000 DriverBase for \SystemRoot\system32\drivers\cdrom.sys: 9cddb000 DriverBase for \SystemRoot\system32\drivers\fs_rec.sys: 9cdea000 DriverBase for \SystemRoot\system32\drivers\beep.sys: 9cdf8000 (ldr/loader.c:309) Could not open module file: \SystemRoot\system32\drivers\sndblst.sys (ldr/loader.c:309) Could not open module file: \SystemRoot\system32\drivers\es137140.sys (ldr/loader.c:309) Could not open module file: \SystemRoot\system32\drivers\mpu401.sys DriverBase for \SystemRoot\system32\drivers\null.sys: 9ce36000 DriverBase for \SystemRoot\system32\drivers\serial.sys: 9ce46000 Serial Driver 0.0.2 DriverBase for \SystemRoot\system32\drivers\psaux.sys: 9ce5c000 DriverBase for \SystemRoot\system32\drivers\keyboard.sys: 9ce75000 DriverBase for \SystemRoot\system32\drivers\mouclass.sys: 9ce85000 (ldr/loader.c:309) Could not open module file: \SystemRoot\system32\drivers\debugout.sys DriverBase for \SystemRoot\system32\drivers\blue.sys: 9ce93000 DriverBase for \SystemRoot\system32\drivers\vbemp.sys: 9cea9000 DriverBase for \SystemRoot\system32\drivers\videoprt.sys: 9cec8000 DriverBase for \SystemRoot\system32\drivers\msfs.sys: 9cede000 DriverBase for \SystemRoot\system32\drivers\npfs.sys: 9cef4000 (mm/virtual.c:235) FIXME: MEMORY_AREA_KERNEL_STACK case incomplete (or possibly wrong) for NtQueryVirtualMemory() DriverBase for \SystemRoot\system32\win32k.sys: 9d1ca000 DriverBase for \SystemRoot\system32\freetype.dll: 9d2c4000 DriverBase for \SystemRoot\System32\kbdus.dll: 9d349000 DriverBase for \SystemRoot\System32\framebuf.DLL: 9d7cb000 0 bytes requested - initiating pool verification 0 bytes requested - initiating pool verification FIXME: CopyImage doesn't support IMAGE_ICON correctly! 0 bytes requested - initiating pool verification 0 bytes requested - initiating pool verification (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find mxdMessage (NTDLL:ldr/utils.c:2034) Failed to create or open dll section of 'msacm32.dll' (Status c0000135) (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find auxMessage (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find mxdMessage (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find midMessage (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find widMessage (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find wodMessage (shelllink.c:648:Stream_WriteLocationInfo) writing empty location info (SAMLIB:samlib.c:400) User already exists! (devinst.c:950:SetupDiInstallClassW) (devinst.c:950:SetupDiInstallClassW) (ntuser/timer.c:157) Unable to locate timer in message queue (ntuser/timer.c:157) Unable to locate timer in message queue (ntuser/timer.c:157) Unable to locate timer in message queue (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find mxdMessage (NTDLL:ldr/utils.c:2034) Failed to create or open dll section of 'msacm32.dll' (Status c0000135) (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find auxMessage (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find mxdMessage (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find midMessage (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find widMessage (NTDLL:ldr/utils.c:1211) LdrGetExportByName(): failed to find wodMessage mm/mm.c:214 mm/mm.c:337 (KERNEL32:except/except.c:159) Unhandled exception (KERNEL32:except/except.c:160) Address: (KERNEL32:except/except.c:163) 7c913a83 C:\ReactOS\system32\ntdll.dll CS:EIP 1b:7c913a83 DS 23 ES 23 FS 3b GS 23 EAX: 00660000 EBX: 80000000 ECX: 0065e758 EDX: 00000000 EBP: 0065e788 ESI: 00000000 ESP: 0065e760 EDI: 00660000 EFLAGS: 00000246 (KERNEL32:except/except.c:166) Frames: (KERNEL32:except/except.c:174) 7c913be4 C:\ReactOS\system32\ntdll.dll (KERNEL32:except/except.c:174) 7c913ce4 C:\ReactOS\system32\ntdll.dll (KERNEL32:except/except.c:174) 7c9143f9 C:\ReactOS\system32\ntdll.dll (KERNEL32:except/except.c:174) 77dca5a1 C:\ReactOS\system32\ADVAPI32.DLL (KERNEL32:except/except.c:174) 40177b C:\ReactOS\System32\vmwinst.exe (KERNEL32:except/except.c:174) 4024c9 C:\ReactOS\System32\vmwinst.exe (KERNEL32:except/except.c:174) 77e71672 C:\ReactOS\System32\user32.dll (KERNEL32:except/except.c:174) 77e71814 C:\ReactOS\System32\user32.dll (KERNEL32:except/except.c:174) 77e7bee3 C:\ReactOS\System32\user32.dll (KERNEL32:except/except.c:174) 77e71672 C:\ReactOS\System32\user32.dll (KERNEL32:except/except.c:174) 77e721dc C:\ReactOS\System32\user32.dll (KERNEL32:except/except.c:174) 77e7a3b8 C:\ReactOS\System32\user32.dll (KERNEL32:except/except.c:174) 77e7bb91 C:\ReactOS\System32\user32.dll (KERNEL32:except/except.c:174) 7618ecaf C:\ReactOS\System32\COMCTL32.DLL (KERNEL32:except/except.c:174) 7618f952 C:\ReactOS\System32\COMCTL32.DLL (KERNEL32:except/except.c:174) 7618f15f C:\ReactOS\System32\COMCTL32.DLL (KERNEL32:except/except.c:174) 7619110d C:\ReactOS\System32\COMCTL32.DLL (KERNEL32:except/except.c:174) 76191b4d C:\ReactOS\System32\COMCTL32.DLL (KERNEL32:except/except.c:174) 77e71672 C:\ReactOS\System32\user32.dll (KERNEL32:except/except.c:174) 77e71814 C:\ReactOS\System32\user32.dll (KERNEL32:except/except.c:174) 77e7bee3 C:\ReactOS\System32\user32.dll (KERNEL32:except/except.c:174) 77e71672 C:\ReactOS\System32\user32.dll (KERNEL32:except/except.c:174) 77e721dc C:\ReactOS\System32\user32.dll (KERNEL32:except/except.c:174) 77ea94a4 C:\ReactOS\System32\user32.dll (KERNEL32:except/except.c:174) 77ea9ac5 C:\ReactOS\System32\user32.dll (KERNEL32:except/except.c:174) 77e71672 C:\ReactOS\System32\user32.dll (KERNEL32:except/except.c:174) 77e71989 C:\ReactOS\System32\user32.dll (KERNEL32:except/except.c:174) 77e7cc46 C:\ReactOS\System32\user32.dll (KERNEL32:except/except.c:174) 77e79e5d C:\ReactOS\System32\user32.dll (KERNEL32:except/except.c:174) 77e7c124 C:\ReactOS\System32\user32.dll (KERNEL32:except/except.c:174) 7618db1c C:\ReactOS\System32\COMCTL32.DLL (KERNEL32:except/except.c:174) 76190b00 C:\ReactOS\System32\COMCTL32.DLL (KERNEL32:except/except.c:174) 402dd6 C:\ReactOS\System32\vmwinst.exe (KERNEL32:except/except.c:174) 402ede C:\ReactOS\System32\vmwinst.exe (KERNEL32:except/except.c:174) 4031bb C:\ReactOS\System32\vmwinst.exe (KERNEL32:except/except.c:174) 40122d C:\ReactOS\System32\vmwinst.exe (KERNEL32:except/except.c:174) 401278 C:\ReactOS\System32\vmwinst.exe (KERNEL32:except/except.c:174) 7c824b19 C:\ReactOS\system32\kernel32.dll (ntuser/class.c:114) Failed to lookup class atom! (ntuser/class.c:114) Failed to lookup class atom! (ntuser/class.c:114) Failed to lookup class atom! (ntuser/class.c:114) Failed to lookup class atom! (ntuser/class.c:114) Failed to lookup class atom! KeBugCheck at mm/rmap.c:492 Bug detected (code 0 param 0 0 0 0) Page fault at high IRQL was 2 KeBugCheckWithTf at ke/catch.c:177 Bug detected (code 1e param 0 0 0 0) Page fault at high IRQL was 2 KeBugCheckWithTf at ke/catch.c:177 Bug detected (code 1e param 0 0 0 0) Page fault at high IRQL was 2 KeBugCheckWithTf at ke/catch.c:177 Bug detected (code 1e param 0 0 0 0) Page fault at high IRQL was 2 KeBugCheckWithTf at ke/catch.c:177 Bug detected (code 1e param 0 0 0 0) Page fault at high IRQL was 2 Stack underflow (tf->esp 9cc02fe0 Limit 9cc03000) Stack Segment Fault Exception: 12(0) CS:EIP 8:8000a233 <ntoskrnl.exe: a233> cr2 9cc02fe4 cr3 2b5000 Proc: 80788940 Pid: c0 <vmwinst.> Thrd: 80408078 Tid: c DS 10 ES 10 FS 30 GS 10 EAX: 0001000f EBX: 9cc03650 ECX: 9cc036ec EDX: 00000000 EBP: 9cc03628 ESI: 9cc03340 ESP: 9cc02fe0EDI: 00000000 EFLAGS: 00010097 kESP 9cc02fe0 kernel stack base 9cc03000 Frames: <ntoskrnl.exe: 1273> <ntoskrnl.exe: 190a> <ntoskrnl.exe: 2f02> <ntoskrnl.exe: 78910> <ntoskrnl.exe: 789bf> <ntoskrnl.exe: 440b2> <ntoskrnl.exe: 68427> <ntoskrnl.exe: 9df6> <ntoskrnl.exe: a029> <ntoskrnl.exe: 1273> <ntoskrnl.exe: 190a> <ntoskrnl.exe: 2f02> <ntoskrnl.exe: 78910> <ntoskrnl.exe: 789bf> <ntoskrnl.exe: 440b2> <ntoskrnl.exe: 68427> <ntoskrnl.exe: 9df6> <ntoskrnl.exe: a029> <ntoskrnl.exe: 1273> <ntoskrnl.exe: 190a> <ntoskrnl.exe: 2f02> <ntoskrnl.exe: 78910> <ntoskrnl.exe: 789bf> <ntoskrnl.exe: 440b2> <ntoskrnl.exe: 68427> <ntoskrnl.exe: 9df6> <ntoskrnl.exe: a029> <ntoskrnl.exe: 1273> <ntoskrnl.exe: 190a> <ntoskrnl.exe: 2f02> <ntoskrnl.exe: 78910> <ntoskrnl.exe: 789bf> <ntoskrnl.exe: 440b2> <ntoskrnl.exe: 68427> <ntoskrnl.exe: 9df6> <ntoskrnl.exe: a029> <ntoskrnl.exe: 1273> <ntoskrnl.exe: 190a> <ntoskrnl.exe: 2f02> <ntoskrnl.exe: 78910> <ntoskrnl.exe: 789bf> <ntoskrnl.exe: 440b2> <ntoskrnl.exe: 68427> <ntoskrnl.exe: 9df6> <ntoskrnl.exe: 9f37> <ntoskrnl.exe: 9f71> <ntoskrnl.exe: 5448c> <ntoskrnl.exe: 4596b> <ntoskrnl.exe: 4b33d> <ntoskrnl.exe: 45b33> <ntoskrnl.exe: 4c81e> <ntoskrnl.exe: 4c8b3> <ntoskrnl.exe: 624b1> <ntoskrnl.exe: 6261c> <ntoskrnl.exe: 5daef> <ntoskrnl.exe: 5dea7> <ntoskrnl.exe: 5f782> <ntoskrnl.exe: 5daef> <ntoskrnl.exe: 5dea7> <ntoskrnl.exe: 610b2> <ntoskrnl.exe: 65a96> <ntoskrnl.exe: 3060>

3 3

ACPI status
by Gge 28 Jan '05

28 Jan '05

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

2 1

Re: [ros-svn] [royce] 13345: allow oring multiple DebugPort values
by Gge 28 Jan '05

28 Jan '05

royce(a)svn.reactos.com wrote: > allow oring multiple DebugPort values > > > Updated files: > trunk/reactos/boot/freeldr/freeldr/debug.c > Hello Royce, A nice option would be to have the debug messages displayed in a "Debug" window . This will allows to redirect the debug messages to a file . How difficult is to implement this enhancement ? Regards Gerard

2 1

reactos.com this weekend
by Ge van Geldorp 27 Jan '05

27 Jan '05

Some urgent maintenance needs to be carried out on the electrical installation in the building that houses the reactos.com box. To perform this maintenance, power will be shutdown Friday night till Sunday morning. I will be moving reactos.com web- and mailservices to a fallback box. This should take place some time Friday. Switch back will be Sunday. The bandwidth capacity of the fallback box is much lower than that of the main box, so please don't plan on submitting stories to SlashDot this weekend... Gé van Geldorp.

3 3

msvcrt/crtdll "merge"
by Gunnar Dalsnes 27 Jan '05

27 Jan '05

Hi, I'm currently "merging" msvcrt and crtdll (again). I'll move msvcrt into a library lib\crt and have msvcrt and crtdll link against it. Only dllmain.c will be left in msvcrt/crtdll. Most of (99.9%) crtdll will be dropped. It all seems to work nicely. One problem thou: I ran into some header problems, where i relied on some stuff in include\msvcrt\string.h but no matter what, mingw\include\string.h were included instead (and they both defined _STRING_H_). After looking at the headers in inlcude\msvcrt they all seem to be ripped from mingw. Does anyone know why they were put in include\msvcrt when mingw has headers for all of this stuff? Can i just remove them (include\msvcrt)? I looked at many depends files and saw most files depend on many mingw headers. Is this correct? Should we depend on mingw headers at all? Gunnar

1 0

videoprt.nostrip.sys
by Ge van Geldorp 27 Jan '05

27 Jan '05

It seems videoprt.nostrip.sys is somewhat messed up. I've attached the output of "objdump -p videoprt.nostrip.sys". Data Directory Entry 1 says there's an import directory at 0x0000b000. Then down under "PE File Base Relocations (interpreted .reloc section contents)" we find: Virtual Address: 0000b000 Chunk size 12 (0xc) Number of fixups 2 reloc 0 offset 14 [b014] HIGHLOW reloc 1 offset 20 [b020] HIGHLOW When the module is loaded, the relocations are applied. This messes up the import table, with the result that the module fails to load (copy videoprt.nostrip.sys to \reactos\system32\drivers\videoprt.sys and boot ReactOS). The 2 relocations given above are not present in the "normal" videoprt.sys module. I'm inclined to blame gcc (I'm using 3.4.1) or more likely binutils (2.15.90 20040222) for this, but before I make Filip unhappy, does anyone know if we're doing something wrong during the build process? Gé van Geldorp.

2 1

Re: [ros-svn] [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 Alex Ionescu 26 Jan '05

26 Jan '05

ion(a)svn.reactos.com wrote: >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) > > >Updated files: >trunk/reactos/config >trunk/reactos/ntoskrnl/include/internal/i386/mm.h >trunk/reactos/ntoskrnl/ke/main.c >trunk/reactos/ntoskrnl/mm/mminit.c > >_______________________________________________ > > Royce and I are currently working on making this fully dynamic. We've got the plan set-up in our minds and it should be committed in less then a week, unless unexpected things happen. Speaking of which, is anyone against not making ACPI a compile-time instruction? It just makes debugging harder, one more thing to worry about, and I don't see the point either...I think it makes much more sense to have some kind of ACPISupported global variable that we either set at boot-up with proper table queries, and/or that the user can specify with an /ACPI command-line flag. Best regards, Alex Ionescu

2 1

new binutils snapshot
by Jonathan Wilson 26 Jan '05

26 Jan '05

http://sourceforge.net/project/showfiles.php?group_id=2435 Does this make those issues (dlltool I think) with using the previous snapshot go away?

1 0

Slab cache
by Hartmut Birr 25 Jan '05

25 Jan '05

Hi, do we need the slab cache in ntoskrnl\mm\slab.c? I've replaced the kmap functions (ntoskrnl\mm\kmap.c) by a process local mapping (hyperspace). The slab cache needs the mapping for a longer time and cannot use the hyperspace mapping. I would remove the slab cache, because it is not used by any of the kernel functions. - Hartmut

4 3

user mode exceptions
by Hartmut Birr 25 Jan '05

25 Jan '05

Hi, on a user mode exception, I get hundreds of lines like this: (i386/exception.c:96) RtlpDispatchException() Dumping exception registrations: (0x0065FFE0) HANDLER (0x7C82CEAF) (0x7FFDF000) HANDLER (0x00000000) (i386/exception.c:96) RtlpDispatchException() Dumping exception registrations: (0x0065FFE0) HANDLER (0x7C82CEAF) (0x7FFDF000) HANDLER (0x00000000) (i386/exception.c:96) RtlpDispatchException() Dumping exception registrations: It needs a very large time, if ros does response again. It occurs on real hardware. Debugprints are going over a serial line. - Hartmut

1 0

Re: [ros-diffs] [hbirr] 13277: - Fixed the directory index of a file for FATX.
by Hartmut Birr 25 Jan '05

25 Jan '05

Hervé Poussineau schrieb: > hbirr(a)svn.reactos.com a écrit : > >> - Fixed the directory index of a file for FATX. >> + ULONG startIndex = rcFcb->startIndex; >> + if ((rcFcb->Flags & FCB_IS_FATX_ENTRY) && !vfatFCBIsRoot(Parent)) >> >> { >> >> + startIndex += 2; >> + } >> + if(startIndex >= DirContext->DirIndex) >> + { > > > This change looks suspicious to me. > "." and ".." don't exist on a FATX volume. They are FAT12/16/32 specific. > Please revert related changes in create.c, dirw.c, direntry.c, fcb.c > > Hervé > > PS: > Comment in direntry.c ("need to add . and .. entries".) is not very > clear. It may be modified to "Need to add . and .. entries, because > they don't exist in a FATX subdir" > _______________________________________________ > Ros-diffs mailing list > Ros-diffs(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-diffs > > FATX doesn't have real '.' and '..' directories. But we use them on each directory except the root. The index from fcb is also used to update the entry of a file in its parent directory. For looking for a directory, '.' has index 0, '..' has index 1 and 'foo' has index 2 and so on. The real index of 'foo' is 0. We must make a difference between the real and the search index. I've modified some parts of freeldr and usetup. I can create and install ros on a fatx partition on a normal pc. I've also load vfatfs on W2K. At the beginning, the wrong index has scrambled the fatx partition. - Hartmut

2 1

We have a web browser] : Input ?
by Gge 25 Jan '05

25 Jan '05

With the Mozilla ActiveX Control , I can browse "www.reactos.com" from the Reactos Explorer as indicated before. The link to www.reactos.com is made by explorer at start but I do not know how to type an URL (www.google.com for example) in the Explorer window ? Any idea ? Regards Gerard

5 10

WineConf 2005
by Steven Edwards 25 Jan '05

25 Jan '05

Hello, If you are a ReactOS developer thats planning on coming to WineConf 2005 please fill out the RSVP form at http://www.winehq.org/site/wineconf We need to get a estimated head count so even if your not 100% sure that you will make it you can RSVP and note that on the webstie. So far GvG and myself are planning on attending and Thomas,KJK and fireball have said they will try to attend as well. Thanks Steven __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com

1 0

Re: [ros-dev] Re: We have a web browser : Input ?
by barry day 25 Jan '05

25 Jan '05

On Mon, Jan 24, 2005 at 05:58:27PM -0600, Royce Mitchell III wrote: > > > > If we even tried, the only thing we would do is alienate potential users > of our OS, because their favorite killer app doesn't work on it. > Clone Microsoft's mistakes and you won't have potential users, there will be no reason to swap to Reactos.

4 4

Re: [ros-diffs] [hbirr] 13257: - Interpret STATUS_TIMEOUT as error in PsLockProcess.
by Filip Navara 25 Jan '05

25 Jan '05

hbirr(a)svn.reactos.com wrote: >- if(!NT_SUCCESS(Status)) > > >+ if(!NT_SUCCESS(Status) || STATUS_TIMEOUT) > > Shouldn't this be "|| Status == STATUS_TIMEOUT" ?

3 2

Re: [ros-dev] Re: We have a web browser : Input ?
by barry day 25 Jan '05

25 Jan '05

On Mon, Jan 24, 2005 at 08:49:17PM -0500, Richard Campbell wrote: > If internet explorer were a 'mistake' it wouldn't have a 92% user base. > If it isn't working, people wouldn't use it. It took quite a long time > for a worthy competitor (firefox) to appear. Anyways, cloning internet > explorer is outside the scope of this project. It may BE a part of > windows, but we can install it (IE5 at least) seperately (eventually). > What the user base is depends on who you ask. Nobody appears to have irrefutable up-to-date figures. And do you describe a program that CERT advises people not to use as "works"? But lets not argue over this. My reason for posting my commments is simply because I think some of us are only aiming at implementing a clone whereas I feel we should be striving to create a compatible OS that is even better, and I get the impression from the faq on the wiki site that was one of the reasons for this project's existence. But on the other hand that risks becoming bogged down in discussion about how things should be done. If at the end of the day we end up with nothing more than an open source clone of Windows that I can hack on I will still be happy.

1 0

Re: [ros-dev] Re: We have a web browser : Input ?
by barry day 25 Jan '05

25 Jan '05

On Mon, Jan 24, 2005 at 04:54:58PM -0600, Royce Mitchell III wrote: > Steven Edwards wrote: > > We may have to install it as both iexplore.exe as well as ibrowser.exe, > because certain ill-behaved apps may look for iexplore.exe, and we want > it to find the user's browser, regardless of whether they've installed > MS's IE or are using ours. > But if the user's choice of browser is firefox or something else then that's not going to work is it.

1 0

Re: [ros-dev] Re: We have a web browser : Input ?
by barry day 24 Jan '05

24 Jan '05

On Mon, Jan 24, 2005 at 04:54:58PM -0600, Royce Mitchell III wrote: > We may have to install it as both iexplore.exe as well as ibrowser.exe, > because certain ill-behaved apps may look for iexplore.exe, and we want > it to find the user's browser, regardless of whether they've installed > MS's IE or are using ours. > That should be left to the developer of the buggy app to fix. One of the reasons Windows has problems with malware is because of developers going about things the wrong way. They need to be taught to do things correctly, not accommodated for.

2 1

Re: [ros-svn] [gvg] 13252: IoCreateFile should be passed kernelmode parameters.
by Hartmut Birr 24 Jan '05

24 Jan '05

gvg(a)svn.reactos.com schrieb: >IoCreateFile should be passed kernelmode parameters. > > > >Updated files: >trunk/reactos/ntoskrnl/include/internal/safe.h >trunk/reactos/ntoskrnl/io/create.c >trunk/reactos/ntoskrnl/io/mailslot.c >trunk/reactos/ntoskrnl/io/npipe.c >trunk/reactos/ntoskrnl/rtl/capture.c > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > > > Hi, it seems that the memory for the captured parameters is never freed. - Hartmut

1 0

memory leakage
by Hartmut Birr 24 Jan '05

24 Jan '05

Hi, since some days ros eats up paged pool memory. I'm using cmd as login shell. 'Make clean' on the ros source tree increase the number of paged pool pages from 500 to more than 8000. In the past the number of paged pool pages has never changed. - Hartmut

1 0

Re: [ros-svn] [ion] 13130: Bug fixes against uninitizlied variables and support for tree-wide optimization (do not try yet, crashes in bootvid).
by Alex Ionescu 24 Jan '05

24 Jan '05

ion(a)svn.reactos.com wrote: >Bug fixes against uninitizlied variables and support for tree-wide optimization (do not try yet, crashes in bootvid). > > >Updated files: >trunk/reactos/config >trunk/reactos/drivers/lib/ip/transport/datagram/datagram.c >trunk/reactos/drivers/net/afd/afd/connect.c >trunk/reactos/drivers/net/afd/afd/write.c >trunk/reactos/drivers/net/tcpip/tcpip/info.c >trunk/reactos/hal/halx86/generic/dma.c >trunk/reactos/lib/epsapi/enum/drivers.c >trunk/reactos/lib/msafd/misc/dllmain.c >trunk/reactos/lib/shellext/slayer/slayer.c >trunk/reactos/lib/ws2_32/misc/ns.c >trunk/reactos/ntoskrnl/Makefile >trunk/reactos/regtests/shared/regtests.h >trunk/reactos/subsys/csrss/win32csr/guiconsole.c >trunk/reactos/subsys/win32k/makefile >trunk/reactos/tools/helper.mk > > If some of you would like to turn OPTIMIZED = 1 and help me with some of the current problems, I'd appreciate it greatly: 1) Bootvid crashes during boot logo intialization. Booting with NOGUIBOOT gets ros to the installation page, where 2) Default selections for radio buttons and combobox do not appear, they must now be selected manually Apart from this glitch, driver installation and second boot were perfect, minus the following: 3) Debug message about unhandled exception, followed by an explorer crash related to a header file. 4) Browsing some registry keys in regedit causes regedit to crash. I haven't noted any other problems for now, but I haven't done any deep testing. On the up side, this brings my little syscall benchmark to 170ms, an additional 15% improvement. In total, this is an 80% improvement over int2e builds. Furthermore, all of ReactOS is extremly fast. Directory listing in cmd.exe is instant, explorer navigation as well. Menus re-draw instantly and the whole experience is smooth. It really feels like Windows, you have to try it to believe it. There's been some talk on activating OPTIMIZED = 1 if (K)DBG != 1 and all the developers on IRC were in agreement. But before such a change is made, the bugs above need to be fixed, as well as any other possible things which might crop up. Best regards, Alex Ionescu

2 3

RE: [ion] 12806: Use proper PISID pointer to SID structure, fix wrong LUID definition, and remove duplicate code in Security Manager
by Ge van Geldorp 24 Jan '05

24 Jan '05

> From: ion(a)svn.reactos.com > > Use proper PISID pointer to SID structure, fix wrong LUID > definition, and remove duplicate code in Security Manager > > Updated files: > trunk/reactos/include/ntos/security.h Are you sure that the constants for e.g. SYSTEM_LUID need to be enclosed in double braces for MinGW? I'd expect SYSTEM_LUID to be of type LUID. That would make the code in ntoskrnl\se\luid.c where SYSTEM_LUID is assigned to a LARGE_INTEGER instead of a LUID incorrect. Gé van Geldorp.

1 0

Re: [ros-svn] [weiden] 13138: implemented the ProcessSessionInformation information class
by Hartmut Birr 24 Jan '05

24 Jan '05

weiden(a)svn.reactos.com schrieb: >implemented the ProcessSessionInformation information class > > >Updated files: >trunk/reactos/ntoskrnl/ps/process.c > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > > > Hi, I think that some parts of your implementation are incorrect. The function must check for the location of the buffer and the previous mode. If the previous mode is user mode, the buffer must be located within the user address space. IMHO using of MmCopyFrom/ToCaller is better than using an exception block. It is also true for your following commits. - Hartmut

10 16

Re: [ros-svn] [weiden] 13226: the system process should be called "System", not "SYSTEM"
by Emanuele Aliberti 23 Jan '05

23 Jan '05

weiden(a)svn.reactos.com wrote: >the system process should be called "System", not "SYSTEM" > > SYSTEM = NT 3.x, 4.0 System = NT 5.x

2 2

Install problem
by Hartmut Birr 23 Jan '05

23 Jan '05

Hi, I've a reactos install problem. If I select german as default language, ros fails in second stage setup. I get a message box 'InitializeProfiles() failed'. I see that the folder 'Documents and settings' changes to the german translation 'Dokumente und Einstellungen'. - Hartmut

1 0

Build number: a proposal
by Emanuele Aliberti 23 Jan '05

23 Jan '05

Just a late night idea. What about using the current revision number of the local SVN repository as the build number? Major, minor and revision number of ROS will be a matter of politics, but the build number will give an exact coordinate in the space of the source code evolution. Is there a way to get it in a portable way? Emanuele

8 8

Enable the "polytest" test
by Sylvain Petreolle 23 Jan '05

23 Jan '05

Changelog: Add makefile for "polytest" test & enable it. Fix compile warnings for diskspeed & zwcontinue tests ===== Usurp (aka Sylvain Petreolle) humans are like computers, yesterday the BIOS was all - today its just a word

1 0

ntdll: building fails
by Emanuele Aliberti 23 Jan '05

23 Jan '05

After svn up and make clean, I get this error ntdll: [CC] string/strstr.c ntdll: [CC] string/strupr.c ntdll: [CC] string/wstring.c ntdll: [AR] ntdll.a ntdll: [LD] ntdll.nostrip.dll temp.exp(.edata+0x290):fake: undefined reference to `NtPlugPlayControl@12' temp.exp(.edata+0xafc):fake: undefined reference to `ZwPlugPlayControl@12' collect2: ld returned 1 exit status make: *** [ntdll.nostrip.dll] Error 1 --- GNU ld version 2.15.90 20040222 GNU Make 3.80 gcc (GCC) 3.4.2 (mingw-special)

3 3

Ping fixup
by WaxDragon 22 Jan '05

22 Jan '05

This small patch fixes a bug in getting the ip address form DNS, and changes the time formatting to avoid internationalization issues ( . vs , for thousands separator). Andrew Munger -- The cheese stands alone.

1 2

[Fwd: Re: [ros-dev] We have a web browser] = OK
by Gge 22 Jan '05

22 Jan '05

The minimum version of msvcr70.dll is 7.0.9466.0 . It works now with this dll version Regards Gerard

1 0

We have a web browser
by Steven Edwards 22 Jan '05

22 Jan '05

1. Add urlmon and shdocvw to the build 2. wget the mozilla control from there "Url"="http://crossover.codeweavers.com/redirect/mozcontrol" 3. Install the control (It may fail a few times) 4. Copy msvcr70.dll to reactos\system32 5. start cmd.exe and cd to C:\program files\Mozilla ActiveX Control ..... 6. type explorer 7. hit the webbutton __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250

4 6

Re: [ros-svn] [ion] 13206: Fix remaning ROS bugs. A minor hack has been added to ObCreateObject because it seems that gcc doesn't dword-align the stacks?!! Thanks to w3seek for some of the ex patches.
by Alex Ionescu 22 Jan '05

22 Jan '05

ion(a)svn.reactos.com wrote: >Fix remaning ROS bugs. A minor hack has been added to ObCreateObject because it seems that gcc doesn't dword-align the stacks?!! Thanks to w3seek for some of the ex patches. > > > After what has now become 6 hours of work, I'm done fixing this stuff. ROS should be usable, but I haven't ran full regression tests...probably a lot of stuff is still broken. Best regards, Alex Ionescu

1 0

Re: [ros-diffs] [ion] 13202: Fix all remaning alignment errors. Ros is now moderately usable. Error in explorer remains making disk browsing impossible, but with other tools it still works
by Joseph Galbraith 22 Jan '05

22 Jan '05

> --- trunk/reactos/ntoskrnl/ps/process.c 2005-01-22 01:00:12 UTC (rev 13201) > +++ trunk/reactos/ntoskrnl/ps/process.c 2005-01-22 01:30:05 UTC (rev 13202) > @@ -1705,6 +1704,7 @@ > > &Status); > if(!NT_SUCCESS(Status)) > { > > + DPRINT1("NtSetInformationProcess() %d %x %x called\n", ProcessInformationClass, ProcessInformation, ProcessInformationLength); > > DPRINT1("NtSetInformationProcess() %x failed, Status: 0x%x\n", Status); I know this wasn't part of your change, but that last DPRINT1() doesn't look right... (unless I'm missing something.) Doesn't it need another parameter? Thanks, Joseph

1 0

SVN Trunk Dead
by Alex Ionescu 22 Jan '05

22 Jan '05

Hi, Booting ROS doesn't work lately...... I've debugged the problem and found two likely causes: 1) RtlFormatCurrentUserKeyPath calls NtQueryInformationToken with a Kernel Mode address while in user-mode 2) Something is wrong with setting the current mode (in syscall.S), and so MmCopySafe... thinks that teh current mode is user while the buffer is kernel: (mm/mm.c:60) 1, de1c7cf8 Note that 1 == UserMode while the buffer is kernel-mode. It's late here so I don't have time to look into it with more detail. Best regards, Alex Ionescu

3 6

ReactOS is dead...
by Richard Campbell 21 Jan '05

21 Jan '05

The current tree doesn't work. See attached screenshot.

2 1

RE: [ros-diffs] [weiden] 13188: fixed ASSERT statement, thanks to blight for pointing it out
by Casper Hornstrup 21 Jan '05

21 Jan '05

If we #define ASSERT(x) if (0) { x } for DBG := 0, won't all these compile errors go away? We have a lot of them. The compiler will perform syntax check, but optimize the statements away. Casper ________________________________ From: ros-diffs-bounces(a)reactos.com [mailto:ros-diffs-bounces@reactos.com] On Behalf Of weiden(a)svn.reactos.com Sent: 21. januar 2005 18:17 To: ros-diffs(a)reactos.com Subject: [ros-diffs] [weiden] 13188: fixed ASSERT statement,thanks to blight for pointing it out fixed ASSERT statement, thanks to blight for pointing it out Modified: trunk/reactos/ntoskrnl/ob/object.c ________________________________ Modified: trunk/reactos/ntoskrnl/ob/object.c --- trunk/reactos/ntoskrnl/ob/object.c 2005-01-21 16:50:11 UTC (rev 13187) +++ trunk/reactos/ntoskrnl/ob/object.c 2005-01-21 17:17:13 UTC (rev 13188) @@ -51,7 +51,7 @@ NTSTATUS Status = STATUS_SUCCESS; /* at least one output parameter must be != NULL! */ - ASSERT((ULONG_PTR)SecureObjectInformation ^ (ULONG_PTR)ObjectName != 0); + ASSERT((ULONG_PTR)CapturedObjectAttributes ^ (ULONG_PTR)ObjectName != 0); if(ObjectAttributes == NULL) {

1 0

WIN32K: LPC use
by Emanuele Aliberti 21 Jan '05

21 Jan '05

This is just a note for the WIN32K developers. I ran the dumppe utility to compare imported symbols in WIN32K.SYS on a real system and on ROS'. Here are the results. ReactOS WIN32K.SYS exported symbols containg substing "Port": ZwConnectPort ZwRequestWaitReplyPort XPSP2 WIN32K.SYS exported symbols containg substing "Port": LpcRequestWaitReplyPort PsGetProcessDebugPort LpcRequestPort This suggests port handles are not used in regular LPC processing within WIN32K and that there is not a twin connection to \Windows\ApiPort (ntuser/csr.c). Emanuele (just guessing)

3 7

ext2 status (a bit long)
by art yerkes 20 Jan '05

20 Jan '05

I've been doing some looking at why winext2fsd doesn't work on reactos. This has been a pet project of mine for a while, but sadly I'm not very skilled in the parts of reactos that it touches. On the ext2 branch, I've got filips changes and some small changes of my own so that I can make a bootcd that will try to install reactos on a fresh ext2 partition. ext2 starts writing the first file to the empty filesystem but stalls when a call to WriteCacheSegment causes ext2 to do a paging write of several pages to class2, which uses ScsiClassSplitRequests to send several blocks to scsiport for writing. The interesting thing is, in the case where my diff prints DEADLY WAIT, SpiProcessRequests receives the IRPs but does not enter the while loop that would process them, nor receive any further completions. At this point i'm totally stuck and so I'll try to isolate the relevant debug output. If somebody is interested and has some spare time I'd appreciate a bit of wisdom about how the DeviceExtension->Flags, NextIrp, ActiveIrpCount and PendingIrpCount fit together. I think that if the IRPs are completed then the rest will work, since the split IRP code in class2 seems reasonable. http://64.81.145.152/~arty/ext2.diff <-- Lots of annotation http://64.81.145.152/~arty/ext2.log <-- Last part of execution http://64.81.145.152/~arty/rosbin.zip <-- Binaries from my tree In the log it is writing atapi.sys to \ReactOS\system32\drivers on the disk. DEADLY WAIT(0) is the place where ext2 can't progress from. It's at line 200 or so in drivers/fs/ext2/src/io.c. The fatal invocation of SpiProcessRequest looks like this before the while loop: (scsiport.c:2864) DeviceExtension->Flags & IRP_FLAG_COMPLETE 0 (scsiport.c:2866) DeviceExtension->SrbExtensionSize 0 (scsiport.c:2869) DeviceExtension->CurrentSrbExtensions 0 Max 0 (scsiport.c:2871) DeviceExtension->PendingIrpCount 4 (scsiport.c:2873) DeviceExtension->Flags & (N|NLU) 0 (scsiport.c:2875) DeviceExtension->NextIrp c0457db0 The wierd thing is that it seems that atapi relies on the ide controller raising an interrupt after IDEWriteBlock, which never happens for me under qemu after this point. This is where I get totally lost unfortunately. I'll try to learn more as I go but any help understanding scsiport is appreciated. Art -- 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

2 1

RE: [Spam] [ros-diffs] [royce] 13154: require attributes to have values
by Casper Hornstrup 20 Jan '05

20 Jan '05

The magic number 1 may be obvious to some, but it isn't to all. It should be true/false, yes/no or all of the above. Casper ________________________________ From: ros-diffs-bounces(a)reactos.com [mailto:ros-diffs-bounces@reactos.com] On Behalf Of royce(a)svn.reactos.com Sent: 20. januar 2005 07:37 To: ros-diffs(a)reactos.com Subject: [Spam] [ros-diffs] [royce] 13154: require attributes to have values require attributes to have values Modified: branches/xmlbuildsystem/reactos/ntoskrnl/ntoskrnl.xml Modified: branches/xmlbuildsystem/reactos/tools/rbuild/XML.cpp Modified: branches/xmlbuildsystem/reactos/tools/rbuild/module.cpp ________________________________ Modified: branches/xmlbuildsystem/reactos/ntoskrnl/ntoskrnl.xml --- branches/xmlbuildsystem/reactos/ntoskrnl/ntoskrnl.xml 2005-01-20 06:29:08 UTC (rev 13153) +++ branches/xmlbuildsystem/reactos/ntoskrnl/ntoskrnl.xml 2005-01-20 06:36:37 UTC (rev 13154) @@ -29,7 +29,7 @@ <directory name="ke"> <if property="ARCH" value="i386"> <directory name="i386"> - <file first>multiboot.S</file> + <file first="1">multiboot.S</file> <file>bios.c</file> <file>brkpoint.c</file> <file>bthread.S</file>

2 1

Hey guys...
by Richard Campbell 20 Jan '05

20 Jan '05

I'm re setting up my ROS dev environment, after a format/reinstall, and i'm encountering the following problem under both QEMU and ReactOS: While booting from the livecd or the bootcd i get an inaccessible boot device error. The HD partition on VMWare is a FAT32 partition formatted in win98, the partition in QEMU is an unformatted partition. Any idea on how to fix this?

5 16

binutils-2.15.90
by Ge van Geldorp 20 Jan '05

20 Jan '05

Since binutils-2.15.90 (which you need to build a bootable ReactOS) is no longer available from the MinGW download pages, I put it on the ReactOS download page on SourceForge: http://sourceforge.net/project/showfiles.php?group_id=6553 Gé van Geldorp.

1 0

Zw/Nt functions
by Hartmut Birr 20 Jan '05

20 Jan '05

Hi, currently our Zw functions for kernel mode are implemented by an parameter wrapper and an int 0x2e instruction. The only reason for using the Zw functions in kernel mode is to bypass the buffer check. Can we implement the Zw functions by saving/changing/restoring the previous mode and calling the equal Nt function? - Hartmut

2 1

comdlg32 wierdness..
by Richard Campbell 19 Jan '05

19 Jan '05

Currently the resource files in comdlg contain a listbox entry similar to below: LISTBOX IDC_SHELLSTATIC,4,20,272,85, LBS_SORT | LBS_NOINTEGRALHEIGHT | LBS_MULTICOLUMN | WS_HSCROLL | NOT WS_VISIBLE shouldn't it be LISTBOX IDC_SHELLSTATIC,4,20,272,85, LBS_SORT | LBS_NOINTEGRALHEIGHT | LBS_MULTICOLUMN | WS_HSCROLL the NOT WS_VISIBLE causes windres errors (windres doesn't recognize NOT, and even if it did, saying NOT WS_VISIBLE instead of just not | WS_VISIBLE is redundant.), which causes the DLL to fail to build. While this appears to be merely a goofup, figured i'd ask about it in the list before i make any changes to the tree in case this is there for a reason. Richard

1 0

Re: [ros-diffs] [royce] 13129: added 'first' attribute to <file>
by d_layer 19 Jan '05

19 Jan '05

royce(a)svn.reactos.com wrote: > added 'first' attribute to <file> > Modified: branches/xmlbuildsystem/reactos/ntoskrnl/ntoskrnl.xml ... > + <file first>multiboot.S</file> According to the XML spec, all attributes must have a value. [1] So, the above line must be written like this: <file first="true">multiboot.S</file> [1] http://www.w3.org/TR/REC-xml/#NT-Attribute -- d_layer

2 1

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