- Ros-dev - ReactOS.org

Re: [ros-dev] About UNICODE<->ASCII support.
by carlo.bramix 13 Nov '07

13 Nov '07

Hello, > > Athough you should also admit that two WideCharToMultiByte() > > calls are not exactly something we can call "drammatic" code > As I also said, WideCharToMultiByte() can cause data corruption if a Unicode > character isn't supported by the currently selected ANSI codepage. > MultiByteToWideChar() is no problem, but the other direction can be > problematic. > After all, we're coding for Windows Server 2003-compatibility here. > We don't have to care about compatibility with Win9x (ANSI-only) or previous > NT versions. That's right, it can cause corruption. But, for an ascii-based OS, it's a compromise for getting the application working because that application, if compiled in that configuration, will work only on Win9x/ME. If someone wants to make an object working on his old OS, he must also be ready to the drawbacks, this has never been a news. Afterall, unicows is doing the same job when wrapping the vaious widechar APIs. But for NT and later, everything just need to be compiled as UNICODE, no? And this is what I cannot understand: the ability to work in both enviroment is an *added*value* to the software, not a defect. I just wanted to clarify that I was not asking to release the accessories and/or other parts of ReactOS' binaries compiled for ASCII. Absolutely not, in no way! Read: I want the most flexible international support available. Just another small bit: besides the functions with the 'W' suffix (while the remaining part of the planet uses at least the unified function names), sometimes debugging directly unicode is a pain, at least for me... The strings into the debuggers are shown as a vector of words instead of a clear string, same condition when declaring some constant strings into the sources, as vector of single chars... Horrible (urgh!). Sincerely, Carlo Bramini

2 1

rbuild auto generated resources
by Marc Piulachs 13 Nov '07

13 Nov '07

>From all changes introduced on my rbuild branch auto generated resources seems to be the most controversial by far so I will try to explain here the design decision behind it One of my particular obsessions is trying to optimize and automate the maxium ammout of things, if something can be reasonably created automatically why do it by hand? CURRENT SITUATION ================= Currently the version common defines REACTOS_STR_FILE_DESCRIPTION , REACTOS_STR_INTERNAL_NAME and REACTOS_STR_ORIGINAL_FILENAME , localized resources and theme manifest are added to [modulename].rc , rsrc.rc or splitted between both. Problems: - Theme manifests files "manifest.xml" are architecture dependent (X86) - Duplicated content, we will have hundreds of identical manifest files for every aplication - No way to compile an aplication without manifest - No way to compile an aplication with only specified localizations - Duplicated work, rbuild has all the information required to automatically generate the defines - If we decide to rename or introduce a new define in the future we will have to edit all resources by hand. - Resource localizations are compiled with any control , the only way to check if they are included is by hand. Advantatges to my proposal: - It solve all the above problems. - Reduce man work - Allows future changes in the format (editing the resource generator source code (1 file) vs all resources files on SVN) - It's the base to other future enchancments , when a new feature is added to rbuild we have just to modify it and all modules will automatically inherit it. An most important of all , it represents a change of the model to a metadata oriented build process. You describe the content (source code , resources ...) rather than the build , rbuild uses that information to generate the apropiate image (as always) but this information can also be used for multiple other things, analitics , reports , web .... How does it work? ================= First of all IT'S OPTIONAL , you can decide to use it or not, your choice. We will use the eventvwr.rbuild as sample: <?xml version="1.0"?> <module name="eventvwr" type="win32gui" installbase="system32" installname="eventvwr.exe"> <include base="eventvwr">.</include> <include base="eventvwr" root="intermediate">.</include> ...  <automanifest>manifest.xml</automanifest> <autoresource>auto.rc</autoresource>  <developer>mpiulachs</developer> <translator>cfinck</translator> <translator>fireball</translator> <translator>mpiulachs</translator> <metadata description="ReactOS Event Log Viewer" />  <localization isoname="de-DE">lang/de-DE.rc</localization> <localization isoname="en-US">lang/en-US.rc</localization> <localization isoname="es-ES">lang/es-ES.rc</localization> <localization isoname="fr-FR">lang/fr-FR.rc</localization> <localization isoname="ru-RU">lang/ru-RU.rc</localization> </module> to turn auto resources on we have to add the <autoresource> element with the name of the resource that will be created in the INTERMEDIATE folder in this case it will be named "auto.rc". It will also automatically create the apropiate manifest.xml file for the architecture being build (x86 or PPC) and will reference it in "auto.rc" Also it will validate and include the localizations, even it has localizations for 5 languages it will only compile those specified on languages.rbuild See attached files for autogenerated content I tried to explain the motivation behind my changes and why I think they are positive , of course I'm open to your questions , ideas or comments but please be contructive and argument your point of view , "I don't like it , we won't use it" as someone said is not an expected opinion. /Marc

8 21

question
by David Johnson 13 Nov '07

13 Nov '07

How is it possible to tell XP what specific IRQ to put your audio card on in Standard PC mode? 1 In the motherboard BIOS. 2 In the Device Manager. 3 Put the card in the corresponding slot. 4 There are jumpers on most motherboards that you can change to direct IRQs. 5 None of the above. _________________________________ Dave Johnson http://www.davefilms.us DaveFILMS® San Diego, CA & Nashville, TN http://perditioncity.us/ Voice Talent Writer, Producer, Director Independent Audio Theater Producer Voice mail and Fax#:(206)350-2915 Voice (615)722-2249 Skype & Msn Live messanger "DaveFilms" AIM / iChat AV "DaveFilms2007"

1 0

vr IRQ in windows
by David Johnson 13 Nov '07

13 Nov '07

Please list all VR IRQ in NT 5.1 and VI IF my computer is not in ACPI m ode is it in Standard PC mode? Please reply.. It is vary important. _________________________________ Dave Johnson http://www.davefilms.us DaveFILMS® San Diego, CA & Nashville, TN http://perditioncity.us/ Voice Talent Writer, Producer, Director Independent Audio Theater Producer Voice mail and Fax#:(206)350-2915 Voice (615)722-2249 Skype & Msn Live messanger "DaveFilms" AIM / iChat AV "DaveFilms2007"

1 0

Re: [ros-dev] [ros-diffs] [arty] 30352: Add structures related to devtree.c
by Aleksey Bragin 12 Nov '07

12 Nov '07

Why not use a linked list structure in LOADER_PARAMETER_BLOCK, describing hardware device tree? (I implemented a bit of it in winldr). Or is it for a different purpose? WBR, Aleksey Bragin. On Nov 11, 2007, at 12:27 PM, arty(a)svn.reactos.org wrote: > Author: arty > Date: Sun Nov 11 12:27:07 2007 > New Revision: 30352 > > URL: http://svn.reactos.org/svn/reactos?rev=30352&view=rev > Log: > Add structures related to devtree.c > > Modified: > trunk/reactos/include/reactos/ppcboot.h

2 1

Re: [ros-dev] Tracking implementation API status
by Aleksey Bragin 12 Nov '07

12 Nov '07

Hi, no, I was speaking about something different. Take a look - http://www.reactos.org/wiki/index.php/Coding_Style there I mean this: /*++ * @name SomeAPI * @implemented NT4 * * Do nothing for 500ms. * * @param SomeParameter * Description of the parameter. Wrapped to more lines on ~70th * column. * * @param YetAnotherParameter * Bleh, bleh :) * * @return STATUS_SUCCESS in case of success, STATUS_UNSUCCESSFUL * othwerwise. * * @remarks Must be called at IRQL == DISPATCH_LEVEL * *--*/ NTSTATUS STDCALL SomeAPI( ... rgenstat-alike tool should be able to parse such header, not only the old-style simple /* @implemented */ WBR, Aleksey Bragin. On Nov 10, 2007, at 1:06 AM, Marc Piulachs wrote: > Hi Aleksey, > > > > I don’t know if I understood you completely, rgenstat works by > parsing c/cpp source files not header files. What do you mean with > “standard function header”? > > > > If we are seriously going to use it I would like to make some > slightly modifications to it to make it more powerful but would > require help from someone with more experience than me writing > parsers in C. > > > > Regards, > > /Marc

4 4

Re: [ros-dev] rbuild auto generated resources
by Aleksey Bragin 11 Nov '07

11 Nov '07

On Nov 12, 2007, at 1:56 AM, Timo Kreuzer wrote: >> Once again, the data extracted from parsing is not TRUE metadata just >> meaningless strings that you can guess or interpret : "author : >> jdoe" , >> "author : jhondoe" , "author : jhon doe" are 3 different persons and >> Jhon Doe just one , I think it's obvious. >> > I disagree here. IMO information about developers and translators > belong to svn. They should neither go into the sources nor into > rbuild files. If you want to find out about it, ask svn and it will > tell you the exact name. We also don't really have maintainers for > most modules, so most rbuild files would be spammed with the names > of lots of developers without saying anything about who wrote a > paticular piece of code. There is standard per-file header for ReactOS source code (if it's not used everywhere, it's a temporary problem), which lists programmers, and it's usually (almost always) maintained. Whenever our code is indexed by systems like Google codesearch, everyone can clearly see the license and authorship from the source file. Additionally, SVN holds exact per-line history of changes. What's the benefit of storing authoship in .rbuild too? (I agree it is logical, but if there is no benefit, then...) WBR, Aleksey Bragin.

2 1

Re: [ros-dev] Tracking implementation API status
by Aleksey Bragin 11 Nov '07

11 Nov '07

Your opinion does have a strong point. Implemented/unimplemented were useful in the early stages, I think. Right now, for both Wine and ReactOS, the quality of implementation matters, not quantity. How is Wine's system done, about documenting functions - where is it done? Source code comments? Can it be adjusted to fit ReactOS coding style? WBR, Aleksey Bragin. On Nov 10, 2007, at 10:16 PM, Steven Edwards wrote: > On Nov 10, 2007 4:00 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote: >> Hi, >> no, I was speaking about something different. >> Take a look - http://www.reactos.org/wiki/index.php/Coding_Style >> there I mean this: > > The implemented/unimplemented tags are really worthless because what > if the API takes 20 params and 18 of them are implemented > and nothing known uses the other 2 params? Do you call it implemented > or unimplemented? Its better to autogenerate the docs from the > function comment headers. See here, I think this is a MUCH better > system and it already works. No point in developing another. > > http://source.winehq.org/WineAPI/ > > If the API does not show up in the documented API then it should be > safe to assume its not implemented. If it is implemented and not > documented then its a Janitorial project. > > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

5 4

Re: [ros-dev] Tracking implementation API status
by Aleksey Bragin 09 Nov '07

09 Nov '07

I support that, though some modifications should be required, because in the kernel a standard function header [should be]/is used. If it's able to parse that header too (provided it contains the @implemented/ @unimplemented), then it's great. WBR, Aleksey Bragin. On Nov 9, 2007, at 8:29 PM, Marc Piulachs wrote: > As most of you know, Casper created a small tool rgenstat (tools/ > rgenstat) that is able to parse source code for modules specified > on apistatus.lst seeking for public APIs decorated with the > @implemented or @unimplemented C comment. Rgenstat when invoked > typing “make rgenstat” it produces an xml file containing all the > functions and it’s current implementation status. With this > database we can do all sorts of automatic compatibility reports . > see for example wine’s equivalent http://www.winehq.org/site/status > or http://www.codexchange.net/roslib generated from incomplete > reactos data , (work in progress) > > > > As it easy and not intrusive I would suggest using this feature to > kernel and core developers. Fireball , GreatLord , Jim , what do > you think about that ? > > > > /Marc

2 1

Re: [ros-dev] rbuild auto generated resources
by Aleksey Bragin 09 Nov '07

09 Nov '07

If it's impossible to make correct .rc files (without the hassle of using backends), then Marc's way is a way to go. There is such tool by Wine, which uses .spec, it may need writing a MSVC-backend though,. WBR, Aleksey Bragin. On Nov 9, 2007, at 10:56 PM, Alex Ionescu wrote: > I think you're all missing the point. > > As it stands now, MSVC won't even READ most of your resource files > because you've decided to write them in a way that violates the .rc > standard and that only binres/windres/whatever-you-call-that- > incompatible-garbage can parse. > > Mark's proposal, apart from fixing all the problems he brought up, > will finally allow you to write resource files that both MSVC and > your-retarded-rc-compiler-name-goes-here can understand, with minimum > effort. Right now, you're all stuck rewriting all your .rc files and > creating .msvc.rc files. > > By the way Mark, you should extend this to definition files. Once > again, MSVC is incompatible with all the ReactOS .def files, which > have been tailored so that Mangle32-gcc can understand them, so > you'll have to create msvc.def files as well. > > The more rbuild can generate independently, the better. You get MSVC > files *after* running "make msvc8", and it's that step that would be > creating the .def/.rc files for MSVC anyway -- what exaclty is it all > you're complaining about regarding "MSVC" compatibility? You don't > have it, how the hell can you lose it, and more importantly, why is > the only suggestion that will finally let you have it "disliked"?! > > You make no sense. > > -- > Best regards, > Alex Ionescu

1 0

Re: [ros-dev] rbuild auto generated resources
by Marc Piulachs 09 Nov '07

09 Nov '07

Forgot to attach autogenerated sample files _____ From: Marc Piulachs [mailto:marc.piulachs@codexchange.net] Sent: Friday, November 09, 2007 7:24 PM To: 'ReactOS Development List' Subject: rbuild auto generated resources >From all changes introduced on my rbuild branch auto generated resources seems to be the most controversial by far so I will try to explain here the design decision behind it One of my particular obsessions is trying to optimize and automate the maxium ammout of things, if something can be reasonably created automatically why do it by hand? CURRENT SITUATION ================= Currently the version common defines REACTOS_STR_FILE_DESCRIPTION , REACTOS_STR_INTERNAL_NAME and REACTOS_STR_ORIGINAL_FILENAME , localized resources and theme manifest are added to [modulename].rc , rsrc.rc or splitted between both. Problems: - Theme manifests files "manifest.xml" are architecture dependent (X86) - Duplicated content, we will have hundreds of identical manifest files for every aplication - No way to compile an aplication without manifest - No way to compile an aplication with only specified localizations - Duplicated work, rbuild has all the information required to automatically generate the defines - If we decide to rename or introduce a new define in the future we will have to edit all resources by hand. - Resource localizations are compiled with any control , the only way to check if they are included is by hand. Advantatges to my proposal: - It solve all the above problems. - Reduce man work - Allows future changes in the format (editing the resource generator source code (1 file) vs all resources files on SVN) - It's the base to other future enchancments , when a new feature is added to rbuild we have just to modify it and all modules will automatically inherit it. An most important of all , it represents a change of the model to a metadata oriented build process. You describe the content (source code , resources ...) rather than the build , rbuild uses that information to generate the apropiate image (as always) but this information can also be used for multiple other things, analitics , reports , web .... How does it work? ================= First of all IT'S OPTIONAL , you can decide to use it or not, your choice. We will use the eventvwr.rbuild as sample: <?xml version="1.0"?> <module name="eventvwr" type="win32gui" installbase="system32" installname="eventvwr.exe"> <include base="eventvwr">.</include> <include base="eventvwr" root="intermediate">.</include> ...  <automanifest>manifest.xml</automanifest> <autoresource>auto.rc</autoresource>  <developer>mpiulachs</developer> <translator>cfinck</translator> <translator>fireball</translator> <translator>mpiulachs</translator> <metadata description="ReactOS Event Log Viewer" />  <localization isoname="de-DE">lang/de-DE.rc</localization> <localization isoname="en-US">lang/en-US.rc</localization> <localization isoname="es-ES">lang/es-ES.rc</localization> <localization isoname="fr-FR">lang/fr-FR.rc</localization> <localization isoname="ru-RU">lang/ru-RU.rc</localization> </module> to turn auto resources on we have to add the <autoresource> element with the name of the resource that will be created in the INTERMEDIATE folder in this case it will be named "auto.rc". It will also automatically create the apropiate manifest.xml file for the architecture being build (x86 or PPC) and will reference it in "auto.rc" Also it will validate and include the localizations, even it has localizations for 5 languages it will only compile those specified on languages.rbuild See attached files for autogenerated content I tried to explain the motivation behind my changes and why I think they are positive , of course I'm open to your questions , ideas or comments but please be contructive and argument your point of view , "I don't like it , we won't use it" as someone said is not an expected opinion. /Marc

1 0

Tracking implementation API status
by Marc Piulachs 09 Nov '07

09 Nov '07

As most of you know, Casper created a small tool rgenstat (tools/rgenstat) that is able to parse source code for modules specified on apistatus.lst seeking for public APIs decorated with the @implemented or @unimplemented C comment. Rgenstat when invoked typing "make rgenstat" it produces an xml file containing all the functions and it's current implementation status. With this database we can do all sorts of automatic compatibility reports . see for example wine's equivalent http://www.winehq.org/site/status or http://www.codexchange.net/roslib generated from incomplete reactos data , (work in progress) As it easy and not intrusive I would suggest using this feature to kernel and core developers. Fireball , GreatLord , Jim , what do you think about that ? /Marc

1 0

Window Handle Leak
by James Tabor 09 Nov '07

09 Nov '07

Hi, Here is a list of files that use ntuser/object.c As you all see, we Dereference more than we Reference! Reference is 0 so we are using Dereference as a delete? This is a mess! Not once is a Thread referenced! Thanks, James ./callproc.c:52: ObmDeleteObject(Handle, ./hook.c:209: ObmDeleteObject(Hook->Self, otHook); ./cursoricon.c:413: ObmDeleteObject(hCurIcon, otCursorIcon); ./cursoricon.c:487: Ret = ObmDeleteObject(CurIcon->Self, otCursorIcon); ./menu.c:320: ObmDeleteObject(Menu->MenuInfo.Self, otMenu); ./window.c:433: ObmDeleteObject(Window->hSelf, otWindow); ./accelerator.c:365: ObmDeleteObject(hAccel, otAccel); ./accelerator.c:374: ObmDeleteObject(hAccel, otAccel); ./accelerator.c:414: ObmDeleteObject(hAccel, otAccel); ./callproc.c:64: NewCallProc = (PCALLPROC)ObmCreateObject(gHandleTable, ./callproc.c:88: NewCallProc = (PCALLPROC)ObmCreateObject(gHandleTable, ./hook.c:113: Hook = ObmCreateObject(gHandleTable, &Handle, otHook, sizeof(HOOK)); ./monitor.c:92: Monitor = ObmCreateObject(gHandleTable, &Handle, otMonitor, sizeof (MONITOR_OBJECT)); ./cursoricon.c:399: CurIcon = ObmCreateObject(gHandleTable, &hCurIcon, otCursorIcon, sizeof(CURICON_OBJECT)); ./menu.c:333: Menu = (PMENU_OBJECT)ObmCreateObject( ./menu.c:442: Menu = (PMENU_OBJECT)ObmCreateObject( ./window.c:1537: ObmCreateObject(gHandleTable, (PHANDLE)&hWnd, ./accelerator.c:351: Accel = ObmCreateObject(gHandleTable, (PHANDLE)&hAccel, otAccel, sizeof(ACCELERATOR_TABLE)); ./input.c:1045: ObmDereferenceObject(DesktopWindow); ./msgqueue.c:776: ObmDereferenceObject(Window); ./hook.c:449: ObmDereferenceObject(HookObj); ./hook.c:455: ObmDereferenceObject(HookObj); ./hook.c:624: ObmDereferenceObject(Hook); ./hook.c:639: ObmDereferenceObject(Hook); ./hook.c:656: ObmDereferenceObject(Hook); ./hook.c:673: ObmDereferenceObject(Hook); ./hook.c:738: ObmDereferenceObject(HookObj); ./monitor.c:119: ObmDereferenceObject(pMonitor); ./cursoricon.c:375:// ObmDereferenceObject(CurIcon); ./cursoricon.c:386:// ObmDereferenceObject(CurIcon); ./cursoricon.c:414: ObmDereferenceObject(CurIcon); ./cursoricon.c:420: ObmDereferenceObject(CurIcon); ./cursoricon.c:532:// ObmDereferenceObject(Object); ./cursoricon.c:369:// ObmReferenceObject( CurIcon); ./cursoricon.c:519:// ObmReferenceObject(CurIcon);

2 1

Re: [ros-dev] [ros-diffs] [weiden] 29670: Tweak the ScrollDC implementation
by tamlin＠algonet.se 08 Nov '07

08 Nov '07

jimtabor wrote: >I noticed WndProc messages originate from win32k too. The window thread is >locked and then the message is sent out. > >Example: Function call User32 -> Win32k -> send message. > >Maybe we are doing double the work when we scroll on a bar. The rapid >blinking of the bar too. We maybe sending more than one message out. Trying a hypothesis here, could it work if all such w32k-registered- and-managed window classes, if not subclassed by the app, lock visual updates while calling back into usermode (cmp. LockWindowUpdate(hWnd) )? (recursive calls, whether intentional or from buggy user-mode app code could invalidate it) >4. Fix bugs. >5. Get paid! If you solve that... :-) -- Mike

2 2

Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1
by Olaf Siejka 07 Nov '07

07 Nov '07

> > > - Declarative module localizations : Now module localizations are created > in > a declarative way which makes trivial tasks like listing non existent or > outdated language localizations in real time for example : > > http://www.codexchange.net/rosdoc/localizations.htm > > Let me know your opinions and suggestions as I would like to start > finishing > some of this features and merge all/part of my changes back to trunk > I find this part extremely important. It would allow real-time tracking of translation progress/status (if i understood it correctly) which would greatly help maintain all the growing ROS localizations and help all ROS translating teams. Such webpage, as you presented here, should be created on ROS website as soon as it would be possible.

5 17

About UNICODE<->ASCII support.
by carlo.bramix 06 Nov '07

06 Nov '07

Hello everyone, I just would like talk about a recent fix applied to one of the components of ReactOS. It is not my intention to make problems in any way with this topic, or pretending a change of the direction taken by the project (peace!). In that recent change, the hybrid support for both ASCII and UNICODE support into task manager has been dropped. I would like that you try to review your opinion on such changes. Me too, I want final builds of executables in unicode format. I think to know almost all advantages of international support. However, I also believe that you should not see the ASCII support as something to throw out of the window, but as a chance, because not all applications in the world are compiled as unicode, so having something to test the ASCII implementation included into ROS is not a so bad idea. As I said, it is a chance for testing. Some of the work here seems derived from wine, but probably (or better: surely) people behind wine had to face to the problem called "debugging" before they got something stable. A closed-source application may not work, but at least there is a chance (perhaps minimal or even less) to replicate a bug into one of the applications available to us. Technically, it isn't a problem for me to make things working on win9x, since I just need to link to UNICOWS.DLL and the problem is almost solved. I just don't like very much that position. And I also understand that my opinion isn't important at all in front of your decisions or the ReactOS standard. Sincerely, Carlo Bramini.

5 5

Online translation service
by Olaf Siejka 05 Nov '07

05 Nov '07

I have no idea on what is being prepared or planned, nor i do not need any mean for translating RC files online. My only concern is for easier control of localisation for a given language, so i dont have to manually check every single one of the rc files. Best regards

2 1

Mile Stones
by James Tabor 05 Nov '07

05 Nov '07

To all! A monumental mile stone was crossed today at 2000z 05/11/2007. ReactOS is now a true GUI/OS. Thread batching is functional and tested good. Solitaire was the program and it only ran once, the function was SetBrushOrgEx. Thanks goes out to all of you and my excitement is the fun I am having working with all of you with this project. Sorry for things said in the past and knowing in all good intentions you all did your best to bring this project to this point. Thanks! James PS: Keep coding! and go back to work!

1 0

work on rbuild branch
by Marc Piulachs 03 Nov '07

03 Nov '07

As some of you may know I have been working in rbuild on my own branch (http://svn.reactos.org/svn/reactos/branches/rbuild/reactos/) for the last two weeks. I will summarize my most important changes here so anyone can give me their opinion: - Created a new concept "the cd bootstrap folder" . The cd bootstrap folder is a user customizable folder in the cd's root that defaults to the current build architecture for example i386 o ppc. - Modifed the InstallBase from the BootStrap element to be relative to the bootstrap folder, for example the usetup bootstrap: <bootstrap installbase="system32" nameoncd="smss.exe" /> will be created in : (CD)\i386\system32\smss.exe on a I386 build and (CD)\ppc\system32\smss.exe on a powerpc build - Introduced a new element "bootstrapfile" equivalent to the bootstrap for module target but applied to regular files for example : <bootstrapfile>hivecls.inf</bootstrapfile> will be placed in : (CD)\i386\hivecls.inf on a I386 build and (CD)\ppc\hivecls.inf on a powerpc build With these changes we will be able to place complete installation for more than one architecture in the same cd .Only one of the architectures will be able to be booted by default but we can include the cdmake utility + some .bat files in a (CD)\tools folder so the user can download the official CD with all supported architectures and create a bootable boot CD for a particular architecture. cool huh? - Experimental support to autogenerate rsrc.rc equivalent and platform dependent manifest.xml to intermediate folder - Add preliminary support to track authors/contributors/developers/translators for each module. It can be useful to autogenerate uptodate \CREDITS file , module/authors reports (see for example: http://www.codexchange.net/rosdoc/authors.htm or http://www.codexchange.net/rosdoc/eventvwr.htm) or even source code for modules like notevil - Autogenerate CREDITS file in intermediate folder (for now) - Declarative module localizations : Now module localizations are created in a declarative way which makes trivial tasks like listing non existent or outdated language localizations in real time for example : http://www.codexchange.net/rosdoc/localizations.htm Let me know your opinions and suggestions as I would like to start finishing some of this features and merge all/part of my changes back to trunk note: The produced iso images won't boot due to relocation of the \loader folder. boot/freeldr/bootsect/isoboot.asm and isobtrt.asm will have to be modified to search \i386\loader .Probably also setuldr.sys will have to be modified. /Marc

2 1

Re: [ros-dev] [ros-diffs] [gbrunmar] 29929: Made each service have its own pipe name as done in Windows
by Aleksey Bragin 29 Oct '07

29 Oct '07

On Oct 28, 2007, at 5:13 PM, gbrunmar(a)svn.reactos.org wrote: > - DPRINT("CreateNamedPipeW() done\n"); > + DPRINT1("CreateNamedPipeW(%S) done\n", NtControlPipeName); Success reports should usually remain DPRINT, so that they don't pollute the debug log. WBR, Aleksey Bragin.

2 1

Re: [ros-dev] Moving some screensavers to rosapps
by Aleksey Bragin 28 Oct '07

28 Oct '07

Hi, "reactos" should have only bare minimum, so I agree about 1 gdi and 1 opengl. Other must be moved to rosapps. WBR, Aleksey Bragin. On Oct 28, 2007, at 2:32 AM, Colin Finck wrote: > Hello everyone, > > Now that we have 5 screensavers in trunk, and they are all in the > "reactos" > directory, it might be a good idea to move some of them to "rosapps". > The big question is now: Which ones shall be kept in "reactos" and > which > ones shall be moved to "rosapps"? > >> From the technical view, it's probably the best idea to keep one >> OpenGL and > one GDI screensaver in "reactos" (for example 3dtext and logon). > Please share your ideas about that. > > Regards, > > Colin

1 0

Moving some screensavers to rosapps
by Colin Finck 27 Oct '07

27 Oct '07

Hello everyone, Now that we have 5 screensavers in trunk, and they are all in the "reactos" directory, it might be a good idea to move some of them to "rosapps". The big question is now: Which ones shall be kept in "reactos" and which ones shall be moved to "rosapps"? >From the technical view, it's probably the best idea to keep one OpenGL and one GDI screensaver in "reactos" (for example 3dtext and logon). Please share your ideas about that. Regards, Colin

1 0

Re: [ros-dev] [ros-diffs] 29826 ...
by tamlin＠algonet.se 27 Oct '07

27 Oct '07

Alex Ionescu wrote: >>> 1) Why implement new, complex features in the kernel instead of >>> fixing current bugs? >> >> You pay, you get a saying in what I work on. I pay, I decide. > >No, this is an open source project, everyone gets a say on what you >work on -- you're free to ignore such sayings at your leisure. Seems I was too imprecise (or again a language barrier/misunderstanding). Sorry. My intention was to communicate that if you pay, you get the option of (trying to) tell me what to work on. When I pay, I decide. Obviously anyone is at any time free to comment. >The quota code is called by the process functions, and maybe even by >drivers, but it doesn't affect their behavior. I'm going out on a limb here (as I haven't checked it), but can't a JOB (artificially) limit available resources? That's part of their intention, isn't it? (please read on) >Two choices: > >1) Implement a rather complex quota implementation, including commit >charges in Mm (which is several thousand lines of code in NT), I knew I got into a rather large area, but this sounds insane for something as seemingly "simple". > to a fragile kernel If it's that fragile it needs to be fixed. If you got a better idea to do it than implementing previously missing functionality to expose those fragile parts of it, especially as what I started to work on apparently exposed those fragile parts, I'm all ears. > & > Use up a valuable developer's time, probably a couple man-weeks Should that be how I chose to spend my time - what's the difference if I hadn't been around at all? None, except the end result might make Win32 GlobalMemoryStatus and VM_COUNTERS present useful and usable data. > & > Add new bugs to a hot path during process/object creation/ >deletion (I hope you'll agree all new code has bugs) Only by convention, not by definition. :-) >OR > >2) Continue working on bug fixing the fragile parts of the kernel and >OS || Implement critical missing functionality for a target driver/ >application & This actually started as fixing critical missing functionality (Wax: feel free to chime in). Currently ROS does not COMMIT on such allocation requests. It happily allows an exe in a 128MB machine with 32MB pagefile to COMMIT almost 2GB memory. The error is of course in the way ROS handles COMMIT requests to VirtualAlloc, in that it defers committing the memory until something touches it... (that is no joke) The first step to research this was (for me) to see the behaviour of GlobalMemoryStatus, and indeed it was broken - it was unimplemented... So what do I do? I "dig where I stand". I start an attempt implementing the missing functionality. So the reason I came to touch Ps, and am digging way deeper in Mm than I'd really like to, is simply the GlobalMemoryStatus(Ex) Win32 API function(s), to even be able to verify, from user-mode, behaviour. [...] >> On a sidenote, the only public reference to PS_QUOTA_TYPE I could find >> were from a PDB file transcript from ntdll, posted at a french site. > >It should be added to the NDK. Agreed. But as I didn't know if that's still your baby (SVN access or not) and only synched at intervals, or if it has been "adopted", and if adding such data types, even if suspected to be correct, from such few and vague information source was even acceptable... I played it safe and used just the indices. Thanks for sharing the typename. If concensus is that adding that data type introduces no problems, even if from such a vague source, I'm in favor of adding it (as it'd solve more than one immediate problem). >>> 7) The quota routines require interlocks >> >> Yep. Even requires a lock for checking and updating QuotaPeak. > >No it doesn't, you can use Interlocked Compare Exchange. Are you thinking of the, semantically non-obvious for maintenance programmers, OldVal = Interlocked*Add(&Quota, Addend); InterlockedCompareExchange(&Peak, OldVal + Addend, OldVal + Addend); ? I think using a spinlock for that would make it much more obvious. Should profiling display it had a measurable impact on execution, sure. But we should also keep in mind we are then trading a single spinlock for two *locked* (bus-snooping/cache-invalidating) instructions. I don't know which is worse (performance wise). >>> 8) They also require a global spinlock in the "give back" case. >> >> I don't follow. Why? I'd imagine the "give back" case to be simpler >> than the charge case, as the former only needs to decrement the usage >> (InterlockedExchangeAdd with a negative value), while the latter needs >> to increment, followed by comparing with and possibly update Peak. > >The global spinlock is required when inserting new quota blocks, >dereferencing them, expanding the quota and giving back the quota. Ah, right... the quota blocks. As already displayed I didn't touch them (I honestly don't even know what they are for yet). I only looked at the (immediate) process quota entries. The linked lists I never touched. >I still disagree with trunk-is-a-playground I have never disagreed with that, so I'm not sure what you're referring to. >and I think that pseudo-code should go in branches, but you're free to disagree. I suggest you take that discussion with the project coordinator, that I cleared that diff with and he explicitly stated a preference for it even after I mentioned "branch". I disagree with you re. comments. I think pseudo-code in comments (in trunk even) is to prefer, as it can explain behaviours and intentions way better than plain english or even documentation. If those comments help maintenance-programmers ten or more years from now, even if only one single person, the comments were well spent time and place. -- Mike

1 0

Re: [ros-diffs] 29826 ...
by tamlin＠algonet.se 25 Oct '07

25 Oct '07

Alex Ionescu wrote: > 1) Why implement new, complex features in the kernel instead of > fixing current bugs? You pay, you get a saying in what I work on. I pay, I decide. > I had already written all these functions, but deleted them, Wasn't that a bonehead thing to do? > because nobody needed them, ... at the time. > and the Mm part was too complex to do. Guess what; I'm currently trying to actually implement it for Mm. Ps was a first step in that direction. Yes, Mm is complex, and yes I don't understand it enough yet - not by a longshot. But checking in incremental improvements, so that the code doesn't get lost, and disabled by default to not affect the behaviour of trunk - that's a good thing. It means people can both review and test the incremental changes, and perhaps even suggest improvements - like you did in pt. 5 below. > 2) Why are you bothering with PspPoolQuotaIndexFromPoolType? Ignorance of: > In case you haven't noticed, there's something called pool masks PAGED_POOL_MASK. Got it. > 5) Instead of duplicating code, perhaps consider calling a main > worker function such as PspChargeQuota? A sound refactoring suggestion. > 6) Consider using an enum instead of magic numbers inside the > quota entries, I believe it's called PS_QUOTA_TYPE. I just followed the lead of existing code. Had there been any mention of an enumeration for nonpaged, paged and pagefile, I would obviously have used those names. On a sidenote, the only public reference to PS_QUOTA_TYPE I could find were from a PDB file transcript from ntdll, posted at a french site. > 7) The quota routines require interlocks Yep. Even requires a lock for checking and updating QuotaPeak. > 8) They also require a global spinlock in the "give back" case. I don't follow. Why? I'd imagine the "give back" case to be simpler than the charge case, as the former only needs to decrement the usage (InterlockedExchangeAdd with a negative value), while the latter needs to increment, followed by comparing with and possibly update Peak. > 9) Committing code that won't even build, even with the define on, > isn't very appropriate. I agree. > If someone wants to actually test this, they won't be able to build it That's an interesting statement. Care to elaborate on how you reached such a factually wrong conclusion? > because of things like "refuse" Some people prefer pseudo-code over nothing at all. Some prefer void. Some people are able to spot C comment blocks. Some are not. Me, I checked that in with both the approval and a statement of preference for this kind of committs by the project coordinator. It not only compiles, it partially works too. > SVN should contain code that builds at any time. It's > not hard to write /* TODO */.. You really need (new?) glasses. You even quoted it yourself! "/* TODO: Check with Process->QuotaBlock if this can be satisfied, */" -- Mike

2 1

Re: [ros-diffs] 29702 ...
by tamlin＠algonet.se 25 Oct '07

25 Oct '07

Alex Ionescu wrote: > Windows uses the FILE_READ_DATA flag here, not FILE_READ_ATTRIBUTES. Yes? And? Let's study the code and the open modes used here. This code tries to open Device\HarddiskN\Partition0 (N = 0 ...) for the sole purpose of checking for availability, and immediately close the handle if the open succeeded. Why would one use FILE_READ_DATA if one never intended to read anything? The code also uses SYNCHRONIZE. Why would one use SYNCHRONIZE if one never intended to wait on the handle? As I see it, that's just requesting extra work for the purpose of nothing. The purpose of that open call is only to see if the disk exists, and if so create the symbolic link PhysicalDriveN -> HarddiskN\Partition0. I don't buy "Windows does this" without backing it up with any arguments whatsoever as to why Windows does this. Perhaps Windows does more with the returned handle than immediately closing it, something that actually requires READ_DATA? > all this is doing is hiding the bug (which is somewhere in vfat) I'm looking forward to the explanation of how opening HarddiskN\Partition0 (not "Partition1", not "Partition1\", but "Partition0" - aka the whole disk) would involve any filesystem activity whatsoever? > Because it's now gone, it'll probably happen in some mysterious > application 2 years from now and nobody will know why. Hahaha, you really are a joker. An app? Calling xHalIoAssignDriveLetters, that is called with a frickin' LoaderBlock? That function is used exactly once, during system startup. Health reasons suggest not holding your breath while waiting for such an application. :-) -- Mike

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev