- Ros-dev - ReactOS.org

ncpa
by Murphy, Ged (Bolton) 07 Apr '06

07 Apr '06

This is all that stands in the way of getting 0.3.0 out the door. As soon as we can config the network adapters via the dialog, we can branch and start bug hunting. This would also be a good time to enlist some more testers under the Munger wing ;) I'm going to have a look at this tonight, but I've had a look before and IIRC, I had trouble hunting the bug down. It would be good if someone with a bit more experience in this area could have a look. I think Gé was working on this before Christmas, so I'm hopefully gonna catch up with him tonight via IM, as I'm not sure if he's subscribed to ros-dev anymore. We've been promising this for about 18 months now. I know a hell of a lot of work has been done in other areas (in fact, the jump from 0.3 to 0.4 should be relatively small as much of the 0.4 work is done), but we need to deliver. After all the recent goings on, getting 0.3.0 would be a nice boost for the project, in terms of both morale and PR. Is anyone willing to help? 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

6 6

Roadmap / List of tasks / Attn. all developers
by Aleksey Bragin 07 Apr '06

07 Apr '06

Hello! In an effort to put ReactOS development into higher scales, I would like to announce that I am creating a global list of all possible development tasks, broken down into modules/sections/etc. By the time all tasks in this list are fully completed, ReactOS would result in transition to a beta-stage and bumping version number to >= 0.5 (so you understand how big this todolist will be). This list would be a base to the global ReactOS Roadmap which is going to show a current status of reactos, expected times before future releases, and what future releases will contain exactly. And the most important: It makes every programmer willing to participate in the project to find a task he feels familiar with, actually do it, and see how it advances the project. All the way before, the only really managed part of development was fixing bugs, because Bugzilla is storing all bugs descriptions/patches/ assignations/etc. Now, similar thing will come in help to the general development. Creating such a list is quite a hard task, and it can't be done by an individual, so: Attention all ReactOS Developers, please! Your word is very valuable here! Please, compile a list of tasks you think ReactOS needs and send it here as a reply to this message (I will put a preliminary draft of what I already compiled so far too somewhere in the wiki). Each task should be a clearly outlined work if possible, however all information is important so you can add something like "//TODO: Add more details about this task later" too. Example of a task considered as "good" to me: - Boot manager -- Make Loader Parameter Block compatible with Windows XP one Example of a less exact task, but which is still "good" - Boot manager -- Make boot process conforming to NTLDR boot process, so that FreeLdr can boot Windows without NTLDR. Example of a "bad" task - NTOSKRNL -- Improve kernel Thank you for the collaboration, I know this maybe a quite hard to do, but it's the first steps of an effort to get development to the speed and quality we never had before. Other things to mention are continuos integration system, regression testing frameworks, etc, etc. With the best regards, Aleksey Bragin.

13 15

Re: [ros-dev] Re: [ros-diffs] [amunger] 21474: DHCP Client fixes and enhancements Set the correct hardware type flag. Fixes bug 651. Send option 12 on discovery, allows some DHCP servers to dynamically update DNS. Send option 61 for good measure. We
by WaxDragon 06 Apr '06

06 Apr '06

On 4/6/06, Thomas Weidenmueller <w3seek(a)reactos.com> wrote: > There are several issues with this patch: > > > + /* What a strage dance */ > > + struct client_config *config = ifi->client->config; > > 1) dhcp crashes for me on the line above. Strange, it works for me here. > > > + char ComputerName [MAX_COMPUTERNAME_LENGTH + 1]; > > 2) use Unicode, please. Obsolete as described in 4) I really tire of hearing this. None of the code in dhcp.exe is unicode right now. I've tried to hack on several pieces of ros only to be told "USE UNICODE" by another dev. Trying to convert entire modules has always gone terribly for me. > > > + DWORD ComputerNameSize = sizeof ComputerName / sizeof ComputerName[0]; > > + > > + GetComputerName(ComputerName, & ComputerNameSize); > > 3) missing error check, leading to buffer overflow if accessed the > string in ComputerName > > > + /* This never gets freed since it's only called once */ > > + LPSTR lpCompName = > > + HeapAlloc(GetProcessHeap(), 0, strlen(ComputerName) + 1); > > 4) makes the ComputerName buffer on the stack obsolete. Only use the > dynamic buffer. strlen will likely cause a buffer overflow if the > computer name was longer than the length of the (obsolete) static buffer > on the stack, since the static buffer will never be initialized in this > case. I'll try to fix this. > > > + if (lpCompName !=NULL) { > > + GetComputerName(lpCompName, & ComputerNameSize); > > 5) once again missing error check which may cause buffer overflows in > the following code > > > + /* Send our hostname, some dhcpds use this to update DNS */ > > + config->send_options[DHO_HOST_NAME].data = strlwr(lpCompName); > > 6) strlwr is POSIX ;) Not helpful, suggest something better. > > > + config->send_options[DHO_HOST_NAME].len = strlen(ComputerName); > > 7) operating on the wrong buffer, may cause buffer overflow due to 5) > > > + warn("util.c read_client_conf poorly implemented!"); > > Indeed :( > > Apart from the bugs mentioned in this code, GetComputerNameExA has a few > bugs: 1) incorrectly returning ERROR_OUTOFMEMORY instead of FALSE and 2) > not checking the return value of RtlUnicodeStringToAnsiString. > > - Thomas > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > WD -- <Bizzeh> it even has a panda that pops out of your case and mauls people who ask stupid questions

3 2

RE: [ros-dev] Re: [ros-diffs] [amunger] 21474: DHCP Client fixes and enhancements
by Murphy, Ged (Bolton) 06 Apr '06

06 Apr '06

Thomas Weidenmueller wrote: > I don't mean to offend anybody with my criticism, I just want to point > out what could and should be fixed or done differently. Your criticism is hugely appreciated. That's the whole point of ros-diffs :) WaxDragon wrote: > I'll try to fix this. I'll give you a hand with it tonight if you need one. 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

Re: [ros-diffs] [amunger] 21474: DHCP Client fixes and enhancements Set the correct hardware type flag. Fixes bug 651. Send option 12 on discovery, allows some DHCP servers to dynamically update DNS. Send option 61 for good measure. We use the MAC address as some other OSes do.
by Thomas Weidenmueller 06 Apr '06

06 Apr '06

There are several issues with this patch: > + /* What a strage dance */ > + struct client_config *config = ifi->client->config; 1) dhcp crashes for me on the line above. > + char ComputerName [MAX_COMPUTERNAME_LENGTH + 1]; 2) use Unicode, please. Obsolete as described in 4) > + DWORD ComputerNameSize = sizeof ComputerName / sizeof ComputerName[0]; > + > + GetComputerName(ComputerName, & ComputerNameSize); 3) missing error check, leading to buffer overflow if accessed the string in ComputerName > + /* This never gets freed since it's only called once */ > + LPSTR lpCompName = > + HeapAlloc(GetProcessHeap(), 0, strlen(ComputerName) + 1); 4) makes the ComputerName buffer on the stack obsolete. Only use the dynamic buffer. strlen will likely cause a buffer overflow if the computer name was longer than the length of the (obsolete) static buffer on the stack, since the static buffer will never be initialized in this case. > + if (lpCompName !=NULL) { > + GetComputerName(lpCompName, & ComputerNameSize); 5) once again missing error check which may cause buffer overflows in the following code > + /* Send our hostname, some dhcpds use this to update DNS */ > + config->send_options[DHO_HOST_NAME].data = strlwr(lpCompName); 6) strlwr is POSIX ;) > + config->send_options[DHO_HOST_NAME].len = strlen(ComputerName); 7) operating on the wrong buffer, may cause buffer overflow due to 5) > + warn("util.c read_client_conf poorly implemented!"); Indeed :( Apart from the bugs mentioned in this code, GetComputerNameExA has a few bugs: 1) incorrectly returning ERROR_OUTOFMEMORY instead of FALSE and 2) not checking the return value of RtlUnicodeStringToAnsiString. - Thomas

1 0

RE: ncpa
by Ge van Geldorp 04 Apr '06

04 Apr '06

> From: "Murphy, Ged (Bolton)" <MurphyG(a)cmpbatteries.co.uk> > > I'm going to have a look at this tonight, but I've had a look > before and IIRC, I had trouble hunting the bug down. > It would be good if someone with a bit more experience in > this area could have a look. > > I think Ge was working on this before Christmas, I was > so I'm > hopefully gonna catch up with him tonight via IM, as I'm not > sure if he's subscribed to ros-dev anymore. I am, although I don't read every message anymore. The status of the applet when I worked on it was that the UI was complete and I was starting to work on transfering the data from the dialog to the TCP/IP driver (via the DHCP client). That part simply isn't implemented yet. I don't have any uncommitted code floating around. Ge

1 0

RE: [ros-diffs] [greatlrd] 21453: Start Implement HEL 1. Start im plement HEL Inisate 2. Start implement HEL GetAvailMem
by Murphy, Ged (Bolton) 04 Apr '06

04 Apr '06

> + DWORD HELMemoryAvilable; > + This->HELMemoryAvilable = HEL_GRAPHIC_MEMORY_MAX; > + *free = This->HELMemoryAvilable; There is a small typo throughout this code "Available" :) ************************************************************************ 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-diffs] [tretiakov] 21429: [AUDIT] msgina is clean.
by Ged Murphy 01 Apr '06

01 Apr '06

aleksey(a)studiocerebral.com wrote: > Author: tretiakov > Date: Fri Mar 31 21:47:52 2006 > New Revision: 21429 > > URL: http://svn.reactos.ru/svn/reactos?rev=21429&view=rev > Log: > [AUDIT] msgina is clean. > > What is the reason for these being clean signed off as clean? Did you speak to the authors? Did you follow the conditions in the wiki?

5 6

Re: [ros-diffs] [gedmurphy] 21413: update Wine sync doc
by Thomas Weidenmueller 31 Mar '06

31 Mar '06

aleksey(a)studiocerebral.com wrote: > -reactos/dll/win32/comctl32 # Synced to Wine-0_9_5 > +reactos/dll/win32/comctl32 # Synced to Wine-20060328 The "synchronization" lacks a bunch of changes. Only a few files were actually synchronized. - Thomas

2 1

Re: [ros-diffs] [tretiakov] 21409: Implement NdrCContextMarshall()
by Ged Murphy 30 Mar '06

30 Mar '06

These changes break second stage. CSR initialasation error. Ged. aleksey(a)studiocerebral.com wrote: > Author: tretiakov > Date: Wed Mar 29 23:09:43 2006 > New Revision: 21409 > > URL: http://svn.reactos.ru/svn/reactos?rev=21409&view=rev > Log: > Implement NdrCContextMarshall() > > Modified: > trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c > > Modified: trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c > URL: http://svn.reactos.ru/svn/reactos/trunk/reactos/dll/win32/rpcrt4/ndr_marsha… > ============================================================================== > --- trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c (original) > +++ trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c Wed Mar 29 23:09:43 2006 > @@ -3231,6 +3231,15 @@ > } > > /*********************************************************************** > + * NDRCContextMarshall > + */ > +void WINAPI NDRCContextMarshall(IN NDR_CCONTEXT CContext, OUT void *pBuff ) > +{ > + CContextHandle *ctx = (CContextHandle*)CContext; > + memcpy(pBuff, ctx->Ndr, sizeof(ctx->Ndr)); > +} > + > +/*********************************************************************** > * NdrClientContextMarshall > */ > void WINAPI NdrClientContextMarshall(PMIDL_STUB_MESSAGE pStubMsg, > > > >

1 1

RE: [ros-dev] Alpha workstation
by Michael Rich 29 Mar '06

29 Mar '06

> Hey if you wanted to part with the RS/6000 arty might be interested as > he has been doing a good bit on the powerpc port. His Mac just died > but he bought one of those nice IBM AIX Laptops that can run NT4 and > is working on that. Not quite ready to part with that thing yet. I'm having a house built, so I'll again have my own office, so I'll be able to hook it and the Alpha up via KVM on its own desk again. Part of the reason its packed up now is I'm living in a little tin can of a place in the meantime. > Yes it does. Would you like me to bring it down to you? Your in the > South East right? Yea I'm over in GA. If the machine has built in USB then that would be very handy to allow me to do some debugging on prebuilt hardware instead of sticking a generic USB card in there. I may actually be coming over to SC this weekend Laters, mike

1 0

RE: [ros-dev] Alpha workstation
by Michael Rich 29 Mar '06

29 Mar '06

Lol, you still have that Alpha machine. My PWS 433a is still sitting in my backroom where I wanted a port of ReactOS for so very long, but could never devote enough time to figuring the technical details out. Another interesting note is I still have the old RS/6000 that Eric and I were trying to get ROS to run on PPC too, however its packed up in the closet below my even older AlphaStation 4/233! Does your PWS433 have USB? My latest quest has been to hack USB support for AlphaNT, but thus far its not worked out very well, lol. Good Luck, Mike -----Original Message----- From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Steven Edwards Sent: Tuesday, March 14, 2006 2:42 PM To: ros-dev(a)reactos.org Subject: [ros-dev] Alpha workstation Hi, Is anyone in the US interested in using the Alpha workstation for a possible port? Its kind of gathering dust here and if no one wants it I would rather we just sell it and stick the money in to the project pot.

2 1

[Fwd: Re: [ros-diffs] peterw: 21369 - /trunk/reactos/CREDITS]
by Filip Navara 27 Mar '06

27 Mar '06

3 3

System for manual regression testing
by Maarten Bosma 25 Mar '06

25 Mar '06

Hi, I think ReactOS lacks of testers since WaxDragon is gone. So I had the following idea: A page which lists all regressions and gives you the option to report a working / non-working revision and calculates the range in which it the regression was caused from that data. I know that bugzilla comments are actually sufficient for this and of course this system would have to be linked with bugzilla, but I think that a page where the regressions are listed up would be more motivating to help testing. What do you think about it ? Best regards, Maarten Bosma

3 6

Mailing list ros-diffs
by Aleksey Bragin 25 Mar '06

25 Mar '06

Hello, A good news: ros-diffs mailing list has just been brought back to life, and now fully functioning. In order to see a colourful diff, please go to the url specified in the email, and to have a plaintext overview - just browse through the email. Have fun with it, Aleksey Bragin.

2 1

The WRK and what it means for ReactOS
by Alex Ionescu 21 Mar '06

21 Mar '06

Hi, Later this spring, Dave Probert's project will finally be complete with the realease of the WRK to academia, which means that almost any student such as I, Brandon, Filip, etc will have access to it. What is the WRK? The WRK (Windows Research Kernel) is Microsoft's answer to Linux/BSD source code used in classes. It is a special version of the NT Kernel designed to be used with the CRK (Windows NT Curriculum Kit) based on Windows Internals 4th Edition. It is a collection of about half a million lines of kernel code, including almost all of the process manager, object manager, thread scheduler, and other components discussed in the book. The PnP Manager, Power Subsystem, Kernel Debugger however are missing, as well as other specific code. This code is located in static libraries which are linked in at the end to create a complete kernel. What of the license? It is the reason why the WRK is so exciting and it's taken so long to come out (thank the lawyers). The license allows viewing, modifying and *creating derived work*, as long as any changes are also sent back to MS and that copyright is not misattributed. Additionnally, the license explicitly permits the creation of books or other reference material, including the presense of code snippets to better explain something, as well as sharing information in community forums. All this is allowed for any non-commercial or educational use, including personal research. The WRK also ships with Virtual PC, the build environment (similar to how we use QEMU/Dazzle for TinyKRNL) and full documentation for all the Native APIs. With such a wonderful thing at our disposal, how will this impact the kernel audit (postively)? What decisions do we take regarding the WRK? Do we use it? We can either use it entirely (ReactOS is, IIRC, an non-commercial research project, unless you still want to "vanquish the evil MS and sell millions"), but that would mean attributing copyright to Microsoft which many here would puke at. Alternatively, it can be used as pure documentation, which gives us all the freedom in the world. Or, we can be our true anti-MS/MS-bashing arrogants and call the WRK a heresy that should never be approached or used. Best regards, Alex Ionescu

6 9

The Future of the Desktop
by Rick Langschultz 21 Mar '06

21 Mar '06

Here are a few of my predictions of the future of the desktop. Having stepped back from the role of an internet developer in the past year I have been focusing more on the programming of binary executables. However, seeing the ever increasing change in desktop technology I am going to make a prediction of the future of executables in the operating system. My prediction is: binary executable software will no longer exist except for the underlying operating system. Instead the desktop will be a transparent web environment that will load AJAX applications and utilize web services to connect online data to desktop data. Also there will be minimum to no storage locally on the users desktop system, instead there will be online libraries filled with personal user data which will be in XML file formats, or other text-file based formats. This way a user can use a thumb print on the computer to access their personal data, and email on any computer in the world as well as in a variety of language formats. That is my prediction of the future of desktop systems of computer users.

7 7

RE: [ros-dev] The Future of the Desktop
by Murphy, Ged (Bolton) 21 Mar '06

21 Mar '06

Can we take this discussion off ros-dev please. ros-dev is reserved for issues directly related to ReactOS development. -----Original Message----- From: Ibrahim Damlaj [mailto:idamlaj@gmail.com] Sent: 21 March 2006 08:10 To: ReactOS Development List Subject: Re: [ros-dev] The Future of the Desktop Good point. However, I think that the reason that executables are going to be extinct is because computers are getting faster and faster. Therefore, the performance gain by using lower-level languages is becoming less and less, which is pushing many developers these days to use higher level (or interpreted) languages, which are simpler and faster to program in. Also, by using interpreted languages, the program does not need to be ported (as long as there is an interpreter for every platform). Therefore people tend to program in higher level (interpreted) languages On 3/21/06, Nate DeSimone <desimn(a)rpi.edu <mailto:desimn@rpi.edu> > wrote: Thank you for sharing that, however it is off topic. Rick Langschultz wrote: > Here are a few of my predictions of the future of the desktop. Having > stepped back from the role of an internet developer in the past year I > have been focusing more on the programming of binary executables. > However, seeing the ever increasing change in desktop technology I am > going to make a prediction of the future of executables in the > operating system. > > My prediction is: binary executable software will no longer exist > except for the underlying operating system. Instead the desktop will > be a transparent web environment that will load AJAX applications and > utilize web services to connect online data to desktop data. Also > there will be minimum to no storage locally on the users desktop > system, instead there will be online libraries filled with personal > user data which will be in XML file formats, or other text-file based > formats. This way a user can use a thumb print on the computer to > access their personal data, and email on any computer in the world as > well as in a variety of language formats. > > That is my prediction of the future of desktop systems of computer users. > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org <mailto:Ros-dev@reactos.org> > http://www.reactos.org/mailman/listinfo/ros-dev <http://www.reactos.org/mailman/listinfo/ros-dev> > > _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org <mailto:Ros-dev@reactos.org> http://www.reactos.org/mailman/listinfo/ros-dev <http://www.reactos.org/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

RE: [ros-dev] The WRK and what it means for ReactOS
by Murphy, Ged (Bolton) 20 Mar '06

20 Mar '06

Alex Ionescu wrote: > Alternatively, it can be > used as pure documentation, which gives us all the freedom in > the world. This would be the preferred method IMO. 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

Time for another change
by Steven Edwards 19 Mar '06

19 Mar '06

Hi All, I have decided to step down as Project Coordinator and would like to nominate Aleksey Bragin (Fireball) to run things in the interim until a new one is officially elected. At this time I cannot contribute the amount of effort needed to run the project during the audit and have many things going on as well. Fireball, Ged, GreatLord, Art and others have been doing a good job getting things on track and I think that given the current state of things we are going in the right direction. I am just no longer in a position to provide the kind of leadership needed. Aleksey has been doing a great job, getting the new SVN up, providing general direction and helping to resolve issues that have been coming up. He has also been working to establish a Foundation for the project in Russia and I think it would be best to move our legal and financial operations there. He will be setting up a donation system and I will be transfering the existing funds to him as well as filing the paperwork needed to shutdown US operations. I do not have the time required to try to continue to support the idea of a US Foundation at this point and I am not sure I believe we need it at this point. When I had the idea initially it was my hope that our progress would be much more rapid and our amount of donations and support from outside the project would be much higher. At this point I view my efforts on the project as being a successful failure. My ultimate goal when joining was to help make a Windows replacement/clone (call it what you will) and to see it be widely used. In saying that I believe it must be feature complete and dependable, both of which have not been meet yet. I believe they will be at some point but not during my time of being really active. In trying to reach that ultimate goal I have some short and long terms plans, most of which have been a success: US Foundation - (Failure) Goal help raise awareness of the project and provide assistance and legal representation to developers on the project. We have a good relationship with the Software Freedom Law Center and they have been kind enough to offer us advice however in terms of real legal help given the current state of the project thats not going to happen any time soon. Wine Cooperation - (Success) We share quite a lot of code with the Wine project and although it is hard as hell to get code in to Wine it has generally been a positive experience. The Wine tree contains hundreds if not thousands of minor fixes and features contributed by developers who have worked on both projects. Certain applications such as Taskmgr and Regedit were re-licensed by us and have been merged in to the Wine tree. Samba Cooperation - (Success) We have not fully ported samba however we have established a very positive relationship with the Samba and Samba-Tng developers and they seem very open to the idea of porting Samba to Windows so that in the future when ReactOS is ready it will provide a drop in solution. Elrond from Samba-tng has provided quite a bit of help and ported most of Samba-Tng to Windows already. Raising Awareness about ReactOS - (Success) When I joined no one had heard of us. Now almost any technical gathering I go to, 50 to 90% of the people attending are aware of our work. The GNU, Linux and BSD developers have for the most part changed their attitude regarding our project, its goals and future. Other uses of ReactOS - (Success) This has been the most surprising to me to watch. While we have not reached the ultimate goal we have seen fruits of our labor. The NDISWrapper teams come to us for questions which allows many Linux and BSD users to run Windows network card drivers. The CaptiveNTFS project created a more effective method of getting data from NTFS on to Linux. Many of the tools we have developed and ported are now being used in all sorts of places such as the FreeDOS port of command.com we reimplemented as cmd.exe has been ported to WinCE/PowerPC. Besides helping the NDISWrapper and Wine teams from time to time we are more and more becoming a source of information for educational purposes. So with all of that being said I am not planning on totally leaving however I mainly plan to help write regression tests for Wine in my spare time and hope that it helps ReactOS. I'm happy to help talk to people on behalf of the project and to help promote it in anyway I can. I think the next major thing I am going to try to do is visit Russia during a conference to meet with Fireball again and I am willing to continue to help mediate issues with Wine that may pop up. I still plan on hanging on IRC and the mailing list however I don't know how closely I will follow the list so if you need something email me directly. Thanks -- 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

6 5

r21332
by Alex Ionescu 18 Mar '06

18 Mar '06

> [10:24] <+CIA-9> mbosma * r21332 reactos/dll/directx/ddraw/ (7 files): Unlock ddraw dll. Maguns and I were the only authors and neither of us used > unclean methods to implement it. You're kidding right? I might as well unlock /ntoskrnl then. Best regards, Alex Ionescu

3 2

Putting MIDL output into svn repository.
by Saveliy Tretiakov 18 Mar '06

18 Mar '06

May I add some midl generated files into svn? (like we do with flex and bison) Lack of features in widl is a great stopper to ReactOS development. Actually, I can't do anything with event logging api because of widl. I want to inplment some rpcss functionality, but widl stops me from doing this.

3 6

Alpha workstation
by Steven Edwards 16 Mar '06

16 Mar '06

Hi, Is anyone in the US interested in using the Alpha workstation for a possible port? Its kind of gathering dust here and if no one wants it I would rather we just sell it and stick the money in to the project pot. Thanks -- 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

5 8

RE: [ros-dev] Wine sync
by Murphy, Ged (Bolton) 16 Mar '06

16 Mar '06

I've been planning to take over on the wine sync's, but have been waiting until I've finished setting up the audit process before looking into it. This is now in place as of a few days ago. I need to speak to Gé about a few things. -----Original Message----- From: Saveliy Tretiakov [mailto:saveliyt@mail.ru] Sent: 10 March 2006 07:33 To: ReactOS Development List Subject: [ros-dev] Wine sync We need a sync with wine :) Who can do it? Well, maybe I could do it myserlf, but I have very limited internet access... _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/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

11 21

dev blogging
by Ged Murphy 14 Mar '06

14 Mar '06

The following devs currently have a blog account set up. If any other devs want one setting up, please message me. Aleksey Bragin Alex Ionescu Andrew Munger Art Yerkes Casper Hornstrup Christoph von Wittich Gé van Geldorp Ged Murphy Hervé Poussineau kjkhyperion Klemens Friedl Maarten Bosma Magnus Olsen Mike Nordell Filip Navara Royce Mitchell III Steven Edwards Thomas Weidenmueller

1 0

Perl support in ROS
by Adam Kennedy 14 Mar '06

14 Mar '06

Hi there Just writing to enquire about the current state of Perl support in ROS (which I can't find any docs/information on) and to let you know that I and a few others are about to release a new non-ActiveState Win32 distribution of Perl, that is compiled with MinGW and is able to compile and install CPAN modules directly, rather than needing ActiveState's PPM library. At the moment I'm just weeding out the last Win32 bugs in the component parts of Bundle::CPAN, and awaiting a upgraded file installer that supports deleting or overwriting a file that is in use. With those in we'll release an initial beta, and after that the CPAN client should handle upgrading of any problems on the way to a production release. Would there be any interest in trying it out? Adam K

2 1

RE: [ros-dev] Wine sync
by Murphy, Ged (Bolton) 14 Mar '06

14 Mar '06

Eric Kohl wrote: > Hi! Hi Eric > I just started a three-week vacation and I'm upgrading my > computer right > now. My plan is to start porting WIDL this week. If you get chance to look at StartService too, I'll owe you beer or 3 ;) > PS: I think the WIDL source can be unlocked because it is > based on WINE > and the additional code was written by me, using IDL test > files and MIDL > from MSVC6. I agree. I think we need to draft up a process for unlocking code in the repository. The first port of call needs to be confirmation from the author. If the author confirms clean methods were utilised to write the code, it automatically fast tracks the audit. I know Arty has a good process for code which doesn't fall into this category. I'll try and get some sort of flowchart onto the wiki tonight. 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

3 2

RE: [ros-dev] Wine sync
by Murphy, Ged (Bolton) 14 Mar '06

14 Mar '06

Saveliy Tretiakov wrote: > > PS: I think the WIDL source can be unlocked because it is based on > > WINE and the additional code was written by me, using IDL > test files > > and MIDL from MSVC6. > > It is already unlocked. All code shared with wine is clean by default. That doesn't necessarily mean it's unlocked. With the exception of 1 or 2 folders, I locked everything in the repository regardless of what it was. Wine stuff will need to be unlocked as and when required. I think it's best to wait until we have a formal unlocking flowchart before we unlock any more code. There have already been 1 or 2 mistakes which we will now have to back-track. 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

Re: FAT patents again... Global and High Performance File Systems
by nitro2k01 13 Mar '06

13 Mar '06

Reminds me... didn't OS/2 have the capability to store both short and long file names on a FAT16 partiton? How does that go with MS' patents? Where MS really allowed to file a patent on something that already existed? /nitro2k01 On 3/10/06, Rick Langschultz <rlangschultz(a)cox.net> wrote: > I just have a question about High Performance and Global file systems > implementation in a ReactOS version? It would be wonderful to cluster > file systems on ReactOS. Also support for EFS would be great. Any > plans yet? > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -- -----BEGIN 2ROT13 MESSAGE----- The blog of nitro2k01: <http://soundandcomplete.blogspot.com/> Saliga äro de som kan stava till 2k01! Sniphpha sniphph! -----END 2ROT13 MESSAGE-----

5 5

Global and High Performance File Systems
by Rick Langschultz 10 Mar '06

10 Mar '06

I just have a question about High Performance and Global file systems implementation in a ReactOS version? It would be wonderful to cluster file systems on ReactOS. Also support for EFS would be great. Any plans yet?

1 0

RE: [ros-dev] Re: [ros-bugs] [Bug 1173] Greek Translation (rc fil es)
by Murphy, Ged (Bolton) 10 Mar '06

10 Mar '06

Saveliy Tretiakov wrote: > > James Tabor wrote: > > > I guess wine isn't taking any patch from ReactOS, even > something based > > on a rc file. > > Is this really true? Very sad :( > No, it isn't true. There will probably be a reason why the patch wasn't accepted. Wine have strict guidelines with regards to accepting patches. If a patch doesn't comply, it is dropped without a reply. 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

4 4

RE: [ros-dev] Re: locking files for the audit.
by Murphy, Ged (Bolton) 10 Mar '06

10 Mar '06

art yerkes wrote: > You need to own the lock first before removing the needs-lock > property. > do this like 'svn lock --force foo.c' If you break the lock first, there is then no problem removing the svn:needs-lock property as the file is unlocked. ************************************************************************ 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

Wine sync
by Saveliy Tretiakov 10 Mar '06

10 Mar '06

We need a sync with wine :) Who can do it? Well, maybe I could do it myserlf, but I have very limited internet access...

1 0

locking files for the audit.
by Ged Murphy 10 Mar '06

10 Mar '06

I have now started locking unaudited files in the repository. A special user called 'audit' has been created to do this lock. There are two reasons for this: 1. The user who locks the file can still commit without unlocking. Having a separate user to lock files removes this issue. 2. All developers can have the username and password for locking, providing a system wide user to lock files. (ask Fireball for the u/n & p/w) How do you lock files? I'll list the method for tortoise-svn via the GUI. Die hard cmd line gurus can adapt it to suit :) - Firstly, go into your tortoise-svn settings and on the general page, click 'clean now' for Subversion authentication data. This will remove your current u/n & p/w - To 'get a lock' on the file(s), right click the file / directory , navigate to tortoise-svn and select 'get lock'. Getting a lock will trigger svn to contact the server automatically and apply the lock. - Next pick the file / directory you just locked and right click. Select file properties and under the subversion tab add 'svn:needs-lock' from the combo box. Add a '*' for the value, check the recursive box and click set. This will ensure all locked files which are checked out are set as read only locally. This is just used as a handy reminder. - You can now commit the files which will add the svn:needs-lock property, however ensure that on the commit dialog, the 'keep locks' checkbox is selected otherwise it will remove the lock you just placed. Once I've audited the code, how do I unlock the files? This is done as your regular username, not as the 'audit' user, so you can clean the 'audit' username / password in the same manner as before if you opted to save it. Again, I'll list the tortoise method. - Right click on the file / directory you want to unlock, navigate to tortoiseSVN and select 'check for modifications' - Select the file(s) you want to unlock, right click and select 'break the lock'. SVN will automatically contact the repo and unlock the files. - Don't forget to remove the svn:needs-lock property from the files to ensure they are no longer checked out as read only. I have so far locked the kernel, however I'm unsure if : 1. we're just gonna lock everything in one go (this would make life easy to start with) and unlock everything as we deem it to be OK 2. lock only dirs we thing need auditing and unlock once clean. I personally prefer option 1 as it ensures we don't miss anything, and would probably be quicker in the long run. Regards, Ged.

3 4

Re: [ros-bugs] [Bug 1173] Greek Translation (rc files)
by James Tabor 08 Mar '06

08 Mar '06

Hi all! ReactOS.Bugzilla(a)reactos.org wrote: > http://www.reactos.org/bugzilla/show_bug.cgi?id=1173 > http://www.winehq.org/pipermail/wine-patches/2006-February/024643.html I guess wine isn't taking any patch from ReactOS, even something based on a rc file. Can't find it in their cvs logs. Yeah! There might be m$ source in that rc file!

2 1

ReactOS build problems...
by Neal Gompa 07 Mar '06

07 Mar '06

I downloaded the latest ReactOS SVN today, and I attempted to compile it with the RosBE. What happened was that the mingw32-make program shows this message: "makefile.auto:47549: *** missing separator. Stop."... Well, I figured that I got an incomplete build, so I reran TortoiseSVN and it said that I had the complete distribution... This should be fixed so that ReactOS will build, and if anyone is thinking... It occurs in all different building syntax... all, livecd, bootcd, install, depends, etc. fail with the same message...

3 4

RE: [ros-dev] Audit for non-code things?
by Murphy, Ged (Bolton) 05 Mar '06

05 Mar '06

Only WineMine is taken from Wine. Our Solitaire is a project Steven found and gained the authors permission to include it. TaskManager was written by Brian IIRC, for ReactOS. The notepad icon was taken from notepad2 which is GPL. It is assumed that anything from other GPL projects is legal and interchanagble. If there is a copyright issue, I can change it. -----Original Message----- From: theUser BL [mailto:theuserbl@hotmail.com] Sent: 02 March 2006 12:24 To: ros-dev(a)reactos.org Subject: [ros-dev] Audit for non-code things? I have tried out the SVN-Snapshot of ROS 3.0 by EmuandCo: http://www.reactos.org/forum/viewtopic.php?t=1741#14146 At first, I want to say, that the ReactOS-Explorer looks a lot of nicer. And some bugs are fixed. Nice work. Then I have looked at the program-icons. sol.exe and winefile.exe seems to use icons from old Windows-Versions (Windows 3.x/95/98/NT4). And with taskmgr.exe I am not sure, if the icon is from Windows or at own designed. All three programs comming from WINE and not from ReactOS. But is legal to using it? More woders me the new ReactOS Notepad. If you click on Help -> About, then there opens a window where stands: Icon borrowed from Notepad2 - http://www.flos-freeware.ch/notepad2.html But Notepad2 have borrowed it from Microsofts WindowsXP Notepad. It is funny to see, how the original creater of the icon, isn't named - but instead of it, an other one is named. But the program notepad++ (http://notepad-plus.sourceforge.net/) is OpenSource (GPL) and thats icon you could be used. After that, I looked with Microsofts fontview.exe (the program is part of every MS-Windows) in the text inside the fonts of ROS. There are copyrighted fonts by Adobe, Bitstream, IBM, Sun and Transgaming. And there are some Bitstream fonts in which stands: Copyright 1990 as an unpublished work by Bitstream Inc. All rights reserved. Confidential. Confidential? Unpublished? From where comes then the fonts? The fonts in which this stand are c0419bt_.ttf, c0582bt_.ttf, c0583bt_.ttf, c0611bt_.ttf, c0632bt_.ttf, c0633bt_.ttf, c0648bt_.ttf and c0649bt_.ttf. Ok, the Copyright is from 1990 (for 16 years!), but is it legal to use this fonts? Instead you could use the following fonts: http://dejavu.sourceforge.net/ http://linuxlibertine.sourceforge.net/ http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=Gentium_lin ux&_sc=1 Greatings theuserbl _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/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

4 3

compilation problems :(
by Felipe Villarroel 05 Mar '06

05 Mar '06

Hi everybody!!!!!, i'm trying to compile ReactOS SVN 0.3 but i'm having problems. I'm currently using the ReactOS Build Enviroment 0.1-3.4.2 but it is unable to compile rbuild. In fact the compilation process stops at linking rbuild.exe. I have created a directory in my D drive (rossrc) and i have downloaded from the SVN the sources in d:\rossrc\trunk. So i changed the directory to d:\rossrc\trunk\reactos and executed mingw32-make. Then it began compiling the sources and after a while it stops with a lot of garbage: [LD] output-i386\tools\rbuild\rbuild.exe plus lots of errors about undefined resources that i put at the end of this email. I currently reinstalled the Build Enviroment hoping that something was installed wrong o was wrongly configured. But the same results appeared. I also tried to compile it under the administration account, because i currently run as user, but there are no changes whatsoever (just trying to check that it isn't my fault or my incompetence :P). I blame the linker for this problem, but i don't know what is wrong with it, because its a known fact that some versions of binutils dont work but clearly RosBE has been tested a lot. thanks in advance, Logan_V8 PS: Garbage output from the linker obj-i386\tools\rbuild\backend\msvc\msvcmaker.o: In function `ZSt11__copy_aux2IPS sS0_ET0_T_S2_S1_12__false_type': D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_alg obase.h:(.text$_ZNSt23_Rb_tree_const_iteratorISsEppEi[std::_Rb_tree_const_iterat or<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >::ope rator++(int)]+0x1b): undefined reference to `std::_Rb_tree_increment(std::_Rb_tr ee_node_base const*)' D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_alg obase.h:(.text$_ZNSt8_Rb_treeISsSsSt9_IdentityISsESt4lessISsESaISsEE9_M_insertEP St18_Rb_tree_node_baseS7_RKSs[std::_Rb_tree<std::basic_string<char, std::char_tr aits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<cha r>, std::allocator<char> >, std::_Identity<std::basic_string<char, std::char_tra its<char>, std::allocator<char> > >, std::less<std::basic_string<char, std::char _traits<char>, std::allocator<char> > >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::_M_insert(std::_Rb_tree_node _base*, std::_Rb_tree_node_base*, std::basic_string<char, std::char_traits<char> , std::allocator<char> > const&)]+0x99): undefined reference to `std::_Rb_tree_i nsert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, st d::_Rb_tree_node_base&)' D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_alg obase.h:(.text$_ZNSt17_Rb_tree_iteratorISsEmmEv[std::_Rb_tree_iterator<std::basi c_string<char, std::char_traits<char>, std::allocator<char> > >::operator--()]+0 x13): undefined reference to `std::_Rb_tree_decrement(std::_Rb_tree_node_base*)' obj-i386\tools\rbuild\backend\msvc\vcprojmaker.o: In function `ZNSt24__copy_back ward_dispatchIPPK10IfableDataS3_11__true_typeE4copyEPKS2_S7_S3_': D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_alg obase.h:(.text$_ZNSt17_Rb_tree_iteratorISsEppEi[std::_Rb_tree_iterator<std::basi c_string<char, std::char_traits<char>, std::allocator<char> > >::operator++(int) ]+0x1b): undefined reference to `std::_Rb_tree_increment(std::_Rb_tree_node_base *)' D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_alg obase.h:(.text$_ZNSt8_Rb_treeISsSsSt9_IdentityISsESt4lessISsESaISsEE5eraseESt17_ Rb_tree_iteratorISsE[std::_Rb_tree<std::basic_string<char, std::char_traits<char > , std::allocator<char> >, std::basic_string<char, > std::char_traits<char>, std:: allocator<char> >, std::_Identity<std::basic_string<char, std::char_traits<char> , std::allocator<char> > >, std::less<std::basic_string<char, std::char_traits<c har>, std::allocator<char> > >, std::allocator<std::basic_string<char, std::char _traits<char>, std::allocator<char> > > >::erase(std::_Rb_tree_iterator<std::bas ic_string<char, std::char_traits<char>, std::allocator<char> > >)]+0x17): undefi ned reference to `std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base*, st d::_Rb_tree_node_base&)' D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_alg obase.h:(.text$_ZNSt17_Rb_tree_iteratorISsEppEv[std::_Rb_tree_iterator<std::basi c_string<char, std::char_traits<char>, std::allocator<char> > >::operator++()]+0 x13): undefined reference to `std::_Rb_tree_increment(std::_Rb_tree_node_base*)' obj-i386\tools\rbuild\backend\backend.o: In function `ZNSt8_Rb_treeISsSt4pairIKS sPN7Backend7FactoryEESt10_Select1stIS5_ESt4lessISsESaIS5_EE8_S_valueEPKSt13_Rb_t ree_nodeIS5_E': D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/ext/new_allo cator.h:(.text$_ZNSt8_Rb_treeISsSt4pairIKSsPN7Backend7FactoryEESt10_Select1stIS5 _ESt4lessISsESaIS5_EE9_M_insertEPSt18_Rb_tree_node_baseSD_RKS5_[std::_Rb_tree<st d::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair< std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, Ba ckend::Factory*>, std::_Select1st<std::pair<std::basic_string<char, std::char_tr aits<char>, std::allocator<char> > const, Backend::Factory*> >, std::less<std::b asic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocat or<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char > > const, Backend::Factory*> > > >::_M_insert(std::_Rb_tree_node_base*, std::_Rb_ tree_node_base*, std::pair<std::basic_string<char, std::char_traits<char>, std:: allocator<char> > const, Backend::Factory*> const&)]+0x99): undefined reference to `std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_ tree_node_base*, std::_Rb_tree_node_base&)' D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/ext/new_allo cator.h:(.text$_ZNSt17_Rb_tree_iteratorISt4pairIKSsPN7Backend7FactoryEEEmmEv[std ::_Rb_tree_iterator<std::pair<std::basic_string<char, std::char_traits<char>, st d::allocator<char> > const, Backend::Factory*> >::operator--()]+0x13): undefined reference to `std::_Rb_tree_decrement(std::_Rb_tree_node_base*)' obj-i386\tools\rbuild\automaticdependency.o: In function `ZNSt8_Rb_treeISsSt4pai rIKSsP10SourceFileESt10_Select1stIS4_ESt4lessISsESaIS4_EE14_M_create_nodeERKS4_' : D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_tre e.h:(.text$_ZNSt17_Rb_tree_iteratorISt4pairIKSsP10SourceFileEEppEi[std::_Rb_tree _iterator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocat or<char> > const, SourceFile*> >::operator++(int)]+0x1b): undefined reference to `std::_Rb_tree_increment(std::_Rb_tree_node_base*)' D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_tre e.h:(.text$_ZNSt8_Rb_treeISsSt4pairIKSsP10SourceFileESt10_Select1stIS4_ESt4lessI SsESaIS4_EE9_M_insertEPSt18_Rb_tree_node_baseSC_RKS4_[std::_Rb_tree<std::basic_s tring<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::basic _string<char, std::char_traits<char>, std::allocator<char> > const, SourceFile*> , std::_Select1st<std::pair<std::basic_string<char, std::char_traits<char>, std: :allocator<char> > const, SourceFile*> >, std::less<std::basic_string<char, std: :char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basi c_string<char, std::char_traits<char>, std::allocator<char> > const, SourceFile* > > >::_M_insert(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, > std::pair<s td::basic_string<char, std::char_traits<char>, std::allocator<char> > const, Sou rceFile*> const&)]+0x99): undefined reference to `std::_Rb_tree_insert_and_rebal ance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_nod e_base&)' D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_tre e.h:(.text$_ZNSt17_Rb_tree_iteratorISt4pairIKSsP10SourceFileEEmmEv[std::_Rb_tree _iterator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocat or<char> > const, SourceFile*> >::operator--()]+0x13): undefined reference to `s td::_Rb_tree_decrement(std::_Rb_tree_node_base*)' obj-i386\tools\rbuild\directory.o: In function `ZNSt8_Rb_treeISsSt4pairIKSsP9Dir ectoryESt10_Select1stIS4_ESt4lessISsESaIS4_EE14_M_create_nodeERKS4_': D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/ext/new_allo cator.h:(.text$_ZNSt17_Rb_tree_iteratorISt4pairIKSsP9DirectoryEEppEv[std::_Rb_tr ee_iterator<std::pair<std::basic_string<char, std::char_traits<char>, std::alloc ator<char> > const, Directory*> >::operator++()]+0x13): undefined reference to ` std::_Rb_tree_increment(std::_Rb_tree_node_base*)' D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/ext/new_allo cator.h:(.text$_ZNSt8_Rb_treeISsSt4pairIKSsP9DirectoryESt10_Select1stIS4_ESt4les sISsESaIS4_EE9_M_insertEPSt18_Rb_tree_node_baseSC_RKS4_[std::_Rb_tree<std::basic _string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::bas ic_string<char, std::char_traits<char>, std::allocator<char> > const, Directory* > , std::_Select1st<std::pair<std::basic_string<char, > std::char_traits<char>, std ::allocator<char> > const, Directory*> >, std::less<std::basic_string<char, std: :char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basi c_string<char, std::char_traits<char>, std::allocator<char> > const, Directory*> > >::_M_insert(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::pair<st d::basic_string<char, std::char_traits<char>, std::allocator<char> > const, Dire ctory*> const&)]+0x99): undefined reference to `std::_Rb_tree_insert_and_rebalan ce(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_ base&)' D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/ext/new_allo cator.h:(.text$_ZNSt17_Rb_tree_iteratorISt4pairIKSsP9DirectoryEEmmEv[std::_Rb_tr ee_iterator<std::pair<std::basic_string<char, std::char_traits<char>, std::alloc ator<char> > const, Directory*> >::operator--()]+0x13): undefined reference to ` std::_Rb_tree_decrement(std::_Rb_tree_node_base*)' obj-i386\tools\rbuild\rbuild.o: In function `ZNSt3mapISsPN7Backend7FactoryESt4le ssISsESaISt4pairIKSsS2_EEE3endEv': D:/RosBE/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/stl_map .h:(.text$_ZNSt17_Rb_tree_iteratorISt4pairIKSsPN7Backend7FactoryEEEppEi[std::_Rb _tree_iterator<std::pair<std::basic_string<char, std::char_traits<char>, std::al locator<char> > const, Backend::Factory*> >::operator++(int)]+0x1b): undefined r eference to `std::_Rb_tree_increment(std::_Rb_tree_node_base*)' obj-i386\tools\ssprintf.o:ssprintf.cpp:(.text$_ZNSbIwSt11char_traitsIwESaIwEE4_R ep10_M_disposeERKS1_[std::basic_string<wchar_t, std::char_traits<wchar_t>, std:: allocator<wchar_t> >::_Rep::_M_dispose(std::allocator<wchar_t> const&)]+0x22): u ndefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)' collect2: ld returned 1 exit status mingw32-make: *** [output-i386\tools\rbuild\rbuild.exe] Error 1 -- _______________________________________________ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze

1 0

Audit for non-code things?
by theUser BL 03 Mar '06

03 Mar '06

I have tried out the SVN-Snapshot of ROS 3.0 by EmuandCo: http://www.reactos.org/forum/viewtopic.php?t=1741#14146 At first, I want to say, that the ReactOS-Explorer looks a lot of nicer. And some bugs are fixed. Nice work. Then I have looked at the program-icons. sol.exe and winefile.exe seems to use icons from old Windows-Versions (Windows 3.x/95/98/NT4). And with taskmgr.exe I am not sure, if the icon is from Windows or at own designed. All three programs comming from WINE and not from ReactOS. But is legal to using it? More woders me the new ReactOS Notepad. If you click on Help -> About, then there opens a window where stands: Icon borrowed from Notepad2 - http://www.flos-freeware.ch/notepad2.html But Notepad2 have borrowed it from Microsofts WindowsXP Notepad. It is funny to see, how the original creater of the icon, isn't named - but instead of it, an other one is named. But the program notepad++ (http://notepad-plus.sourceforge.net/) is OpenSource (GPL) and thats icon you could be used. After that, I looked with Microsofts fontview.exe (the program is part of every MS-Windows) in the text inside the fonts of ROS. There are copyrighted fonts by Adobe, Bitstream, IBM, Sun and Transgaming. And there are some Bitstream fonts in which stands: Copyright 1990 as an unpublished work by Bitstream Inc. All rights reserved. Confidential. Confidential? Unpublished? From where comes then the fonts? The fonts in which this stand are c0419bt_.ttf, c0582bt_.ttf, c0583bt_.ttf, c0611bt_.ttf, c0632bt_.ttf, c0633bt_.ttf, c0648bt_.ttf and c0649bt_.ttf. Ok, the Copyright is from 1990 (for 16 years!), but is it legal to use this fonts? Instead you could use the following fonts: http://dejavu.sourceforge.net/ http://linuxlibertine.sourceforge.net/ http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=Gentium_li… Greatings theuserbl

5 8

RE: [ros-dev] Audit for non-code things?
by Ge van Geldorp 03 Mar '06

03 Mar '06

> From: art yerkes > > No we imported X fonts where permitted and used TGMarlett for > window titles (also permitted, see media/fonts/doc) Executive summary: There's no problem with the fonts. Details: Jason imported helb___.ttf and timr____.ttf in r1877 from OpenOffice (LGPL, so GPL compatible). I imported the Bitstream Vera fonts (Vera.ttf, VeraBI.ttf, VeraBd.ttf, VeraIt.ttf, VeraMoBI.ttf, VeraMoBd.ttf, VeraMoIt.ttf, VeraMono.ttf, VeraSe.ttf, VeraSeBd.ttf) in r4689. They are covered by the license in media/fonts/doc/VERA-COPYRIGHT.TXT. Steven imported TGMarlett.ttf in r9427. The "TG" refers to Trans Gaming. The font is under a X11 license (see http://www.transgaming.com/gamefaq.php?specialid=3 under 6.2) which is GPL compatible. Art imported some of the X fonts (UTBI____.ttf, UTB_____.ttf, UTI_____.ttf, UTRG____.ttf, c0419bt_.ttf, c0582bt_.ttf, c0583bt_.ttf, c0611bt_.ttf, c0632bt_.ttf, c0633bt_.ttf, c0648bt_.ttf, c0649bt_.ttf, cour.ttf, courb.ttf, courbi.ttf ) in r10143. These are covered by the licenses in media/fonts/doc/COPYRIGHT.IBM and media/fonts/doc/Copyright.Bitstream. GvG

1 0

Re: [ros-bugs] [Bug 1327] New: Scrambled output from Calculator
by Brandon Turner 02 Mar '06

02 Mar '06

ReactOS.Bugzilla(a)reactos.org wrote: >http://www.reactos.org/bugzilla/show_bug.cgi?id=1327 > > Summary: Scrambled output from Calculator > Product: ReactOS Apps (rosapps) > Version: unspecified > Platform: x86 Hardware > OS/Version: ReactOS > Status: NEW > Severity: normal > Priority: P3 > Component: Utilities > AssignedTo: ros-bugs(a)reactos.org > ReportedBy: the_real_martian(a)msn.com > QAContact: ros-bugs(a)reactos.org > > >When using Calculator, it will have outputs such as 308-d or 0770777-ff. This >happens when it is set to "Dec", not Hex > > > Does this happen on both ROS and Windows or just ROS? Can you reproduce it everytime with certain steps? And this isnt really considered ROS Apps I dont think since Calc.exe is in /reactos. Brandon

2 2

Re: [ros-bugs] [Bug 1328] New: Alt+Tab has no effect
by Brandon Turner 02 Mar '06

02 Mar '06

ReactOS.Bugzilla(a)reactos.org wrote: >http://www.reactos.org/bugzilla/show_bug.cgi?id=1328 > > Summary: Alt+Tab has no effect > Product: ReactOS > Version: 0.2.9 > Platform: x86 Hardware > OS/Version: ReactOS > Status: NEW > Severity: normal > Priority: P3 > Component: Kernel > AssignedTo: ros-bugs(a)reactos.org > ReportedBy: the_real_martian(a)msn.com > QAContact: ros-bugs(a)reactos.org > > >In Windows, Alt-Tab usually allows switching between open Windows. Alt-Tab has >no effect in ReactOS > > > There is a hotkey meta bug please make this a dependency . Brandon

1 0

Re: [ros-bugs] [Bug 1326] New: Ctrl+Alt+Del has no effect
by Brandon Turner 02 Mar '06

02 Mar '06

ReactOS.Bugzilla(a)reactos.org wrote: >http://www.reactos.org/bugzilla/show_bug.cgi?id=1326 > > Summary: Ctrl+Alt+Del has no effect > Product: ReactOS > Version: 0.2.9 > Platform: x86 Hardware > OS/Version: ReactOS > Status: NEW > Severity: normal > Priority: P3 > Component: Kernel > AssignedTo: ros-bugs(a)reactos.org > ReportedBy: the_real_martian(a)msn.com > QAContact: ros-bugs(a)reactos.org > > >When Ctrl+Alt+Del is pressed, there is no effect. This can really get annoying >if a program is not responding, and you have to right-click the taskbar to open >Task Manager. > > > There is a hotkey meta bug please make this a dependency . Brandon

1 0

Feature Request: Intel EFI support
by Rick Langschultz 27 Feb '06

27 Feb '06

I was wondering if there was any plan on implementing Intel's EFI in the near or distant future. I hear that Intel wants to move away from BIOS and work more closely with EFI. I know that support for the BIOS will never totally disappear but EFI is a better architecture in my opinion. So here is my request for EFI support in ReactOS.

7 10

Re: [ros-bugs] [Bug 390] Freeloader Execption: DIVIDE BY ZERO
by Jerry 24 Feb '06

24 Feb '06

I had this same problem when developing my bootsector. When I reset the bootdrive before I jumped to freeldr the problem went away. I think that the first thing that freeldr needs to is to reset the boot drive before it moves on. ReactOS.Bugzilla(a)reactos.org wrote: > http://www.reactos.org/bugzilla/show_bug.cgi?id=390 > > > > > > ------- Additional Comments From simona(a)informatik.tu-muenchen.de 2006-02-25 00:17 CET ------- > got the same problem with the boot cd 2.9 on a travelmate 290. > shoud be the same hardware and the same crappy "insyde software" bios (v2.0 on > my chip): > Press any key to boot from CD <enter> > > Failed to read the PVD. > Press any key > Failed to read the super block. > Press any key <enter> > Failed to read boot sector. > Press any key <enter> > Failed to read boot sector. > Press any key <enter> > Unable to locate boot parition > > Press any key <enter> > Error opening boot partition for file access. <enter> > > Press any key to boot from CD > > And so on... > Notice that one time the any-key message appears without waitig for any key. > > And, after the first "round" it waits way shorter for any keypress to boot > from CD (the time between two dots printed has decreased). > I experienced this problem with the first LiveCD version i tried (2.0 i > think). > >

5 8

RE: [ros-dev] Re: Vote: code auditing
by Murphy, Ged (Bolton) 24 Feb '06

24 Feb '06

Brandon Turner wrote > > " B - Sections of ReactOS which require auditing are > 'locked', that being > that the source is fully available to download and build, but no > development work should be undertaken until the said code has > passed the > audit. The lock will be removed only when that section of > code has been > audited." > > I have asked 3-4 times but still havent got an answer as far > as I can tell. Does the definition of "audit" in the pharse > mean the code needs to be looked through and documented and > bad code be marked. Or does it mean all that and the marked > code needs to be rewritten for it to be considered "audited". Here is my understanding (although I'm not saying it's correct) First of all, we must take the authors word on whether something needs auditing or not. If a particular author says the code which he wrote is clean, then this automatically bypasses the audit. This clears up James' worry about his dll code which he has declared clean. If an author can't be contacted, it is classes as unknown and must go through the audit process. Once we have a list of all code which has not been verified, a new SVN user is generated and he is used to lock all the code (this is done with a separate user to avoid certain features of SVN lock) Any developer is able to remove a lock. Locking the code only really acts as a reminder that the code has not passed an audit. This code shouldn't be modified / improved until it has done so. The lock therefore ensures all the code is audited and nothing is missed. It also acts as an incentive to get the code audited. Without the lock, I think it will be conveniently forgotten about..... Once code has been locked how does it get out of locked status? I think there are 3 possibilities: - look through the code looking for anything even remotely strange. (I think Alex's description which I have linked to the end of this mail makes some good points). If all the code seems perfectly legitimate, it passes the audit and the lock is removed. - If code doesn't seem legitimate, search for documentation. If docs are found to cater for all the questionable code, the docs are added and the code passes audit. - If the code doesn't seem legitimate and docs can't be found, then the code is deemed dirty and further action must be taken (e.g. part of the code rewritten, all the code rewritten, docs written, etc). This would have to be discussed at greater length. HTH 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

Vote: code auditing
by Ged Murphy 24 Feb '06

24 Feb '06

Vote topic : Ensure code auditing is carried out Start date : 16/02/06 Period : 7 days discussion, 7 days voting With the success of proposal B in the recent vote and the old repository reopening for business, we need to discuss ways to ensure the code is audited and doesn't take a backseat. Following the correct voting procedure, there will be a 7 day discussion period, followed by a 7 day voting period. Until this decision is made, I propose for the repository to be fully open, with developers being diligent with their actions. This topic has been discussed somewhat between developers, although not extensively. Two viable proposals have so far been put forward and are as follows : A - The repository is completely open to all development and ReactOS developers must take it upon themselves to ensure all code is audited. B - Sections of ReactOS which require auditing are 'locked', that being that the source is fully available to download and build, but no development work should be undertaken until the said code has passed the audit. The lock will be removed only when that section of code has been audited. Discussion of these topics and any further proposals should be in reply to this topic.

6 9

Audit documentation
by art yerkes 23 Feb '06

23 Feb '06

How do we feel about having the documentation directory from the casper tree (the one where audit documentation is being written) moved to svn://svn.reactos.ru/reactos/trunk/documentation? -- Discordant is the murmur at such treading down of lovely things while god's most lordly gift to man is decency of mind. Call that man only blest who has in sweet tranquility brought his life to close. If only I could act as such, my hope is good. -- Aeschylus' Agamemnon (translated by H. W. Smyth)

3 2

Boomerang
by theUser BL 23 Feb '06

23 Feb '06

At http://www.reactos.org/pipermail/ros-dev/2006-February/007878.html and on other places there is mentioned, that the way to audit is, to look at the ReactOS-Source-Code, look if it looks understandable. The problem is, that is possible, that people disasseble MS-Windows-code and port then the Assembler-Code in stupid C code. And - because (not clean room) reverse engineering isn't allowed - all code, which looks stupd will be eliminated. That was also discussed in a german forum. There someone have at http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=9920469&forum_i… discribed, how a normal C program can be compiled to assebler code and an other people create stupied C code, where you can see, that it was reverse engineered. But in the same forum, someone have mentioned, that there existing decompiler like Boomerang http://boomerang.sourceforge.net/ which creates from binary code logical, easy to read C code. (Don't know before, that something like this exists). Have a look at http://boomerang.sourceforge.net/cando.php I want with this mail only to say, that it would be very hard to find the reverse engineered code (if there existing one). Greatings theuserbl

2 1

Re: [ros-svn] [martinf] 116: fix build with _ROS_ define
by James Tabor 21 Feb '06

21 Feb '06

martinf(a)svn.reactos.org wrote: > fix build with _ROS_ define > > > Updated files: > trunk/reactos/base/shell/explorer/shell/mainframe.cpp > Hi, Should you move your changes to the new svn? Thanks, James

1 1

Virtual Encrypted File System (VEFS)
by Rick Langschultz 20 Feb '06

20 Feb '06

Through an intriguing article on Slashdot I have read that ipods are now being used for things other than audio. They are being used to obtain data from a computer, and computer network obtaining business documents and such in seconds. One way to make ReactOS a safer operating environment is to use a virtual encrypted file system that would restrict the copying of files to any usb, or network device via an encryption algorithm. So I propose a VEFS that would restrict this. The VEFS would disallow the passage of documents to any removable device unless the user has permission to archive them, which would be the "a" attribute. The VEFS would make use of two AES encryption algorithms which would encrypt the file's contents. One being a key another a lock, however the user must provide a password to unlock and decrypt the files. This would allow the user to unlock the files, only if they have the password. This would also allow users to secure their personal and corporate data. Any ideas?

3 2

Project Status (Haiku Style)
by Rick Langschultz 19 Feb '06

19 Feb '06

Has anyone looked at the Haiku Project lately. There hasn't been much change in status but I do think the status page has a great graph that reactos should implement. http://haiku-os.org/learn.php? mode=status&haikuusersession=80b7ab5450deadb0c18c136376ee33d0

1 0

Fw: change script
by art yerkes 18 Feb '06

18 Feb '06

This is a script you can use to switch your current repository to the new one. It won't save much dl time at this point, but might help. It's experimental, and it might claim that some directories 'already exist'. If so, you have to delete the old version of the directory. Of course, you'll be able to get your diffs out by doing svn diff on those directories beforehand. In any case, use with caution. run like this python change-repo.py <reactos-dir> svn://svn.reactos.com/trunk/reactos svn://svn.reactos.ru/reactos/trunk/reactos 97493ccd-5924-5043-b1f5-66cb403b36ce -- Discordant is the murmur at such treading down of lovely things while god's most lordly gift to man is decency of mind. Call that man only blest who has in sweet tranquility brought his life to close. If only I could act as such, my hope is good. -- Aeschylus' Agamemnon (translated by H. W. Smyth) -- Discordant is the murmur at such treading down of lovely things while god's most lordly gift to man is decency of mind. Call that man only blest who has in sweet tranquility brought his life to close. If only I could act as such, my hope is good. -- Aeschylus' Agamemnon (translated by H. W. Smyth)

3 2

Attention ReactOS Developers -- SVN server
by Aleksey Bragin 18 Feb '06

18 Feb '06

Hello! As for recent changes with SVN repository hosting, the active ReactOS repository now is being placed on svn://svn.reactos.ru/reactos. I thought it would be wise not to copy passwords from the old repository, so All developers with commit access, please send me your exact matching svn commit name (though I can look it up easily of course ;-)) and a password you would like to use in the repository. Right now there is only directory/files moving operations are going, without any features being added or deleted until the voting on files- locks in SVN for non-audited parts will be resolved. This doesn't touch modules which are clean apriori - like rbuild for example. Thank you, Aleksey Bragin.

5 7

RE: [ros-dev] very confused
by rené Tournois 18 Feb '06

18 Feb '06

At 15:11 17/02/2006 -0000, you wrote: I apologize for this second intrusion, but i have some difficulties to really understand this: >Define 'MS code'. If we're talking about leaked source code, then that is >true. But you said elsewhere that there was _no_ leaked source, so that the only problem should be with your next words: >If we're talking about small chunks of assembly from dissasembled MS >binaries, then that is what the audit hopes to uncover and remove. Once the >audit is complete, we can also say we know this to be true, at the moment we >don't know. ... and this one sounds strange to me, because i saw several messages talking in terms of *year* (?!), for the audit. Well, i just downloaded the ReactOS Sources, and searched for all the Files having an "__asm__" Statements inside, after having saved in a dedicated Directory, the folders: bootdata / Drivers / hal / include / lin / media / modules / ntoskrnl / regtests / services / subsys and win32api. I did not considered the other ones because, for example, i suppose that there can be no "problem" with the [apps] Folder. ;) The search of the Files with "_asm_" inside shows only around 80 Files found. Opening several of these Files, shows that the occurencies of "_asm_" seem to be from 1 to, say, 10. Most usually around 2 or 3. It also shows that many of these Statements cannot be any problem. Example: { __asm__("int $3\n\t" : /* no outputs */ : /* no inputs */) } Some other ones, a little bit more significative look like, for example: __asm { mov edx, Port mov edi, Buffer mov ecx, Count cld rep ins byte ptr[edi], dx } ... that do not seem to me big enough for demonstrating anything, particulary not for a so trivial code... Not considering that most of the ones i saw, were simple LOCK or INT instructions, and the like, that do not even diserve a reading. I did not search inside _all_ files, but i had to search inside many, (say, 1/3), before i could point out an Asm Routine with more than 10 Instructions... I stopped there, because i said to me that it was stupid to read that way, and that i was possibly missing the Files of real interrest for the Audit. But all i have seen does not explain to me, how it could ever take one year for proof-reading so few, and so small, "__asm__" statements. What am i missing? Betov. < http://rosasm.org >

6 5

very confused
by theUser BL 17 Feb '06

17 Feb '06

Hi! I am now very confused. It seems for me, that the current informations about ReactOS´s situation is poor. And if there existing informations, they are IMHO contradictorily. On 27.1.2006 Steven Edwards wrote "Reset, Reboot, Restart, legal issues and the long road to 0.3" http://www.reactos.org/xhtml/de/news_page_14.html In this text there is no word about leaked Windows-code. So it seems, that the main problem is revers engineering, which is not clean room rev. eng. One day later a developer says in the forum http://www.reactos.org/forum/viewtopic.php?p=13239&highlight=#13239 "The biggest problem isn't disassembled code. The fact is that 4 of the developers have had a copy of the leaked Windows source." So, the biggest problem is, that some ROS-developer have looked in leaked code. He have said that, and nobody have contradicted it. But at http://www.reactos.org/archives/public/ros-dev/2006-February/007832.html a developer says to me "The leaked source code was never an issue here, that was an escalation of the mail which was posted on the public list. The rumours which materialized from that were unfounded and untrue." and the cvs tree will be completly re-opend. In an other mail, I don't find it at the moment, anybody says, that there is still no Microsoft-Code found in ROS. All is clean. On the following http://www.reactos.org/pipermail/ros-dev/2006-February/007717.html a developer says "I am told that the sources for FreeLdr are all okay, except for the some of the bootsectors having been pretty much just disassembled from MS's. Is this true?" The answer comes from an other developer http://www.reactos.org/pipermail/ros-dev/2006-February/007722.html "crashfourit has posted a patch here:" That means, that it is possible, that MS-bootsector-code have found the way in ROS, if I understood it right. And at http://www.reactos.org/archives/public/ros-general/2006-February/002128.html somebody cite something where a Codewaever chef says, that in ROS is stolen code. I have at the current no links, but I have the feeling, that there existing a lot of more comments like these, which me all confused very much. And then ReactOS gives for me more questions then answers. What does the Audit-process mean? You have - as somebody says - already seen, that no Windows-Code is in ReactOS. But you want with the audit look for code, which are integrated by (not clean room) reverse engineering. But how do you want to find it? The clean room inverse enginering is like re-writing an existing book, without reading the existing book itself. Only reading review, critiques and summaries about the book are alowed to read. But there existing some people who have reverse enginered, but not clean room. This is like someone, who have completly read the book itself and tries to write the book what he read then down in mind. But how do you want to become out, who have read the original book and who not? Steve Edwars have written "and the long road to 0.3". Is it still true, that it needs now longer, until 0.3 comes out? The tree will already be opend. Does it mean, that 0.3 comes only after the end of the audit-progess out? If this is true, comes then before the end of the audit other releases out (0.2.10, 0.2.11, .... etc) ? You see. I am very confused. I don't expect that you answer to my mail here. I only want, that your public clarification, http://www.reactos.org/archives/public/ros-dev/2006-February/007832.html Murphy have written "The whole tree will be reopened in the state it was in before it closed. More details will follow when this happens.", will really clarify all. So that no longer confuseness for anyone exists. Greatings theuserbl

4 3

RE: [ros-dev] very confused
by Murphy, Ged (Bolton) 17 Feb '06

17 Feb '06

theUser BL wrote: > I am now very confused. I'll try and clear some other areas up for you. I don't have web access at the moment, so I am only going off what you have pasted under the links. > On 27.1.2006 Steven Edwards wrote "Reset, Reboot, Restart, > legal issues and > the long road to 0.3" > http://www.reactos.org/xhtml/de/news_page_14.html > > In this text there is no word about leaked Windows-code. So > it seems, that > the main problem is revers engineering, which is not clean > room rev. eng. Correct. > One day later a developer says in the forum > http://www.reactos.org/forum/viewtopic.php?p=13239&highlight=#13239 > "The biggest problem isn't disassembled code. The fact is > that 4 of the > developers have had a copy of the leaked Windows source." > > So, the biggest problem is, that some ROS-developer have > looked in leaked > code. This isn't much of a problem, the problem is the integrity / validity of our code. i.e. how was the information to write the code obtained. See above. > But at > http://www.reactos.org/archives/public/ros-dev/2006-February/0 > 07832.html > a developer says to me > "The leaked source code was never an issue here, that was an > escalation of > the mail which was posted on the public list. The rumours > which materialized > from that were unfounded and untrue." Correct. > In an other mail, I don't find it at the moment, anybody > says, that there is > still no Microsoft-Code found in ROS. All is clean. Define 'MS code'. If we're talking about leaked source code, then that is true. If we're talking about small chunks of assembly from dissasembled MS binaries, then that is what the audit hopes to uncover and remove. Once the audit is complete, we can also say we know this to be true, at the moment we don't know. > On the following > http://www.reactos.org/pipermail/ros-dev/2006-February/007717.html > a developer says > "I am told that the sources for FreeLdr are all okay, except for the > some of the bootsectors having been pretty much just disassembled from > MS's. Is this true?" > The answer comes from an other developer > http://www.reactos.org/pipermail/ros-dev/2006-February/007722.html > "crashfourit has posted a patch here:" > > That means, that it is possible, that MS-bootsector-code have > found the way > in ROS, if I understood it right. This code hasn't been audited yet. It's possible that parts of the bootsector have been derrived from an MS dissasembly. The audit will reveal the answer, and it will be rewritten if nessesary. > And at > http://www.reactos.org/archives/public/ros-general/2006-Februa > ry/002128.html > somebody cite something where a Codewaever chef says, that in > ROS is stolen > code. Incorrect. There is no stolen code in ROS and more than there is stolen code in Wine. > And then ReactOS gives for me more questions then answers. > > What does the Audit-process mean? It means all suspect code will be proof-read and documentation must be made available to prove it's validity. If not, the will be either rewritten, docs written or removed dependant on the circumstances. > You have - as somebody says - already seen, that no > Windows-Code is in > ReactOS. > But you want with the audit look for code, which are > integrated by (not > clean room) reverse engineering. > But how do you want to find it? Any code that is questionable. i.e. a reason cannot be found as to why it is included. I agree it's difficult to tell what is clean room and what it not. As KJK said, if we don't question it's validity as all appears well, then it would be up to a 3rd party to proove otherwise. > Steve Edwars have written "and the long road to 0.3". Is it > still true, that > it needs now longer, until 0.3 comes out? The tree will > already be opend. > Does it mean, that 0.3 comes only after the end of the > audit-progess out? If > this is true, comes then before the end of the audit other > releases out > (0.2.10, 0.2.11, .... etc) ? Decisions on new policies havn't been reached yet. It's true that it is still a long road. The audit is still going to happen, it's just that we're doing it in a slightly different way now. It is hoped that this new method will ensure the project stays alive during the audit. > You see. I am very confused. I hope that cleared some things up for you. > http://www.reactos.org/archives/public/ros-dev/2006-February/007832.html > Murphy have written "The whole tree will be reopened in the state it was in > before it closed. > More details will follow when this happens.", will really clarify all. So > that no longer confuseness for anyone exists. The current vote will decide the outcome of that. There are currently 2 options. Read the mail entitled 'Vote: Code Auditing' for more details. Regards, 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

4 3

Re: [ros-dev] very confused
by rené Tournois 17 Feb '06

17 Feb '06

At 20:21 17/02/2006 +0100, you wrote: >I think this only applies to the bootsector, wich has asm directly taken >from disassemblies in it. Ah. Then it should be the [Boot] sector. I see 5 files in there, with asm statements. Only one could be a problem, that is named "longhorm.h". 52,000 Bytes long // 105 "_asm__". Outchhhh... But did not another guy said that there was a possibility of complete replacement? And, if i miss-undertood, or if not possible, would it take one year for proof-reading 52,000 bytes of C Source? >I think what Ged was talking about was disassemblies converted into C. >And this can be found by looking for typical things of that kind of code: >- Magical number inside C code. Normally constants are used or the >numbers are commented or really obvios. But when you don't know why >there's a constant 0x2342 then you don't really know how to call it. In >disc.c there's a constant called PARTITION_MAGIC ;-) >- excessive gotos: You would normally not use any gotos, but it can be >hard to identify complex structures of for, if, while,... inside asm >code, so you do it like it's done in asm: with gotos. It doesn't look >good, but it works. Ah! C simulating Assembly and hard coded unknown numbers... OK, i see the problem better, with these points, as long as there is really a _lot_ of Files with "goto"s inside, and i can imagine how sorting all of these out, might be a boring task. But this was not, at all, what was first said. Thanks for the explanations. Betov.

1 0

RE: [ros-dev] Re: Vote: code auditing
by Dann B. Smith 17 Feb '06

17 Feb '06

Which is why I stated a couple weeks ago thaqt politics has NO place in an engineering project. At all. Ever. -----Original Message----- From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of mf Sent: Friday, February 17, 2006 1:55 AM To: ReactOS Development List Subject: [ros-dev] Re: Vote: code auditing Brandon Turner wrote: > That was the orginal plan, and we just voted against it. > > Brandon > That's the idea with politics, you amend a proposal until the original purpose of the proposal is completely reverted, and you end up with a new set of useless silly rules with possible flaws, loopholes etc. If you can't get people to accept something, just confuse them with even more proposed rules, preferably vague but essentially the same as what they originally voted against. mf _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

3 3

RE: [ros-dev] very confused
by Murphy, Ged (Bolton) 17 Feb '06

17 Feb '06

Murphy, Ged (Bolton) wrote: > Incorrect. There is no stolen code in ROS and more than there > is stolen code in Wine. Sorry, that should read 'There is no stolen code in ROS _any_ more than there is stolen code in Wine. ************************************************************************ 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] very confused
by Murphy, Ged (Bolton) 17 Feb '06

17 Feb '06

theUser BL wrote: > But at > http://www.reactos.org/archives/public/ros-dev/2006-February/007832.html > a developer says to me > "The leaked source code was never an issue here, that was an escalation of > the mail which was posted on the public list. The rumours which materialized > from that were unfounded and untrue." > and the cvs tree will be completly re-opend. IIRC, it was me who said that. What I mean by that is that none of the leaked Windows source code has ever found it's way into ReactOS. Many people thought that was the case, but they were wrong. 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

RE: [ros-dev] Re: Goodbye Everyone...
by Dann B. Smith 17 Feb '06

17 Feb '06

I must agree. Problems can sometimes bring out the best in people and projects. The fact that there was a minor setback will likely make the project stronger and btter then ever, even if only by reafirming to the project by those who have committed the most. -----Original Message----- From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of mf Sent: Thursday, February 16, 2006 3:09 AM To: ReactOS Development List Subject: [ros-dev] Re: Goodbye Everyone... Steven Edwards wrote: > We seem to be a ship that is taking on water. Gee, if that's the attitude our Project Coordinator, role model and source of inspiration for the project, is taking, then I don't know what I should think. Are you just acting this unoptimistic because you feel like a captain who's almost got mutiny on his hands, or is it some other reason? From everything I've seen, I'd say things are looking up lately. But that's just my humble opinion. mf. _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

3 2

RE: [ros-dev] Goodbye Everyone...
by Murphy, Ged (Bolton) 17 Feb '06

17 Feb '06

Dann B. Smith wrote: > Hmmm... Wrong. A strong leadership can prevent the > politicization of a > project if handled correctly. > > I would like to paraphrase certain scientists here and say that if you > have to vote on a thing, it isn't science (or engineering). > And if it's > science (or engineeirng), it does not (ever) need a vote. > > Science and engineering are based on two things: truth and > workability > (respectively). > > If that maxim can't be followed, the rest of the discussion is moot, > since the project has already died. It has nothing to do with Science or engineering. It's a simple case of people having different ideas and we have to work out which path to follow. In a volentary project like this, how else do you propose different views are solved? You can't forcefully make someone do something unless you are paying them, thus a majority vote is the only fair way. 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

RE: [ros-dev] Goodbye Everyone...
by Dann B. Smith 17 Feb '06

17 Feb '06

Hmmm... Wrong. A strong leadership can prevent the politicization of a project if handled correctly. I would like to paraphrase certain scientists here and say that if you have to vote on a thing, it isn't science (or engineering). And if it's science (or engineeirng), it does not (ever) need a vote. Science and engineering are based on two things: truth and workability (respectively). If that maxim can't be followed, the rest of the discussion is moot, since the project has already died. -----Original Message----- From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Murphy, Ged (Bolton) Sent: Thursday, February 16, 2006 4:21 AM To: 'ReactOS Development List' Subject: RE: [ros-dev] Goodbye Everyone... Rick Langschultz wrote It is inevitable that as a project grows in size and popularity, it also becomes much more political.

1 0

RE: [ros-dev] Vote: code auditing
by Ged Murphy 17 Feb '06

17 Feb '06

Ged Murphy wrote: > B - Sections of ReactOS which require auditing are 'locked', > that being that the source is fully available to download and > build, but no development work should be undertaken until > the said code has passed the audit. The lock will be > removed only when that section of code has been audited. I am in agreement with proposal B, freezing of un-audited sections. Here are my reasons: Firstly I'll elaborate on what a lock does: Any developer can 'get-a-lock' on a file. Having this lock means only that developer can commit to that file*. A locked file cannot be modified, deleted or renamed in the repository by anyone else. To set a lock on a file, you lock it as per your client syntax and set the subversion property svn:needs-lock. When this property is set on a file, a checked out or updated file is made read only locally. (except for the person who holds the lock*). This acts as a warning that the file should not be modified. Users of Tortoise will also have a graphical overlay stating a file is locked. Locks can be removed by any developer in a process called breaking-the-lock. (ownership of the lock can also be taken known as stealing-the-lock, although that's not important for us). The ability to Break the lock ensures that no one developer has control over the lock. Anyone can remove a lock at any time. Users and developers alike will not notice a lock unless they try to modify locked code, so it would in no way inhibit general usage. *(a user named 'audit' can be set up to do the initial locking of the files) What the lock would do is act as a barrier for any further development on non-audited code. Code which has not been audited must be deemed as 'tainted' until it has passed an audit. I do however think that what we deem as tainted can be narrowed down. All usermode applications along with all Wine libs and many other areas (to be discussed) will bypass the lock immediately. Code which has not yet passed the audit should not be improved, committed to, developed (whatever the phrase). There are 2 good reasons for this. Firstly, there is a possibility that this code needs to be removed, so it is a complete waste of a developers time to improve this code. Secondly (and most importantly), by freezing this code, it puts more of an incentive on developers to audit it. e.g. if someone is working on some code which requires a particular section of un-audited code to be modified, or exposes a bug in some un-audited code, the developer must audit the said code in order to fix the problem. Only then will they be able to take advantage of this with their ReactOS improvement/addition. If this code wasn't frozen, the chances are, the developer will tweak the un-audited code and carry on regardless. Thus un-audited code will tend to take a back seat. I agree with Gé, in that if some method is not put in place to ensure our code is audited, people will conveniently forget about it. Not only must we been seen to be pro-active with the audit for the general public to see (e.g. osnews, slashdot), but we must also ensure we do not alienate developers who feel _very_ strongly about the un-audited code. By reopening the repository, with the addition of locking un-audited code, I think we can strike a fair compromise for all parties, and ensure the audit takes place. Ged.

2 1

Re: [ros-dev] Freeldr installer ?
by Sylvain Petreolle 17 Feb '06

17 Feb '06

> The Ros CDs loader might be useful for you too. This did remind me we can download ros sources without using SVN. Therefore I have the freeldr installer now, thanks for all. If you didnt read the mailing list since some time, SVN code is being audited and contains almost nothing atm for *users*. --- Sarocet <sarocet(a)gmail.com> a écrit : > Sorry, as you talked about old svn i thought that was your problem. > Don't know what happened with svn, i have been disconnected of the project > over a month. > The data you want is (should be) probably in trunk/reactos/boot/freeldr at > folders freeldr and install. > I also see strange no data in branches folder..... > > Anyway, i can send you the freeldr folder i have on my svn copy (over a > month and a half old). I guess better wait until get the new svn before > updating. > The Ros CDs loader might be useful for you too. > Kind regards, Sylvain Petreolle (aka Usurp) --- --- --- --- --- --- --- --- --- --- --- --- --- Tired of a proprietary Windows on your computer ? Use free ReactOS instead ( http://www.reactos.org )

1 0

[VOTE] Freeze modules until documented
by art yerkes 17 Feb '06

17 Feb '06

http://www.reactos.org/forum/viewtopic.php?t=1697 -- Discordant is the murmur at such treading down of lovely things while god's most lordly gift to man is decency of mind. Call that man only blest who has in sweet tranquility brought his life to close. If only I could act as such, my hope is good. -- Aeschylus' Agamemnon (translated by H. W. Smyth)

4 4

***SPAM*** Goodbye Everyone...
by Richard 16 Feb '06

16 Feb '06

Well, it's been fun, however i believe it is time for me to leave. ReactOS really has fallen to pieces and it's going to take a long time (years) to get things back on track. What really annoys me about this entire thing is that waaay back in the earlier days of ROS (before 0.1) Things were fun. Nothing worked, but things were fun. Development on ROS was actually HAPPENING (I know this because I myself was part of it). Since then things started changing. New developers appeared, a lot of flame wars were breaking out, etc. I stayed on the list, pitched in my 2 cents, etc. Though i stopped coding for the most part. Now it turns out that developers were using dirty room reverse engineering tactics, or have had access to the source code. I almost left then, but i figured i'd give it a little bit longer and see what happens. Now I see a bunch of arguing on the mailing list, ROS development has stopped, and I'm doubting it'll resume again for a long time, and things have just pretty well fallen apart. Even IF the audit is completed, ROS will likely be in pieces. It will NEVER be at the level it was before the audit. Anyways, I believe it is time to start anew. New project, different name, different goals. Until Then, Bye. Richard Campbell ReactOS Developer and Long Time Fan

8 11

Vote on ReactOS Reactivation Plan closed
by Aleksey Bragin 16 Feb '06

16 Feb '06

The vote on choosing a plan for further ReactOS development is now finished. The results are: Plan A: 4 Plan B: 14 This means that all points from the Plan B are now in force. Additional announcement will be made regarding the SVN repository. For detailed read go to http://www.reactos.org/forum/viewtopic.php? t=1675 WBR, Aleksey Bragin.

1 0

RE: [ros-dev] Goodbye Everyone...
by rené Tournois 16 Feb '06

16 Feb '06

At 15:01 16/02/2006 -0000, you wrote: >Sorry, I'm not really sure what your question is. > >After being derailed recently, ReactOS is now being put back on the tracks. >There is finally a clear path starting to emerge for development to restart. >There will not be a fork, development work will continue on ReactOS. > >If any of those don't answer your question, can you try to reword it please. :)) Don't be sorry: I am used with not being understood, and i am quite sure that this is not because of my "particular english". :)) Well, my question has been answered to, by the recent answers to Hyperion post, and, mind you, if you do not understand what i write, as a matter of fact, it seems that i understand rather well how the things are going, because since day one of the "problem", when some other lurkers fellows of mines were under alarm mode about it, i told them that "the problem will not take years, but 3 months". And if you could understand my previous question, you would prefectly understand, also, how and why i was able to predict the exact time that it would take, before yourselves, whereas i do not even write C. :)) Betov. < http://rosasm.org >

1 0

RE: [ros-dev] ***SPAM*** Goodbye Everyone...
by Murphy, Ged (Bolton) 16 Feb '06

16 Feb '06

Juan Rodriguez wrote: > I totally agree with Hyperion, not to mention that even the > last version > was far away from beeing really usable/stable as an os should > be at least. > I know there is much work that has been done, but as i recall the > project was to make an os able of beeing an alternative to windows > itself, politics and such, are matters that should be > discusssed after > the project has taken form, and imho it is not. So lets code and stop > bitching about politics. Great, you should join the project and solve all our problems. I wish we had realised sooner that the answer was so simple. We could have saved all this mess if we had known the way to avoid issues is to shut up and continue coding. ************************************************************************ 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

3 2

RE: [ros-dev] Goodbye Everyone...
by Murphy, Ged (Bolton) 16 Feb '06

16 Feb '06

... wrote: > I have seen enough of such scaring horrors, like Anti-GPL, and/or > Right-Wing guys, contributing to ReactOS, to understand the reasons > why the true words were not said, but, at this point, i really would > like to know where the things are going to, and if a dissident Project > is to be started, the correct political and ethical way, or if the > same Project is taking a correct path, i would like to see, at least, > a "White Paper" for it. Having seen volunnteers saying that "using > GPLed-compatible Dev-Tools was not a necessity" (Hyperion, if i recall > well), or pure horrors like "In the future we may have collaborations > with MicroSoft" (Alex, taking publicly the defense of a Neo-Nazi, > against... me -???!!!...-), for example, are things that made me > really sea-sick. > > Personaly, i am not interrested with knowing if unfair Code was > implemented or not (knowing of the individual, this is not any > surprise to me, by the way). What i wish to know is: > > Will the political and ethical lessons be understood? Or not? > > [By the way, the simple fact of having to ask such a question, > about such an important GPLed Project, like what ReactOS is, > is already a pure scandal to me: I shouldn't even have to ask] Sorry, I'm not really sure what your question is. After being derailed recently, ReactOS is now being put back on the tracks. There is finally a clear path starting to emerge for development to restart. There will not be a fork, development work will continue on ReactOS. If any of those don't answer your question, can you try to reword it please. 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

RE: [ros-dev] ***SPAM*** Goodbye Everyone...
by Murphy, Ged (Bolton) 16 Feb '06

16 Feb '06

theUser BL wrote > That would be nice. > If you restore the old cvs-tree, before the Windows-code > leaked (ca. 7. Feb. > 2003) and before the people who have readed the code joined > ReactOS, then > there existing legal ReactOS-code, which you can published. No, you misunderstood. The whole tree will be reopened in the state it was in before it closed. More details will follow when this happens. The leaked source code was never an issue here, that was an escalation of the mail which was posted on the public list. The rumours which materialized from that were unfounded and untrue. ************************************************************************ 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] ***SPAM*** Goodbye Everyone...
by theUser BL 16 Feb '06

16 Feb '06

>The only consolation I can give you is that the old tree will be restored >somewhere as per the vote. From there auditing should take place. That would be nice. If you restore the old cvs-tree, before the Windows-code leaked (ca. 7. Feb. 2003) and before the people who have readed the code joined ReactOS, then there existing legal ReactOS-code, which you can published. That is what is needed! At the moment you have deleted all. There existing no longer any code. The look at the future is to look behind, which code can be let in and which not. But if you publish old code, then there is a point from which on the ReactOS-developer - like Richard - can again developing forward. Greatings theuserbl

1 0

RE: [ros-dev] Goodbye Everyone...
by rené Tournois 16 Feb '06

16 Feb '06

At 10:20 16/02/2006 -0000, you wrote: >It is inevitable that as a project grows in size and popularity, it also >becomes much more political. [...] > >There is no getting away from the fact that politics would eventually >emerge, it was going to happen some day. I am a lurker, here. I started a GPLed project -completely outside ReactOS, but conditioned to the existence of ReactoS- the first day i heard of the ReactOS Project. In other words, i work _for_ reactOS Environment, and not _for_ Windows, and along all of these years of developments (I started in 1998), i always took a particular care of locking my own work, so that it could not be extended and re-used, in case the ReactOS Project would collapse. I am used to not post anything, here, as long as i consider that, as i do not contribute to anything in the ReactOS developments, i just have the right to shut-up and thank for having the right for reading. Nevertheless, with the actual events, it seems to me that, we -the external lurkers- have natural rights to be informed about the _real_ political and ethical concerns. I have seen enough of such scaring horrors, like Anti-GPL, and/or Right-Wing guys, contributing to ReactOS, to understand the reasons why the true words were not said, but, at this point, i really would like to know where the things are going to, and if a dissident Project is to be started, the correct political and ethical way, or if the same Project is taking a correct path, i would like to see, at least, a "White Paper" for it. Having seen volunnteers saying that "using GPLed-compatible Dev-Tools was not a necessity" (Hyperion, if i recall well), or pure horrors like "In the future we may have collaborations with MicroSoft" (Alex, taking publicly the defense of a Neo-Nazi, against... me -???!!!...-), for example, are things that made me really sea-sick. Personaly, i am not interrested with knowing if unfair Code was implemented or not (knowing of the individual, this is not any surprise to me, by the way). What i wish to know is: Will the political and ethical lessons be understood? Or not? [By the way, the simple fact of having to ask such a question, about such an important GPLed Project, like what ReactOS is, is already a pure scandal to me: I shouldn't even have to ask] Betov. < http://rosasm.org >

1 0

RE: [ros-dev] Goodbye Everyone...
by Murphy, Ged (Bolton) 16 Feb '06

16 Feb '06

Rick Langschultz wrote > It seems that many people want to give up the project, which would be > a total loss of time and energy of those who have spent many hours > and money on the project. I agree that it has looked like that on occasions, however I assure you that is not the case :) It is inevitable that as a project grows in size and popularity, it also becomes much more political. There is no avoiding the fact that the ReactOS of today is a very different environment from what it was. This change leads to many of the original developers viewing the project of losing the aspect of fun which it used to have. As a consequence, many are leaving the project which, is a sad and unfortunate outcome. There is no getting away from the fact that politics would eventually emerge, it was going to happen some day. All big project have this barrier to battle with, and that day has arrived ReactOS too. However with project growth bringing the unfortunate addition of politics, it also brings the welcome addition of excitement and maturity. End users now have something to try out, we even have firefox and thinderbird running now :-D This level of maturity should ensure the survival of ReactOS, even if there are huge mountains to climb every so often. Hope that raises a few spirits, keep your eye on ReactOS this weekend ;) 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

RE: [ros-dev] Goodbye Everyone...
by Murphy, Ged (Bolton) 16 Feb '06

16 Feb '06

Steven Edwards wrote: > We seem to be a ship that is taking on water. We are hopefully about to hit a turning point and put things back on track. The project has been completely lost and in the dark for the past few weeks, but we are starting to find the light now. I'm looking forward to this weekend ;) Ged. ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

2 1

Call for Vote
by Maarten Bosma 15 Feb '06

15 Feb '06

Subject: Freeze every module in svn until it got audited Proposed by: Maarten Bosma / Art Yerkes Days of discussion: 7 (started 09.02.2006) Days of voting: 7 (starting in 24 hours from now - 16.02.2006 20:00 GMT) Proposal: Do not allow changes to a module until it got audited. Options: [ ] Accept proposal [ ] Do not accept [ ] Further Discussion Remarks: I took the first appearance of the idea as beginning of discussion.

5 5

Freeldr installer ?
by Sylvain Petreolle 15 Feb '06

15 Feb '06

Hi people, Im using Freeldr to boot up my entire system since I tried ReactOS. I installed it on a diskette in the past and it would be a great thing if I could migrate it to the hard disk. Since the old SVN isnt online anymore, I dont have access to the commandline installer. Do you plan to put it back into the SVN later, and if not, could you tell me where I can find it ? Kind regards, Sylvain Petreolle (aka Usurp) --- --- --- --- --- --- --- --- --- --- --- --- --- Tired of a proprietary Windows on your computer ? Use free ReactOS instead ( http://www.reactos.org )

2 2

RE: [ros-dev] FW: Repository hosting
by Murphy, Ged (Bolton) 15 Feb '06

15 Feb '06

Perhaps this is now the time to move it to the Swedish servers as suggested by JvA -----Original Message----- From: Ge van Geldorp [mailto:gvg@reactos.org] Sent: 15 February 2006 11:27 To: 'ReactOS Development List' Cc: 'Casper Hornstrup' Subject: [ros-dev] FW: Repository hosting > -----Original Message----- > From: Casper Hornstrup [mailto:ch@eudicon.com] > Sent: 13. februar 2006 18:06 > To: 'ReactOS Development List' > Subject: Repository hosting > > Hi. > > I've decided not to host the ReactOS Subversion repository beyond > March 31st 2006. That gives you up to ~6 weeks to find a new place to > host it. I will send the repositories (both new and old) to the person > who will host the repository in the future. Please contact me when you > want this done. ************************************************************************ 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

FW: Repository hosting
by Ge van Geldorp 15 Feb '06

15 Feb '06

> -----Original Message----- > From: Casper Hornstrup [mailto:ch@eudicon.com] > Sent: 13. februar 2006 18:06 > To: 'ReactOS Development List' > Subject: Repository hosting > > Hi. > > I've decided not to host the ReactOS Subversion repository beyond > March 31st 2006. That gives you up to ~6 weeks to find a new place to > host it. I will send the repositories (both new and old) to the person > who will host the repository in the future. Please contact me when you > want this done. > > P.S. Please CC me directly as I'm not subscribed to this list. > > Med venlig hilsen / best regards > Casper Hornstrup > Chief Executive Officer @ Eudicon > ch(a)eudicon.com / www.eudicon.com > (+45) 27 29 36 20

1 0

ReactOS File System
by Rick Langschultz 15 Feb '06

15 Feb '06

I am writing a file system for personal development use for reactos. I want to take a poll about what File System features that ReactOS would like to implement in its distribution. Are there any features out there that ReactOS developers like to implement in ReactOS. I want to model the file system on NTFS but i have been looking at Sun's ZFS and think that it would be a great File System for React... Another thing... How is the code audit going?

4 6

RE: [ros-dev] What Happened
by Dann B. Smith 14 Feb '06

14 Feb '06

Hi! I'm probably a non-person to most people here. This is my first foray into the mailing list as a submitter. If I may say a few things: First: No one has a RIGHT to anything. Mailing lists, archives, whatever. You only have whatever options the originators of IP or code decide to give. Second: For a fully open source project, private lists are Bad News. While they do allow sensitive ideas to be discussed in a more informal setting, they also give the options to have high-level decisions to be made without any community support. I've seen it saidf in this list that the "private" list developers talk abut things that don't affect other developers. WRONG! Anything that the "primary" developers talk about affects the entire development community. Otherwise, there's no reason to duscuss it at all. Third: While reverse engineering may be legal in Europe, it's only legal in certain circumstances in the US. Open source projects tend to be world-wide in scope. Thus, the most restrictive of laws MUST be applied so that no legal boundaries are crossed. In this case, it looks like the US has laws that do not exist elsewhere. Likewise, the US has one of the largest "markets" for software, so the US can't be discounted unless we wish to develop a Europe-only OS. Thus, no matter what, we have to follow the restrictive US laws on reverse engineering. Despite any personal feelings, laws must be upheld. Fourth: Re: dirty laundry. This is almost a non-starter. Yes, some things were said that caused a bit of an uproar. Yes, the project is being held up in some respects. On the other hand, we have enough people here who care enough to give voice to their opinions AND who care enough to see the project succeed that the idea that "dirty laundry" being aired in public being a bad thing is absurd. The results say otherwise. Politics has NO place in an engineering project. None. Ever. Don't let the idea of politics creep in and kill an otherwise wonderful thing. Fifth: Personal attacks here are without doubt, worthless. This is a list for developers, coders, and engineers. To call someone's attitude ridiculous goes right back into my previous statement about politics. Sixth: I would like to thank you all for reading my post, whether you agree or not. In the end, I speak for no one but myself, and you can take what I say however you want. Dann Smith Dallas, TX, US -----Original Message----- From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Rick Langschultz Sent: Wednesday, February 08, 2006 6:27 PM To: ReactOS Development List Subject: Re: [ros-dev] What Happened Don't get me wrong, reactos is a great programming idea. The way some people do things is not necessarily what the community would want. As a long term web developer I had an interest in VFS implementation of NTFS over FAT or other filesystem. Creating a private mailing list not available to the community restricts information from getting to developers that want to continue to develop reactos, whether they commit or not. Everyone has the right to develop what they think ReactOS needs. Personally I think ReactOS needs stable Networking, a more stable and secure filesystem, and service implementation. I also think that building a universal install disk would be great -- install on PowerPC, intel, arm, all on one cd would be great. I am not willing to give up on programming projects so I will continue developing code, but when the audit is complete I just hope 99% of the community is there to back ReactOS up... On Feb 8, 2006, at 4:05 PM, Ged Murphy wrote: > Rick Langschultz wrote: >> "The ReactOS(r) project is dedicated to making Free Software >> available to everyone by providing a ground-up implementation of a >> Microsoft Windows(r) XP compatible operating system." Why not say I >> am sorry ReactOS is off limits to you, the community, because people >> steal, cheat and lie. It is said that good programmers steal code, >> and great programmers know whose code to steal... >> Stealing M$ code is obviously not the wisest choice... >> >> I will continue to develop my own personal ReactOS code but I don't >> think I will contribute it to ReactOS. My implementation of the NT >> VFS over FAT will be rolled into a new project. And be able to be >> downloaded by ROS developers and community members. >> >> Ridiculous... > > As is your attitude ... > > The ReactOS developers have spent thousands upon thousands of hours > writing a free operating system for the world to use. > It has become so large now, that the inner workings are becoming > business like, and measures must be put into place to deal with this. > If you can't accept that developers need a place where they can > discuss topics, have arguments and sort out issues, out of the public > eye then that's your problem. I'm positive Linux and BSD have > somewhere where developers can discuss issues, as do most other large > (and even small) projects Maybe we should take minutes of any > telephone conversations we have and post those too? > > I for one am glad you won't be committing any code. You attitude > sounds like it would generate more problems than it's worth. > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

7 11

White Paper outdated ?
by Maarten Bosma 11 Feb '06

11 Feb '06

Our Withe Paper on http://www.reactos.org/xhtml/en/dev_whitepaper.html says > The original target for ReactOS, with regards to driver and application > compatibility, was Microsoft Windows NT 4.0. Since then, Microsoft > Windows 2000 and Windows XP have been released. Microsoft Windows 2000 > and Windows XP are both descendants of Windows NT. As such we can > gradually shift our compatibility target without worrying about the > architecture changing too much. In fact, internally, Windows 2000 > reports version information as Windows 5.0 and Windows XP as Windows > 5.1. The ReactOS team have decided to maintain Windows NT 4.0 as the > official compatibility target. This is because most of the resources, > articles and books on Windows NT/2000/XP technology are written for > Windows NT 4.0. This does not mean that features present in later > versions of Windows NT based operating systems will not be implemented > in ReactOS. Since we changed the reported version to Windows 2000, i'd say that is not true anymore is it ? Maarten Bosma

5 5

rbuild XML processing
by Martin Fuchs 11 Feb '06

11 Feb '06

Hi, as you may know rbuild uses its own XML reading routines independent from any existing XML parser. This means there is missing some functionality we could get using a "real" XML parser: - no real syntax and hierarchy check of XML data - no UTF-8 support I am working on integrating Expat (the XML parser used for example in ROS Explorer) into rbuild. This is currently only an experiment just for fun - independent from ReactOS. I may use this rbuild derived build system for some private projects. Is there any interest to include Expat into the ReactOS version of rbuild? Regards, Martin

2 2

RE: [ros-dev] What Happened--It Happened Lets Get To Work.
by Peter Dolding 11 Feb '06

11 Feb '06

Reverse engineering. USA states clear rules. A person who pulls appear the code cannot take part in creating the new code or device. Ie Document how it work. This rule does not change where ever you are. Reverse engineering cases have been fort and lost in most countries because developer not been able that they did not copy X section of code directly from what they were Reverse engineering. Ie since the code matched close enough it was pick since they had seen inside the program they copied and then tried to hide it. USA method prevents this. The coder never saw inside the program so it must be a fluke. Legal or not is not the issue it if you can prove that you have not breached copyright in a court of law. Digital Millennium Copyright Act (DMCA) Has never been tested in a court of law. Australian Government had something simpler for about two months since then fair use clauses have been added allowing reverse engineering and other methods of bypass with restrictions of course you cannot set out with the reason bar to break DRM but setting out to bypass to allow legal backups or for compatibility is fine or to bypass some other forms of stupidity. Ie region codes fall into stupidity. I by a legal copy of something bring it home then cannot play it that is stupidity. DRM is not allowed to create trade barriers if so it illegal so completely open to attack. Simple example provide it. Completely Open Source Player. Linux kernel ... Only part closed kinda was a public key. The license on the key was a killer. [quote] You here by agree to use only approved software on any machine that is use with this public key. No existing or third party data allowed on the playing device along with the public key except for approved software and file created by approved software as part of approved software operation. [/quote] Now a pirate that does not care about the license does not have to format their computer to watch the video. Law abiding person has to. Note approved software only contains a player not a converter. Pirate is free do what they like and law abiding is hurt majorly. The addon's in Australia would allow above to be got around legally. Just give this to your government. They realize there is a flaw in the DMCA and its not friendly. We have a mess. Fighting over what rules apply here apply there solve nothing. Laws that have not been to court may or may not hold. Lets take a really good look at the source tree. -Insert new version of externally source sections. Leave documentation so next update of this section is simpler. Note my Zlib patch posted to ros-dev is a requirement 1.1.4 has known security problems. Most likely there are more. -Locate sections that need documentation written. Rbuild is one of these things that needs documentation for new developers. It confused the heck out of me. I am not a documentation writer. I woffle to much and suffer from dislexer so sometime documentation I can read no one else can(yes it can pass a grammar and spell checker). -Find features that external libs need added to improve them inside Reactos to produce a better Reactos. Mesa could do with a opengl version change option. Ie no hardware accel and low processor user drop it back to version 1.2 opengl. Ie adjustable 1.2 takes a lot less process to render than 1.5. Developers could work on adding these features while main tree is completing audit. Developers with nothing to do get upset. I guess most of the developers in Reactos that this first time they have had to handle a Audit. Key to handling a Audit effectively is not to remain frozen at the same point in time. But to move forward in the process of Auditing. If have access to external developers get them working on parts that will be required in future as soon as able normally requiring feature requests. Peter Dolding

1 0

RE: What Happened
by David Eckert 11 Feb '06

11 Feb '06

Allow me to just put it this way, reverse engineering IS illegal, HOWEVER even Microsoft reverse-engingeers stuff that they want to know how it works and to write drivers/etc for, so I still don't see the point of why anyone would have a problem, it's not like ReactOS is the first to utilize reverse-engineering practices to learn something, and secondly I'd like to point out by the information I have studied, ReactOS DOESN'T have Windows source code in it (at least by the current facts, no) it was suspected that so due to a certain crash that looked similar in terms of debugging very identicle to Windows. -- -David W. Eckert

7 7

The zlib update from 1.1.4 to 1.2.3
by Peter Dolding 11 Feb '06

11 Feb '06

Get zlib 1.2.3 extact to a directory. Apply patch to that directory with normal bzcat zlibreactos.diff.bz2 | patch -p1 Read the README.ROS please edit as required. Me English don't mix. Made attempt at instructions for next updater of that section. I don't mind if it gets deleted if my English is to bad. When happy delete the old zlib dir and replace with the zlib 1.2.3 directory. If liked update to svn. As far as I can see it give no problems with Reactos 0.2.9. After in svn no need to audit if you look closely their is only one minor change other than that is zlib-1.2.3. Clean code. Peter Dolding

1 0

FW: hi we have translated the explorer of React OS ...........
by Ge van Geldorp 10 Feb '06

10 Feb '06

Forwarded from ros-translate to ros-dev _____ From: mailman-bounces(a)reactos.org [mailto:mailman-bounces@reactos.org] On Behalf Of banglasoft Sent: Friday, February 10, 2006 03:06 To: ros-translate-owner(a)reactos.org Subject: hi we have translated the explorer of React OS ........... hi gvg and other React OS developers, we have translated the React OS explorer in bangla. here is a screen shot attached with this mail. now we r looking forward to hearing from u people. if u give us the permition than we will translate the whole React OS. we think if some one translate the React OS in Bangla then this definitely will be a grate improvement for the React OS. React OS will be more femous then windows OS amoung the bangla speaking people. we r waiting for u r reply. -banglasoft.

5 5

Re: [ros-dev] FW: hi we have translated the explorer of React OS ...........
by theUser BL 10 Feb '06

10 Feb '06

> we have translated the React OS explorer in bangla. here is a screen >shot >attached with this mail. now we r looking forward to hearing from u people. >if u give us the permition than we will translate the whole React OS. we >think if some one translate the React OS in Bangla then this definitely >will >be a grate improvement for the React OS. React OS will be more femous then >windows OS amoung the bangla speaking people. Nice. I know only that for Java is at http://java.sun.com/products/jlf/ed2/book/Appendix.C.html http://java.sun.com/products/jlf/ed2/book/Appendix.C2.html http://java.sun.com/products/jlf/ed2/book/Appendix.C3.html http://java.sun.com/products/jlf/ed2/book/Appendix.C4.html http://java.sun.com/products/jlf/ed2/book/Appendix.C5.html a side of different translations. It describes the standard translations for the Java-specification. So I think they can be used. GNU Classpath makes also use of the there discribes LookAndFeel. And at http://developer.gnome.org/projects/gtp/style-guides/ are GNOME translation guidelines. (in the pdf-files) And here are more of the GNOME thing: http://developer.gnome.org/doc/tutorials/gnome-i18n/developer.html http://developer.gnome.org/documents/style-guide/wordlist.html Greatings theuserbl

3 3

RE: [ros-dev] RE: What Happened
by Murphy, Ged (Bolton) 10 Feb '06

10 Feb '06

Carlo J. Calica wrote: > I don't remember reading that on this list. The public > allegations were: > wide spread "questionable" reverse engineering practices, and > devs looking > at leaked code. There were many allegations thrown about. One of the first places for something to appear was our own forums in which the post was titled something along the lines of "ReactOS contains MS leaked source code" (I don't remember the exact wording). I picked that one because it was completely untrue and unfounded. I was just using it as an example of how something untrue can escalate into something damaging. > > > Now, if this mail was received privately, we could have > dealt with the > > issue internally and avoided all this mess. Development would have > > continued whilst we resolved any potential issues. For the > community and > > the project as a whole, which would you consider to be the > better option? > > > Pretending issues don't exist won't make them go away. The resolution > shouldn't change if discussed in private or public. I never once said they would. I don't know where you got that from. The way something is handled can vary greatly dependant on the circumstances, but that doesn't avoid the fact that the issue remains and must be dealt with. > Maybe development > could have continued during a code review, but then the code > review would > take much longer and may never be completed. There might > never have been > the clarification on reverse engineering techniques. As a > potential user > and project proponent, I am VERY happy with the whistle > blowing and the > public response. ReactOS IS stronger after this setback. > Now you have a > good IP policy that is defensible. We don't have a valid IP Policy at the moment. I also fail to see how a project on the edge of closing and divided developers is stronger. > PLEASE reconsider the private list. Failing that, members of > the list, move > public topics here. We DO appreciate it. It IS for the good of the > project. Public topics are _not_ discussed on the private list. In all honesty, very little is discussed on the private list. This is just another example of something being blown out of proportion. Developers have been having private discussions since the project started about 8 years ago, however they are few and far between. It's just that now instead of using private emails exclusively, a mailing list has been set up for convenience. Nothing has changed. I'm sure members of the community who are non-developers also do the same. I don't ask that they discuss their issues on the public mailing list either. > Don't feel the need to respond. I just wanted to provide an alternate > viewpoint. This topic is very much opinion. I doubt you'll > be able to > change mine and I may be unable to change yours. I am nothing but an > interested observer, you owe me nothing. Thanks for hearing me out. All views are fully welcome, and valid. This project belongs to everyone. 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

RE: [ros-dev] What Happened
by Murphy, Ged (Bolton) 10 Feb '06

10 Feb '06

Rick Langschultz wrote: > Creating a private mailing list > not available to the community restricts information from getting to > developers that want to continue to develop reactos, whether they > commit or not. The private mailing list has nothing to do with development and certainly contains no information that could be deemed useful towards the development of ROS. It's just somewhere developers can discuss sensitive issues without worrying about setting a an exponential bomb off. All projects have their problems. It's much better for both the project and community as a whole if these problems aren't broadcast worldwide. We used to use personal emails or MSN, this just takes over that role making it easier and quicker. I'll give you an example, take the recent allegations of leaked MS source code in the ReactOS repository. These allegations completely were untrue, however as soon as this found it's way onto the public mailing list, drastic and maybe over reactive actions were taken. This email has single handidly stopped all development of ReactOS for the past 2 weeks and has the potential of holding the project up for a year or two. It's safe to say the project has been in trouble of dying off completely. Now, if this mail was received privately, we could have dealt with the issue internally and avoided all this mess. Development would have continued whilst we resolved any potential issues. For the community and the project as a whole, which would you consider to be the better option? All projects have their problems, you just never hear about them because they aren't made public. There is nothing to be gained by hanging out your dirty linen in public. 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

4 3

Voting announcement: "Which way you would like ReactOS to go?"
by Aleksey Bragin 09 Feb '06

09 Feb '06

Subject: Which way you would like ReactOS to go? Proposed by: fireball Days of discussion: 7 Days of voting: 7 Proposal: Two plans for further development are being proposed, Plan A - "current", Plan B - "proposed" Rationale: - Further information is available in the Votings forum. Note to readers: Only developers can take part in the voting. Thanks, Aleksey Bragin.

1 0

RE: [ros-dev] Bug: The calculator of ROS calculates wrong
by Murphy, Ged (Bolton) 09 Feb '06

09 Feb '06

Realistically, 3 + + should give a syntax error as it's not a valid mathematical equation. Anything generated from this equation is undefined. I know some calculators use hitting the + button as a trigger to calculate anything in memory. Looking at the Windows calculator, it seems to take a number then a operand as valid syntax to use the previous number as post number. Thus '3 +' = 6 '3 -' = 0 '3 *' = 9 Any further operand cancels out the previous. Thus: '3 + + + + - - - - * * *' is equivalent to '3 *' = 9 Strange .... -----Original Message----- From: Brian [mailto:briandabrain@gmail.com] Sent: 08 February 2006 23:21 To: ReactOS Development List Subject: Re: [ros-dev] Bug: The calculator of ROS calculates wrong just a thought... shouldn't 3,+,+ in calculator produce 6... brian friend of ReactOS ************************************************************************ 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

What Happened
by Rick Langschultz 09 Feb '06

09 Feb '06

I have a question: Where is everyone on the list. I have only received a few mailing list posts in the past couple of days. I know that there has been a scandle as of late, but does that stop mailing list posting? What is the deal?

8 14

Bug: The calculator of ROS calculates wrong
by theUser BL 08 Feb '06

08 Feb '06

Is it an error of ROS or an error of WINE? The Wine-Calculator is every time one too high. 3 + 7 = 11 in the calculator and so on. But it comes already after the "+" or "*" was pressed. After [3] + [+] there stands 4 in the display. Or is it an error of QEmu? I don't know. Only to mentioned it. I know that you have at the moment no time for it, because you are in progress of oversearching your code. Greatings theuserbl

5 4

Re: [ros-dev] What Happened
by Maarten Bosma 08 Feb '06

08 Feb '06

I think the existence of this mailing list has realy been revealed on ros-dev before. Maarten Bosma Ged Murphy wrote: > Maarten Bosma wrote: > >> Rick Langschultz wrote: >> >>> I have a question: >>> >>> Where is everyone on the list. I have only received a few mailing list posts in the past couple of days. I know that there has been a scandle as of late, but does that stop mailing list posting? What is the deal? >> >> >> >> I think I can solve that puzzle. Since that scandal we got a private mailing list just for developers. ;) >> > > I don't think that was meant to be public knowledge. People will think we have something to hide now. >

1 0

Re: [ros-priv] OT: uni project
by Maarten Bosma 08 Feb '06

08 Feb '06

Ged Murphy wrote: >> good idea - a paint(brush) clone >> [..] > > Yeah, it's a nice idea. :) > Certainly worth considering. I don't think that is what ReactOS needs at it's current state. But that's just my opinion. > Other thoughts were taking on the cache manager I have heard that this is one of the hardest part of ReactOS and also the cache manager rewrite was already done so far. (However I don't know how much of it will be left after the audit.) > Keep em coming guys, I have until next Monday to decide. Maybe some kind of device driver, or a file system driver (for example Reiser4) although that is told to be hard too. Another idea of mine would be a web based job system. I think that one of the main problems of ReactOS is that we just say: "Here is the source, you can choose a part to work on. Have fun !". I know that we got Bugzilla, but you have to admit that it has not really proven to be a good place for new devs to get started. So a system, which lists tasks sorted by skills needed, would be a solution. Later such a system could be used for Bounties as well. But I don't know if it is a good project for you. Actually I just wanted to write down the idea before I forget about it again. > Thanks, > Ged. > Maarten Bosma

1 1

FixedSys-fonts
by theUser BL 08 Feb '06

08 Feb '06

As I see in ROS 0.2.9 the font in noteopad looks a lot of different to the font which Microsoft used in its Notepad. In Win95/98 Microsoft used for Notepad FixedSys as font. In WinXP it used LucidaConsole. But what is with FixedSys? Is it completly new created by Microsoft? I think no. Have a look at the PC-system font. I mean the VGA-font which you see, if you start your computer or which you see, when FreeLoader runs. The PC-system have three standard fonts. The CGA font have 8x8 pixel. The EGA-font is a little bit bigger and the VGA-font is 8x16 pixel large. Today you see nearly only the VGA-fonts. There existing also some OpenSource programs, which draws this fonts on the screen: QEmu, DosBox, freeBASIC, etc. And if you compare this font with the Win95/Win98 fixedsys font, you will see, that letters like "A" and "O" are completly the same. And the other letters have mostly only the squiggle, curlicue, flourish or how it is called erased. If you erase it on letters like "B", "D", "F", "d" and so on, then the most majority of the letters looks completly like the fixedsys font of Win95/Win98. Only the "0" and some other letters looks then different. In WinXP the FixedSys font looks now different. I think there it is a completly new creation by Microsoft. It is also smaller (I think 7x14 or so) then the old fixedsys font. But I think, if anybody want to create a fixedsys font for ReactOS, then using the PC-system-fonts and removing the protruded lines, would be a good basis for the ReactOS fixedsys font. The fixedsys font is a little bit unique. It is not a extern TrueType font. It is integrated in the system. It is also not a vector-graphic font. It exists only in one size. There existing no bold or italic version of it. And it will not be antialiased. And if you remove all fonts of the Windows-System, Windows will use the fixedsys font insted. Greatings theuserbl

1 0

Reverse Engineering Apps instead Windows
by theUser BL 08 Feb '06

08 Feb '06

Hi! I am not a programmer. So, it can be possible, that my idea is naive. You write here in the list, that the best would be, to make clean room reverse enginering, if an API isn't documented. But why you not disasseble the apps which you want to run on ROS instead of disassembling Windows? I see for it two advancements and one disadvancement. The advancements: 1. If you make clean room rev. eng., then you cut into halves the number of developer of ROS. Then only one half programs for the system. The other half writes documents. But if you disasseble the apps which running on Windows, then you are still allowed to publish the documentation of the API it used. You are not allowed to write then an application like that, what you have disassembled. But that is nothing you want. You want to write an OS, which can execute this app. And that is (hopefully) allowed. I don't know, if I am naive, but I think, if you see, that the program used a function void WindowsFunctuion (int, int, float); then you can write little test apps, with different values, to see what happens. So you don't need to disasseble Windows to look which happens. 2. If you make a clean room rev. eng. the people who write the document can make a mistake. Discribes the API wrong or not complete, so that the program which needs it still not runs. In this case the people who program, must say to the documenter, that he must do it again or better. But they can not communicate to much about it. Not to detailed. But this problem can be solved if you use the programs/drivers for Windows to disasseble insted of Windows itself. The only disadvantage I see is, that it can need more time to understand the code. If you "only" disassemble Windows, you comprehend the code in any time. But if you disassemble an app, it is at first the same. But if you have written the API for ROS and the app runs on ROS, then you must begin by zero by disassembling the next app, which don't run on ROS. And you must try to understand the code of this app and so on. So it can be possible, that this way takes longer, then clean room rev. eng. Windows direct. But I am not sure. Greatings theuserbl

1 0

RE: [ros-dev] Wine Sync
by Murphy, Ged (Bolton) 08 Feb '06

08 Feb '06

Ge van Geldorp wrote > > From: Murphy, Ged (Bolton) > > > > James Tabor wrote: > > > > > We should have Wine synced into the SVN by now. 8^) What is > > > missing or not? > > > > Gé ;) > > :) > I'm still here. AFAIK, we agreed to transfer the Wine DLLs as late as > possible. > > GvG Yeah, I recall that being the idea. I think it's more important to get base libs like CTR, kernel32, user32 and GDI32 in. Pretty much nothing will build without those, so the Wine dll's would be useless anyway. 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

RE: [ros-dev] Wine Sync
by Murphy, Ged (Bolton) 08 Feb '06

08 Feb '06

James Tabor wrote: > We should have Wine synced into the SVN by now. 8^) > What is missing or not? Gé ;) Hehe ************************************************************************ 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] Anonymous SVN
by Murphy, Ged (Bolton) 08 Feb '06

08 Feb '06

Aleksey Bragin wrote: > Hi Pavel, > currently, only audited SVN server is publically accessible, its URL > is: svn://svn.reactos.org/audited. > As for the main svn server, it has been switched off from anonymous > access, because there were concerns, that it might contain > copyrighted material. As soon as we clear up the situation, > it may be > opened to public access again. > > On Feb 8, 2006, at 1:56 PM, Pavel S. Mironchik wrote: > > > Hi, > > I wonder if any anonymous access to reactos svn exists. > > or could I get login to read svn and track chnages? For convenience, you can also track changes via the ros-diff mailing list. 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

Anonymous SVN
by p.mironchik＠sam-solutions.net 08 Feb '06

08 Feb '06

Hi, I wonder if any anonymous access to reactos svn exists. or could I get login to read svn and track chnages? -- Best regards, Pavel S. Mironchik

2 1

Wine Sync
by James Tabor 08 Feb '06

08 Feb '06

Hi, We should have Wine synced into the SVN by now. 8^) What is missing or not? Thanks, James

1 0

Can rbuild be made to work with distcc?
by Andrew "Silver Blade" Greenwood 07 Feb '06

07 Feb '06

I know I've asked about this before but - maybe I missed something or I'm stupid - I never got it working. I'd like to be able to use distcc when compiling ReactOS, if that's at all possible. When I tried, rbuild built using it, but then rbuild went on to just compile locally. It'd be great if it can be modified to make it a simple flag to pass to rbuild or the makefile or something. For working on small parts it's probably not that beneficial, but it'd make a complete recompile much faster I think :)

1 0

Re: [ros-svn] [jimtabor] 99: Add portcls to new branch.
by James Tabor 07 Feb '06

07 Feb '06

jimtabor(a)svn.reactos.org wrote: > Add portcls to new branch. > > > Added files: > trunk/reactos/drivers/sound/multimedia/ > trunk/reactos/drivers/sound/multimedia/portcls/ > trunk/reactos/drivers/sound/multimedia/portcls/portcls.c > trunk/reactos/drivers/sound/multimedia/portcls/portcls.def > trunk/reactos/drivers/sound/multimedia/portcls/portcls.h > trunk/reactos/drivers/sound/multimedia/portcls/portcls.rc > This was KISS! All stubs are based from OSR. http://www.osronline.com/ddkx/stream/pcdesign_78yv.htm Thanks, James

1 0

FreeLdr
by Samuel Bronson 04 Feb '06

04 Feb '06

I am told that the sources for FreeLdr are all okay, except for the some of the bootsectors having been pretty much just disassembled from MS's. Is this true? If so, will someone please copy them over before I die of impatiance? Its not like we need those bootsectors, anyway. I mean, a lot of us on IRC have agreed that using GRUB to load FreeLdr is probably our best bet for now, until someone gets around to customizing boot code from GRUB or FreeDOS. Anyway, we don't need to worry about that until the installation CD boots ;-). -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

1 1

Place for 'proof' code
by art yerkes 04 Feb '06

04 Feb '06

In the course of auditing isapnp, I wrote a test case that proves that switch(a) { default: printf("foo\n"); break; } While peculiar, cannot be the product of directly reverse engineering visual C or gcc output (and likely any other compiler). Is there a place we want to put such apps? -- Discordant is the murmur at such treading down of lovely things while god's most lordly gift to man is decency of mind. Call that man only blest who has in sweet tranquility brought his life to close. If only I could act as such, my hope is good. -- Aeschylus' Agamemnon (translated by H. W. Smyth)

2 2

Re: [ros-bugs] [Bug 1309] ReactOS' notepad does not show the status bar
by James Tabor 04 Feb '06

04 Feb '06

ReactOS.Bugzilla(a)reactos.org wrote: > http://www.reactos.org/bugzilla/show_bug.cgi?id=1309 > ------- Additional Comments From j_anderw(a)sbox.tugraz.at 2006-02-04 02:29 CET ------- > Created an attachment (id=675) > --> (http://www.reactos.org/bugzilla/attachment.cgi?id=675&action=view) > implements status bar for notepad > > Hi, I will keep a note on this patch, Thanks, James

1 0

Re: [ros-dev] Moving svn to another contrury or not
by Johannes Olofsson 03 Feb '06

03 Feb '06

9 8

Re: Re: [ros-dev] Moving svn to another contrury or not
by Johannes Olofsson 03 Feb '06

03 Feb '06

10 12

Re: Re: [ros-dev] Undocumented APIs
by Johannes Olofsson 03 Feb '06

03 Feb '06

Oh... I thought it might have been some kind of expression describing the feeling of "the project is going to #£€% anyway so why not move to Sweden as well..." My interpretation might have been biased by the somewhat edgy and often childish attitudes displayed in this thread lately. My opinion is that we HAVE to walk a few extra miles to regain the credability of this project. Even if this means more documentation and restrictions for the devoted practicians of reverse engineering. /Johannes Olofsson > Från: James Tabor <jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> > Till: ReactOS Development List <ros-dev(a)reactos.org> > Rubrik: Re: [ros-dev] Undocumented APIs > Datum: Wed, 01 Feb 2006 12:43:42 +0000 > Johannes Olofsson wrote: > > > > > > >>Man! Sweden here we come! > >>James > >> > > > > ?????????????????????????????????????????????????????????????????? > > Was this some kind of insult? > > /Johannes > > > WHAT? > NO! There was talk of moving the svn to Sweden. > James > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > <a > href=http://www.reactos.org/mailman/listinfo/ros-dev>http://www.reactos.org/ > mailman/listinfo/ros-dev</a>

2 1

Related to Reverse Engeneering.
by Jerry 02 Feb '06

02 Feb '06

Here is a link to my privious post dealing with reverse engeneering. http://www.reactos.org/archives/public/ros-dev/2006-February/007691.html http://www.myersbigel.com/copyright_articles/copy_article2.htm "We conclude that where disassembly is the only way to gain access to the ideas and functional elements embodied in a copyrighted computer program and where there is a legitimate reason for seeking such access, disassembly is a fair use as a matter of law"--Sega Enterprises Ltd. v. Accolade, Inc -- Listen to Americas Debate Radio at 9 o'clock eastren on Wensdays! http://radio.americasdebate.net/listen/low (Dial Up) http://radio.americasdebate.net/listen/ (BroadBand) Call in at: 1-888-DEBATE-5 1-912-342-2345 Skype: callto://americasdebate

3 3

Moving svn to another contrury or not
by Magnus Olsen 02 Feb '06

02 Feb '06

here is a letter from JvA. As most people know we have talk to move svn to another place. Dear ReactOS Crew, I spoke today with Lysators highest administrator Kalle, and he told me that there should be no problem what so ever for Lysator to host you. However, in order for us to host you we need a letter from you where you ask us to host you, and specify what you want to use the server for. This letter is needed for bureaucratic reasons. The root group needs to officially grant you the right to be hosted in our server hall, and marked as a Lysator-project. What the root group wants to know is what you intend to use the server for and what ports you need open in the firewall. The security rules in Lysator strictly says that only Lysator members are allowed to have administrator/root accounts on the servers in the server hall. The person who would administrate your server would be me. People outside Lysator, like the ReactOS developers, are however allowed to have normal SSH-accounts. Bandwidth is not a problem. Kalle told me that Lysator has been granted a secondary gbit-connection if the current one isn't enough. By the way, the server hall has UPS:es to make sure the servers are online even if there are would be electrical difficulties. When you have had a meeting and decided what you want hosted in the Lysator server hall, send me a letter where you ask us to host you and I'll give it to Kalle. When you officially have been granted to be hosted by us, you need to supply us with a server, 1U or 2U. If you want, I could build it for you here in Linköping if you collect money and let GreatLord buy the parts. The OS that the server would run would be Gentoo Linux. I will of course install Apache, SVN, cross-compile GCC and whatever you need on the server for you. Best regards, Fredrik Smedberg (JvA)

4 3

RE: [ros-dev] Moving svn to another contrury or not
by Murphy, Ged (Bolton) 02 Feb '06

02 Feb '06

Rick Langschultz wrote: > I think ReactOS should have no Reverse Engineered code within it. > Reverse Engineering could be bad for the projects publicity and code-base. > I think that reverse engineering of the Microsoft Code is wrong!!! > And if programmers within this project want to reverse engineer they > should start their own projects, with their own names, and use their > own code. How would you like your product(s) to be stolen? It's not wrong, and it's not illegal. If Microsoft provided better documentation for their internal interfaces, then it wouldn't be required. Without reversing to discover how various parts work, ReactOS would struggle to make a fully compatable system. You don't think that writing an operating system to effectively clone the Windows methodologies is wrong, yet you think that reversing various parts to discover how it works is. That doesn't make sense to me. As long as there is no code copying, there is no problem. One person reverses and documents how something works, another person reads the docs and reimplements it. It's just like reading a book. It's no different than dismantling an engine, or a calculator, or a toy to understand how it works. 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

Re: Re: [ros-dev] Moving svn to another contrury or not
by Johannes Olofsson 02 Feb '06

02 Feb '06

Sorry about that, It seems like my mail-client automatically used the same style as the original mail I responded to... Regards Johannes > Från: Alex Buell <alex.buell(a)munted.org.uk> > Till: ReactOS Development List <ros-dev(a)reactos.org> > Rubrik: Re: [ros-dev] Moving svn to another contrury or not > Datum: Thu, 2 Feb 2006 14:25:18 +0000 > On Thu, 2 Feb 2006 13:37:24 +0000 (GMT) "Johannes Olofsson" > <johannes_olofsson(a)spray.se> waved a wand and this message magically > appeared: > > Your message was full of html tags. Can you make sure your mailer uses > plain text instead of html. Some of us don't use clients that likes > html, you know. > > -- > <a href=http://www.munted.org.uk>http://www.munted.org.uk</a> > "Honestly, what can I possibly say to get you into my bed?" - Anon. > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > <a > href=http://www.reactos.org/mailman/listinfo/ros-dev>http://www.reactos.org/ > mailman/listinfo/ros-dev</a>

1 0

Life after audit
by Mikhail Y. Zvyozdochkin 02 Feb '06

02 Feb '06

Hi all, Steven Edwards wrote at http://www.reactos.org/xhtml/ru/news_page_14.html: "One final note, this audit of the code is going to take a long time. It could take years, but it will happen, this project will come out better than it was before". Whether means it, what all development will be suspended for the period of audit? I understand necessity of audit, but I am afraid, that in a year the urgency of the project will catastrophically fall, and it will hopelessly lag behind from Microsoft :(. I want, that ReactOS have survived... WBR, DarkHobbit

6 6

Undocumented APIs
by Casper Hornstrup 01 Feb '06

01 Feb '06

I'd like to put this amendment to the IP policy to a vote, but first let's start with the 7 day discussion period. "If an API or a particular behaviour of an API which is part of the Windows(R) operating system is not publicly documented by Microsoft, then the API or the particular behaviour of the API may only be implemented in ReactOS if there is documentation of published software which depend on the API or the particular behaviour of the API, and which is not only distributed with the Windows(R) operating system. The documentation must be available in the repository." I argue that the more ReactOS differ from Windows, the harder it will be to prove that ReactOS is a derivative work of Windows. Med venlig hilsen / best regards Casper Hornstrup Chief Executive Officer @ Eudicon ch(a)eudicon.com / www.eudicon.com (+45) 27 29 36 20

17 44

RE: [ros-dev] Undocumented APIs
by Murphy, Ged (Bolton) 01 Feb '06

01 Feb '06

Casper Hornstrup wrote: > "If an API or a particular behaviour of an API which is part of the > Windows(R) operating system is not publicly documented by > Microsoft, then > the API or the particular behaviour of the API may only be > implemented in > ReactOS if there is documentation of published software which > depend on the > API or the particular behaviour of the API, and which is not only > distributed with the Windows(R) operating system. The > documentation must be > available in the repository." > What if a particular API is required for a particular program to work, but that API is undocumented by both Microsoft and the owner of the said program? Also, what about using code from 3rd parties which might contain undocumented API's, like Wine for instance? 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

13 23

Re: Re: [ros-dev] Undocumented APIs
by Johannes Olofsson 01 Feb '06

01 Feb '06

> > Man! Sweden here we come! > James > ?????????????????????????????????????????????????????????????????? Was this some kind of insult? /Johannes

2 1

RE: [ros-dev] Undocumented APIs
by Murphy, Ged (Bolton) 01 Feb '06

01 Feb '06

art yerkes wrote: > > Which is of course fine, but since ReactOS has no use for > it, why commit it? > > It isn't needed to meet the goals of ReactOS. > > > > Casper > > I don't agree with this sentiment at all. We've always > before been proactive > about implementing at least visible parts of the API to make > it more likely > that applications we didn't know about would have a chance to > work. I think > that's a reasonable way to work, especially if you're working > in an area you've > got a good understanding of. I completely agree with this. Some of the rules being proposed seem to be a little over cautious. This 'shake up' shouldn't put a strangle hold on the project. 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

Re: [ros-dev] Re: Undocumented APIs
by Johannes Olofsson 01 Feb '06

01 Feb '06

> Too vague in my book. I request a reformulation. I sort of get what you > try to indicate, but it's too easy to explain incorrectly and the > meaning as I understand it doesn't include enough APIs to be of any > significance to note down in the IP policy. There are also arguments > against it, like the educational purpose of being able to lecture at > universities on the subject of NT using ReactOS. Why would you want to lecture on the subject "alternative ways to implement undocumented APIs that are not used by any 3rd party software"? /Johannes Olofsson

1 0

Flow chart
by Ged Murphy 01 Feb '06

01 Feb '06

Hi all. Would someone be willing to put a flow chart together on moving code from the main branch to the audited branch. I think if something like this is put in place, it would ensure everyone was operating in the same manner. Pasted from IRC when discussing the audit methodologies: <GedMurphy> I understand what qualifies for being 'unclean' (which it seems most of ReactOS will be initially), in which case it should be placed into the intermediate repository. However it isn't clearly stated what happens then. If documentation can't be located or test cases aren't written, how is that code further analized? <sedwards> If the code is 'unclean' then someone need to mark themselves down to rewrite it on the audit page <GedMurphy> but what if it's not unclean, but there is no documentation for it? Is it automatically deemed to be unclean in that case? <GedMurphy> e.g. Exception wrote most of the original part of the network stack. I'm positive this was done in a clean manner, but where are the docs? Does he still have them? What happens if there aren't any or they have been lost? <GedMurphy> does rewriting them automatically mean that code is then ok? <GedMurphy> senario 2. No docs can be found, but someone writes some. If that code was ripped from Windows assemblies but we provide docs, that code might get through. However it doesn't get around the fact that it's been 'borrowed' from Windows dissasemblies. <GedMurphy> at what point in the audit is the code checked for similarities to the Windows counterpart, if at all? <GedMurphy> This is what I mean by set methodologies. Something should be laid down, like a flow chart I would offer to do it, but I think one of our more experienced dev would make a better job. Maybe someone who has done something like this before. I was hoping for one to follow for myself to make sure I don't drop a b*ll*ck :) Ged.

4 4

Re: [ros-dev] Undocumented APIs
by David Eckert 31 Jan '06

31 Jan '06

I agree highly with Alex, I honestly think that ReactOS has lost complete focus on what their intentions were originally, I think it is time to go into discussion regarding the re-evaluation of the projects primary goals are, this is not good if it is left unmanaged, but on the other hand, it still would be kind of neat for someone to "re-invent the wheel" Windows NT wouldn't it? ;) -- -David W. Eckert

3 2

RE: [ros-dev] GetGlyphOutline
by Murphy, Ged (Bolton) 31 Jan '06

31 Jan '06

Maarten Bosma wrote: > Why do you want to close all bugs ? Most of them will be > still vaild > after the audit. I'd say the better solution is to add them to the > patch category. I agree with Steven. This is a good time to restart bugzilla, as it was a mess. Many of the bugs are going to be invalid, or giving different results after the audit. There will also be many new bugs introduced. It's easier to just restart it than keep tabs on the old tree. We should keep better control over it next time. ************************************************************************ 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

3 2

EventLog documentation
by Saveliy Tretiakov 31 Jan '06

31 Jan '06

Hello. I've put some EventLog links on the wiki: http://www.reactos.org/wiki/index.php/EventLog

1 0

RE: [ros-dev] Undocumented APIs
by Murphy, Ged (Bolton) 31 Jan '06

31 Jan '06

D. Hazelton wrote: > Someone mentioned that regedit might be a piece of code which > is the only one > to use a function call... All modern windows releases ship > with two versions > of regedit, regedit.exe and regedt32.exe - and there have > been several > third-party replacements for regedit released. Win XP and above ship with a new regedit. Regedit.exe(win98 derivative) and regedt32.exe(crippled version for 2K) have both been dropped. 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

GetGlyphOutline
by James Tabor 31 Jan '06

31 Jan '06

Hi, I finished a fast port of GetGlyphOutline from Wine. Not too bad, no crashes. Thanks, James

5 10

RE: Ros-dev Digest, Vol 17, Issue 64
by Lucio Diaz 31 Jan '06

31 Jan '06

Dont be silly, all of you, such audit will take at least half a year and reimplementing everything will just destroy the proyect. Use your heads, you are programmers, and you fear there is leaked code, if there is any their assembly it should be similar to the windows one, so be easy: compile reactos, dissasemble it. Then dissasemble windows. Write a tool that compares dissassembled code. And you have ONLY (and is still lots of work) to compare where there are enough coincidences betwen reactos assembly and windows assembly. Once you get to those spots you only have to check if there is a logical conclusion of a sole way of doing something (like clearing a stack) or a copied code. Why hope for reactos, Lucio Diaz. --------------------------------- LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com

1 0

RE: [ros-dev] Bugzilla and Security Audit Documentation
by Murphy, Ged (Bolton) 30 Jan '06

30 Jan '06

M Bealby wrote: > Hey all, Hi Martin > I have finished my security audit of one of the pieces of code in the > new svn repository! (/base/services/tcpsvcs/) > > In my audit notes I have listed the problems by simple filename:line, > flaw, description. They are also dated. Is this the same sort of > documentation you would like in svn and bugzilla too? I think the best place for this would be bugzilla. You can group the full audit in one bug. > On that note, what is happening with bugzilla? I seem to remember > someone mentioning that someone was going to go through all the bug > reports and close any that affected non-audited code. Is this > correct? I don't know what is happening with bugzilla at the moment. We've lost WaxDragon now :( He used to take care of bugzilla, and all other things related to testing. You don't want the job, do you ?? ;) > Should I submit my bug report anyway? I'll write something > noticeable in the summary field so it is obvious it is to do with the > security audit. When you submit it, I'll try to get it fixed straight away. I expect there to be quite a few fixes as I just threw this code together quickly to give us something to test with. ;) > Are we going to implement something like Peters /documentation/ patch? > If so I will put my security auditing notes in there too. I don't see any reason to store information which is going to be fixed. Bugzilla and SVN will take care of the history for us. However if there is general audit information in there, then I think is should be treated in the same manner as the rest and stored in the respective directory accordingly. Regards, Ged. ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

2 1

New Setup system
by David Hinz 30 Jan '06

30 Jan '06

Hey guys, at first I was shocked, when I read that you want to audit all code and will have to rewrite a lot of the old code, but then I realised, that this is a great chance for making improvements. Here's one of my ideas: We could create a completely new setup, that will have a gui (not really a new idea...). But the second thing would be to create something similar to debians apt and debconf. My idea was to create a new setup, that installs ReactOS in packets, that would look a bit like this: A compressed archive (maybe bzip) that contains a folder with all the files, that need to be installed, one file that contains informations like e.g. where to put the files (%SYSTEMROOT% or %WINDIR%...) and one script file that looks a bit like a batch file. Maybe we could add a file, that contains some questions and hints, that can be interpreted by different configuration utilities. That is, what is IN these archives, in addition to this the header of the file would contain uncompressed information about the dependencies, so that they are easier to read. All this would give us some big advantages. For example we would be able to create different distributions and repositories. Companies would be able to have a mirror of our repository and could additionally have their own repositories, whose files depend on ours. This would ease deployment in big companies and would be a big advantage compared to Microsoft, as everything happens completely unattended, even if you upgrade from ReactOS 1.0 to 3.0. I'm looking forward to read what you think about my idea. Greets, David Hinz

11 20

RE: [ros-diffs] [martinf] 33: import the lean explorer branch into thenew repository
by Casper Hornstrup 30 Jan '06

30 Jan '06

If you want to use Subversion's merging abilities then you need to copy this from trunk. Casper

1 0

NTOSKRNL Audit
by Ge van Geldorp 29 Jan '06

29 Jan '06

I've made a start with the audit of NTOSKRNL. The page http://www.reactos.org/wiki/index.php/Ntoskrnl_audit contains a list of all the public (either exported or syscall) routines of our ntoskrnl.exe, with a template to fill in the audit metrics which were proposed. I already checked the documentation status of all routines. GvG

1 0

Bugzilla and Security Audit Documentation
by M Bealby 29 Jan '06

29 Jan '06

Hey all, I have finished my security audit of one of the pieces of code in the new svn repository! (/base/services/tcpsvcs/) In my audit notes I have listed the problems by simple filename:line, flaw, description. They are also dated. Is this the same sort of documentation you would like in svn and bugzilla too? On that note, what is happening with bugzilla? I seem to remember someone mentioning that someone was going to go through all the bug reports and close any that affected non-audited code. Is this correct? Should I submit my bug report anyway? I'll write something noticeable in the summary field so it is obvious it is to do with the security audit. Are we going to implement something like Peters /documentation/ patch? If so I will put my security auditing notes in there too. Cheers, Martin

1 0

Pathcomments corrected
by Jack Bane 29 Jan '06

29 Jan '06

Corrected some "old-style" file path-comments JB

1 0

TLD documentation diff
by Peter Ward 29 Jan '06

29 Jan '06

Index: documentation/README =================================================================== --- documentation/README (revision 0) +++ documentation/README (revision 0) @@ -0,0 +1,11 @@ +This is the documentation directory for the ReactOS project. + + +Directory Layout: + +api\ : Documentation for various APIs. +articles\ : Howto's, Articles and related documentation. +audit\ : Documentation about and gathered by the audit. +reverse.engineering\ : Clean-Room effort documentation. + : _Only_ human language and pseudo-code documentation is allowed here. +

1 0

Proposal for a new "Documentation Management" group
by Wierd_w 29 Jan '06

29 Jan '06

Just an idea to kick around-- With the recent issues of reverse engineering, and our new-- extra stern-- IP policy, it appears that "cleanroom implementation" (US style) is going to be very strictly adhered to. This raises a few concernes to me, even though I dont develop code. 1) The developers that decide they will become(Stay) reverse-engineers are going to have a great deal on their plate allready. Not only will they have to decompile proprietary binaries, but they will also have to make documentation about the functions within those binaries. Asking them to manage the collective work of both themselves and other reverse engineers is asking too much. 2) Implementors are not allowed to have direct communication with reverse engineers, under US style CleanRoom implementation practices. So, I propose a new group classification, with the purposes of 1) Organizing, catalogueing, and possibly correcting (For spelling, and other grammaticals) the whitepaper documentation produced by the reverse engineers. 2) Offering the functional service of communicating with the reverse engineers any objections, or concerns the implementors might have. (EG, "XXXX XXXX does XXX XXX by YYYYY" is not sufficent to explain what is going on, can I get a better description?", the documentation manager group would contact the reverse engineer in question, and ask them to make an adendum to their documentation to address this issue, and would then contact the implementor after such addendum(s) have been completed, and filed.) This group would thus have responsibilities simmilar to "Editor", "Librarian", and "Secretary", which is why I propose the generic name "Documentation Manager(s)." If there is allready such a position/group, I withdraw the proposal. Otherwise, I dont see how we could really hope to pull this off without dedicated individuals on this task. (PS, having "non-Coders" on this taskforce would probably alleviate any allegations of contamination between reverse engineers and Implemntors, in that it is unlikely that the secretary in question would understand a very technical request to begin with, and thus be unable to pass on any such complicated requests in their duties as secretary. It would also give some really strong enthusiasts something to do-- All you need are clerical and communication skills.) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Samba 4.0TP (Second Post)
by Rick Langschultz 28 Jan '06

28 Jan '06

Has anyone checked out the Samba 4.0 Tech Preview? I think the NTVFS folder includes code that allows another FS to act like NTFS. But take a look and tell me if integration to ReactOS would be a good idea.

1 0

ntdocs diff
by Jerry 28 Jan '06

28 Jan '06

Please ignore my last diff; this is an improved version. This diff sets up a directory (ntdocs) where documention and test cases and be put. I sugest that the tree for this dir should mirror the actual code base for ease of use. Thanks. Index: ntdocs/readme.txt =================================================================== --- ntdocs/readme.txt (revision 0) +++ ntdocs/readme.txt (revision 0) @@ -0,0 +1,6 @@ +This directory contains the documentation for Reactos (test cases and the like). Please do NOT put actual code here. +Just enough to implement it. Only human lanuage and puedo-code is allowed here. If you reversed engeneered, it please keep the policy and DO NOT implement it. + +The tree layout for the docs should mirror that of the actual code tree for ease of use. + +Thanks. \ No newline at end of file

2 1

How to audit.
by Jerry 28 Jan '06

28 Jan '06

I think we need to be more organized in this endeavor. We need to decided who will look at chuck of code, so that the process goes faster. I suggest that we pair up into two person teems whose responsibility is to decide if a certain group of code it dirty or not. These teems will then look at their area of code systematicly, deciding if part or alll of the code they come across is dirty. All the clean code will then be put into the audited trunk, then the stripped stub of the functions that were dirty.

1 0

RE: [ros-diffs] [chorns] 11: Document rbuild
by Ge van Geldorp 28 Jan '06

28 Jan '06

> From: chorns(a)svn.reactos.org > > Document rbuild > Property changes on: trunk/reactos/tools/rbuild > Name: svn:doc It seems your brain is pre-wired to type "svn:..." after "propset" :-) GvG

2 1

what about stuff we share with Wine?
by Jonathan Wilson 28 Jan '06

28 Jan '06

Are we going to have to audit that too? Is there a risk that Wine might contain compromised code somehow?

2 1

Propose standards for the audit
by Steven Edwards 28 Jan '06

28 Jan '06

Hello, Ok here are some proposed ground rules for the audit. Mostly thanks to Art and Alex. We are still open for debate on this 0. Everyone needs commit all documentation you have reverse enginered something so that someone else can reimplement it. Filip has some nice docs at http://www.volny.cz/xnavara/doc_trash/ There is stuff I posted on the Wiki and Bugzilla. Can someone make a api-documentation module in svn and commit all this stuff to there? 1. A function is deemed to have been implemented in a non-clean manner if - "unknown" arguments given values - functions for which there is NO DOCUMENTATION - functions with no test cases available either in ReactOS or somewhere on the internet - functions with undocumented magic numbers - functions with excessive gotos NO DOCUMENTATION means it cannot be found on MSDN, Google, sysinternals, osronline, any book published by Microsoft Press or any other publication. 2. The following does not count - functions of 5 or less lines of code - functions for which every basic unit corresponds to a clause in the official documentation - functions which mimic those implemented in other libraries and that work similarly 3. Even if the function body is not clean, the prototype can remain. -- Steven Edwards - ReactOS and Wine developer "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

8 13

rev-doc diff.
by Jerry 28 Jan '06

28 Jan '06

I thought it would be a great idea to put all the reversed engineered documentation in a separate directory in the audited trunk. Here is the diff to set it up (attachment). Thanks. Index: rev_doc/readme.txt =================================================================== --- rev_doc/readme.txt (revision 0) +++ rev_doc/readme.txt (revision 0) @@ -0,0 +1,4 @@ +This directory contains the documentation from reverse engineering. Please do not put actual code here. +Just enough to implement it. If you reversed engeneered it please keep the policy and do NOT implement it. + +Thanks. \ No newline at end of file

2 2

Cleaned up skeleton?
by Jan Schiefer 28 Jan '06

28 Jan '06

Just a very, very vague question: When can the public exspect access to a ( surely very leaky ) cleaned up skeleton of ROS? I mean that we have a running system, without the unchecked ( unclean ) components, so that people can start working again on the clean code. For example: We can boot and explorer pops up. Nothing more. So we can fix bugs in NTOSKRNL, FREELDR and EXPLORER... Greetings, Jan Schiefer

3 3

Build system
by Martin Fuchs 28 Jan '06

28 Jan '06

Hi, as the repository is being set up fresh, I think this would be the best time to correct some problems with the directory layout and file naming schemes. The rbuild input files have been named "*.xml". Yes, these files are XML files. But it's not the best name for them. It would clash with XML files being used by the built applications itself. So I propose to rename all those "*.xml" files of the rbuild system to "*.rbld". What do you think about this idea? Regards, Martin

5 5

RE: [ros-diffs] [frik85] 4: import reactos.org directory
by Casper Hornstrup 28 Jan '06

28 Jan '06

This is wrong. Bugzilla is 3rd party software and needs to go to /vendor/bugzilla/current. Casper

2 1

My thoughts
by Andrew "Silver Blade" Greenwood 28 Jan '06

28 Jan '06

Personally, my main area of interest regarding the recent discussions has been that of reverse-engineering. But what I'm about to say could probably be applied to the leaked sources, too (this isn't what I'm here to discuss, however.) We all know that some bits of Windows' internals are hidden, often intentionally, and that some product may make use of certain hidden API function calls, or may interact with the system components in a way other than that described in the API reference documentation. Other times, parameters to API function calls are not clear, or not documented at all. As a result, to make something that is compatible with Windows (or at least MORE compatible), it is necessary to use alternative methods (eg: reverse engineering) to determine what an undocumented function works, how it behaves, or to investigate undocumented flags, etc. For the sake of the project, any reverse-engineering should be done as a 2-man job. It seems the case that people often take it upon themselves to do both jobs - that of the person looking at the disassembly, and that of the person writing the code. This is how I wrote most of WDMAUD.DRV. I was skeptical about the morals/legality of it at the time, but was told that it doesn't matter. As this is all now out in the open, and I've exmained the disassembly of WDMAUD.DRV, it's probably best that I continue to examine it, and document my findings, for another developer to implement later. For other modules, it depends who's comfortable doing disassembling. I'm happy to write code, and would like to do so. But I haven't the first clue about kernel-mode debugging so things like the Kernel Streaming API, I'd probably struggle with. As for the rest of the project, the impression I get is that, rather than going through the existing code and auditing it, it might be best to start over. This has disgruntled a lot of the major developers. But don't forget, when the project was in its early days it was focusing on NT4 compatibility... Not a lot worked, and there was no clear-cut development policy... Then there was an explosion of activity and we've been racing forward ever since. Some may claim we're reinventing the wheel again, but we already *have* a working kernel and this time round it shouldn't be as difficult as it was previously, provided we can use our original sources as a reference. There's all sorts of things that can be implemented from the start rather than being added on later (maybe translations? - I don't know how this works but AFAIK this was something that was discussed further along the development line.) We can focus on the current technology and not aim low (NT4.) I just think we need to have people who are good at deciphering disassembly and producing documentation, and people who can code from that documentation (or other documentation, of course.) Anyway, those are my thoughts. If any of it doesn't make sense it's because I'm tired!

2 1

Re: [ros-diffs] [ion] 8: - Update directory change in rbuild/xml files too.
by Filip Navara 28 Jan '06

28 Jan '06

1 0

New repository?
by Reuben Perelman 28 Jan '06

28 Jan '06

What's the location of the new ReactOS SVN repository? I tried 'svn co svn://svn.reactos.org', and I got an error saying that no repository existed at that address, so I'm guessing the location of the repository has moved.

2 3

Re: [ros-svn] [chorns] 1: Standard repository layout
by TwoTailedFox 27 Jan '06

27 Jan '06

... I assume SVN is starting from Scratch? On 1/27/06, chorns(a)svn.reactos.org <chorns(a)svn.reactos.org> wrote: > Standard repository layout > > > Added files: > branches/ > tags/ > trunk/ > vendor/ > > _______________________________________________ > Ros-svn mailing list > Ros-svn(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-svn > -- "I had a handle on life, but then it broke"

2 1

some more informations
by Hartmut Birr 27 Jan '06

27 Jan '06

This message has been removed. If you need to access to it please contact gvg(a)reactos.org

4 5

Big document
by David Eckert 27 Jan '06

27 Jan '06

This message has been removed. If you need to access to it please contact gvg(a)reactos.org

3 2

Reset, Reboot, Restart, legal issues and the long road to 0.3
by Steven Edwards 27 Jan '06

27 Jan '06

Hello, There has been a lot of talk about possible tainted code in ReactOS and or developers that had access to leaked Microsoft source code. This has caused a lot of speculation about the future of the ReactOS Project. I'm going to try to put those fears to rest and explain what has been going on and where we are going to go from here. There was one issue that started this discussion and it related to clean-room reverse engineering of certain code in ReactOS. Due to the fact we have developers in many different countries the term reverse engineering can mean many things to many different people. For us in the US when you speak of clean-room reverse engineering it means that one person tears apart the implementation of a device, writes documentation and another reads that documentation and implements. Other countries do not require this invisible great wall of development and allow the same person that disassembles the interface to also write the replacement implementation. Because of the confusion this has caused and the possible legal issues this could lead to we have decided to do the following. 1) Amend our Intellectual Property Policy Statement to reflect clean-room reverse engineering as meaning the US standard method for reverse engineering and make that the project requirement 2) Audit the entire source tree and rewrite all code found to have been implemented not using the US method for reverse Engineering 3) Require all developers contributing major code to accept the terms of our IP Policy Document via signature. Now as for the issue of leaked source code, I want to try to put all fears to rest. We don't know what the legal ramifications are for someone downloading and having leaked code, as the party that maintains copyright ownership of that code might still try to claim Trade Secrecy on information contained in the sources in a court of law. It is our point of view that the source code leaks of Windows have been spread to a broad enough audience that it would be impossible to claim the product is still under Trade Secrecy. Because of this we are not banning any developer who might have had access to leaked sources from contributing to ReactOS, however they are being limited as to what area they can contribute. Copyright law still applies to all leaked Windows sources and no one in ReactOS may copy code from a Windows source leak and try to apply it to code in the ReactOS tree. We know of four developers who have had access to leaked sources prior to working on ReactOS and while they no longer have copies of the source code in question, each of the developers have told us in private which sections of the sources they were exposed to. As such the project has amending the IP document as a fourth step of protection 4) any developer that had access to leaked sources is baned from contributing code to the project for any of the modules that are the same as leaked sources they examined. So to clarify that, lets say someone saw some of the leaked Windows source code in version.dll, then they would be unable to contribute code to the ReactOS project for that dll. It is our hope that a court case will arise and declare Microsoft's Windows code is no longer under Trade Secret protection so these developers who did have access to some of the leaked sources will be free to contribute again to all sections of the project. One final note, this audit of the code is going to take a long time. It could take years, but it will happen, this project will come out better than it was before. I don't believe anything anyone has done while working on this project was really wrong. Every decision has three possibilities, being moral, ethical and or legal. Sometimes the law in itself is unethical and immoral. If people made mistakes and there was a violation of the law, I question the justice of the law and or anyone that would try to prosecute any of the developers who just want the freedom to learn and create a more free system. -- Steven Edwards - ReactOS and Wine developer "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

8 8

ReactOS Project Status
by Steven Edwards 27 Jan '06

27 Jan '06

Hello, Sorry for this general email. I have gotten many personal emails about the current situation and cannot reply to all of them. In short here is the deal: There have been allegations about possible copyright and trade secret violations in the ReactOS Project. Pending a discussion with legal council, those members with SVN access who were part of private discussion and online on IRC on Tuesday Jan 24th 2006 decided by majority vote to suspend operations of public SVN, forum, discussion and email archive. Anyone with SVN write access who might have missed any of the discussion is asked to try to be on IRC today at 3PM EST (-5GMT). We are going to discuss the matter further and decide how to proceed. What started out as a question about development methods mushroomed in to a much larger issue. The question the looms before us is a simple one. If one or more developers had at any leaked source code in the past, does it taint us and the entire project in the future? It is my point of view based on the AT&T Unix case that it does not however IANAL. It is my hope the matter can be solved via a simple set of changes in our IP Policy as well as sworn affidavits by major contributors stating they do not have access to leaked sources and if they ever did, no longer possess them. Rest assured that the project will live on. Every developer I have spoken with wants the project to survive and be a success. In the meantime we are filtering email discussion on this matter because we do not want rumor and hearsay to be spread. When the time comes and we have proper legal advice we will move forward. No one is trying to hide the truth, but law regarding Copyright, Trade Secret, Patent, etc differ from one country to another and we are currently exploring what US law says regarding the situation. One final note, no one is denying that mistakes could have been made and or trying to hide it forever and pretend there is nothing going on. We just simply do not want people to be accused of breaking the law if they really did not. There is clearly some violation of our current IP policy, however depending on what the legal council suggests we will see how we move forward. Many of the core developers at some point have either violated small sections of it by mistake or prior to its ratification. -- Steven Edwards - ReactOS and Wine developer "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

4 3

RE: [ros-dev] Reset, Reboot, Restart, legal issues and the long road to 0.3
by jonwil＠tpgi.com.au 27 Jan '06

27 Jan '06

IANAL but from what I understand, there are 2 issues with using the leaked source code. The first is that it is (C) Microsoft. This can be handled like any other copyrighted material. The second is that it could be considered a trade secret. I dont know that much about trade secret law but AFAIK once something is widely distributed (like the MS 2000 & NT4 source leaks are), it cant be considered a trade secret anymore. I think that what the ReactOS team needs need is for a lawyer skilled in the area of trade secret law to answer the question as to whether the leaked MS source code is still a trade secret or not. (although unless an actual lawsuit happens that provides a usable precedent either with the leaked MS source code or a similar leak elsewhere, getting clear usable advice one way or the other might not be possible) If it is not, there is no problem with people who have seen it contributing to any part of ReactOS (as long as there is no copyright violation). If it is, then there is need to be more careful about people who have seen it contributing. -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .

1 0

Best wishes for a fresh start
by Thomas Weidenmueller 27 Jan '06

27 Jan '06

Hey devs, I hope the new rules we established will prevent something similar in the future and I really hope this project will one day succeed. It's not going to be an easy task, but it can be done. I wish you all best luck to succeed. However, the amount of effort more or less wasted, and personal reasons made me decide that it's better for me to step back for now until ReactOS some day reaches this point of maturity again. I basically don't have the resources and energy to devote so much time, again. Re-inventing the wheel already is controversial, but I personally can't do it yet another time. I've met many very talented people ever since I joined almost three years ago, so it's very sad for me to leave most of this behind. Even though there were disagreements occasionally, it was great fun for me to collaborate and create something unique and outstanding. However, I'm going to try to stay in touch at least. I encourage everyone to stay if somehow possible and rebuild ReactOS! Thanks for everything that was done for me and the countless hours of fun I had with this project. Best Regards, Thomas

1 0

NTVFS from Samba 4.0TP
by Rick Langschultz 26 Jan '06

26 Jan '06

I was wondering if NTVFS from the Samba 4.0TP would be able to be integrated with ReactOS? This might add some support for NTFS over Fat32 or like file systems...

1 0

svn: No access allowed to this repository
by Reuben Perelman 25 Jan '06

25 Jan '06

What's going on with subversion?

1 0

ROS 21010: KMODE on start of installer
by Reuben Perelman 24 Jan '06

24 Jan '06

I'm getting a KMODE_EXCEPTION_NOT_HANDLED on bootup of ROS 21010 on QEMU. Technical information: ***STOP: 0x0000001E (0xc0000005,0x7c90b49,0x0000000,0x0000000) Page Fault Exception: 14(0) Processor: 0 CS:EIP 1b:7c907b49 cr2 0 cr3 567000 Proc: 009a02a0 DS 23 ES 23 FS 3v GS - EAX: 00000000 EBX: 0000001 ECX: 0000002 EDX: 00000003 EBP: 0000000 ESI: 0000008 NTDDK: Pageable code called at IRQL > APC_LEVEL (31) Assertion 'FALSE' failed at ./ntoskrnl/ob/handle.c line 888

4 7

Another NDIS bug fix.
by Jerry 24 Jan '06

24 Jan '06

Inproved the implimentation of NdisWriteConfiguration(), by Crashfourit. Index: drivers/net/ndis/ndis/config.c =================================================================== --- drivers/net/ndis/ndis/config.c (revision 21005) +++ drivers/net/ndis/ndis/config.c (working copy) @@ -66,6 +66,18 @@ ULONG ParameterType = ParameterValue->ParameterType; ULONG DataSize; PVOID Data; + + /* + The next few lines of code before teh first if statement are used when + ParameterType equals NdisParameterHexInteger or NdisParameterInteger. + This is done so that Buff can be used beyond the switch statement. + */ + UNICODE_STRING buff; + WCHAR str[25]; + + Buff->Length=0; + Buff->MaximumLength = sizeof(str) / sizeof(str[0]); + Buff->Buffer=str; if(ParameterType != NdisParameterInteger && ParameterType != NdisParameterHexInteger && @@ -81,12 +93,29 @@ /* reset parameter type to standard reg types */ switch(ParameterType) { - /* TODO: figure out what do do with these; are they different? */ + /* + TODO: figure out what do do with these; are they different? + Done by Crashfourit + */ case NdisParameterHexInteger: - case NdisParameterInteger: - ParameterType = REG_SZ; - Data = &ParameterValue->ParameterData.IntegerData; - DataSize = sizeof(ULONG); + case NdisParameterInteger: + { + if (!NT_SUCCESS(RtlIntegerToUnicodeString( + ParameterValue->ParameterData.IntegerData, + ( ParameterType == NdisParameterHexInteger ) ? 16 : 10, + &buff)) + ) + { + *Status = NDIS_STATUS_FAILURE; + return; + } + else + { + ParameterType = REG_SZ; + Data = &Buff->Buffer; + DataSize = Buff->Length; + } + } break; case NdisParameterString:

1 0

Keyboard Lights
by James Tabor 23 Jan '06

23 Jan '06

Hi all, Has anyone noticed the keyboard lights not working. I guess sometime around first part of December. Thanks, James

3 2

Code Auditing Questions
by M Bealby 23 Jan '06

23 Jan '06

Hey all, As my exams are now over I will hopefully be having more free time available to put into ReactOS security. I would like to perform a security audit of the code base. I've jotted down a few thoughts and suggestions of mine below and would appreciate feedback on them. Methodology I hope to work on the kernel mode code first, working up through the layers up to application API level code. I feel this is the best method because, as it has been mentioned before to me on IRC / email , some functions canot check the parameters that are passed down to lower functions. I understand the following code to run in kernel mode: /lib/rtl/ /lib/string/ /lib/kjs/ /lib/freetype/ /lib/pseh/ /hal/ /drivers/ /subsys/win32k/ /ntoskrnl/ If you know of any more please let me know. I was thinking of checking out an entire svn revision and updating only after I had checked an entire library. What do other people think on this? I will predominatly be working just from the code source, but after playing around with Doxygen I have found it to be incredibly useful for quick referencing typedefs and function parameter calls. What am I looking for? I am only a single person, so code auditing will be a slow process at the moment. I wish to check for the following vulnerabilities: Incorrect null termination. Buffer overflows. Premature termination. Lack of input validation. Bad calculations. Off by one / few. Personally I feel this list of six common vulnerability types should be enough to thwart the most common of attacks, but if anyone else feels some other class of vulnerability is missing from the list please let me know. Obviously if I find any other bugs then they will be reported as well. Reporting of errors? How should I go about reporting the errors? I was previously told to report all occasions of the incorrect uses of the RtlAllocateHeap function under the same bug number (no 1110, some still unfixed). Is this the preferred method for my code auditing results? I would like to submit the bugs as quickly as possible, so I can keep my working tree as close to possible to head, but this may mean submitting multiple bug reports for the same problem. I think that the best option is to submit similar bugs in the same module under the same report, but open a new bug if the same vulnerability occurs in another module. Thoughts? These are just some of my ideas that are floating around in my head at the moment. I would welcome all feedback on this matter and I think I may create a wiki page with the same information on. Again, thoughts on this would be nice as I haven't really used wiki's before. Cheers, Martin

4 4

New patch for NDIS:config.c
by Jerry 23 Jan '06

23 Jan '06

I noticed that the implimentation of NdisReadConfiguration() is slightly off, so I fixed it. The reason why this was so is located in the diff as a comment. Thanks. Index: drivers/net/ndis/ndis/config.c =================================================================== --- drivers/net/ndis/ndis/config.c (revision 20999) +++ drivers/net/ndis/ndis/config.c (working copy) @@ -493,8 +493,17 @@ str.Buffer = (PWCHAR)KeyInformation->Data; (*ParameterValue)->ParameterType = ParameterType; - *Status = RtlUnicodeStringToInteger(&str, 16, &(*ParameterValue)->ParameterData.IntegerData); + + /* + If ParameterType is NdisParameterInteger then the base of str is decimal. + If ParameterType is NdisParameterHexInteger then the base of str is hexadecimal. + */ + if (ParameterType == NdisParameterInteger) + *Status = RtlUnicodeStringToInteger(&str, 10, &(*ParameterValue)->ParameterData.IntegerData); + else if (ParameterType == NdisParameterHexInteger) + *Status = RtlUnicodeStringToInteger(&str, 16, &(*ParameterValue)->ParameterData.IntegerData); ExFreePool(KeyInformation); if(*Status != STATUS_SUCCESS)

1 0

Re: [ros-svn] [weiden] 20972: fixed compiling
by James Tabor 22 Jan '06

22 Jan '06

weiden(a)svn.reactos.org wrote: > fixed compiling > > > Updated files: > trunk/reactos/lib/gdi32/objects/font.c > Oops, sorry about that, thanks, James

1 0

Re: [ros-diffs] [greatlrd] 20960: corret a member name in DD_SURFACECALLBACKS so it is same as ddk
by Royce Mitchell III 21 Jan '06

21 Jan '06

greatlrd(a)svn.reactos.org wrote: >corret a member name in DD_SURFACECALLBACKS so it is same as ddk > >Modified: trunk/reactos/w32api/include/ddk/ddrawint.h > > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/w32api/include/ddk/ddrawint.h* > >--- trunk/reactos/w32api/include/ddk/ddrawint.h 2006-01-21 02:19:27 UTC (rev 20959) >+++ trunk/reactos/w32api/include/ddk/ddrawint.h 2006-01-21 14:22:17 UTC (rev 20960) >@@ -421,7 +421,7 @@ > > PDD_SURFCB_GETFLIPSTATUS GetFlipStatus; > PDD_SURFCB_UPDATEOVERLAY UpdateOverlay; > PDD_SURFCB_SETOVERLAYPOSITION SetOverlayPosition; > > >- PVOID Reserved; > > >+ PVOID reserved4; > > > PDD_SURFCB_SETPALETTE SetPalette; > } DD_SURFACECALLBACKS, *PDD_SURFACECALLBACKS; > > > why is this necessary?

2 1

Re: [ros-svn] [mbosma] 20952: Delete libjpeg because sedwards and greatlord thought we should wait with jpeg support until the patent expired. If someone got a different opinion please take the issue to ros-dev.
by mf 20 Jan '06

20 Jan '06

Hi folks, > Delete libjpeg because sedwards and greatlord thought we should wait with jpeg support until the patent expired. If someone got a different opinion please take the issue to ros-dev. > > > Deleted files: > vendor/libjpeg/ I hereby "take the issue to ros-dev", because I have a different opinion. ReactOS is filled with patented (to more and lesser extent, ranging from SEH to scrollbars, I kid you not) features, and I believe it is hypocritical to simply remove one of them. I don't know the details on the libjpeg patent, but I do know that linux distributions use libjpeg as well, and I haven't seen them remove it yet. I officially request a vote to revert this commit. Thanks for reading, mf.

5 6

So long and thanks for all the code ing
by David Johnson 20 Jan '06

20 Jan '06

Does this mean the ROS is going to die a violent death? No hope for a real alternative to M$ Windoze? I am really looking forward to Version # 1.0.0 of ROS in both x86 and PPC. People we (you devs) need to stick togather. Become a team! People are counting on YOU! ROS-PPC + Open Workstation Computing platform. = Power to the People! If you have to become 90% WinOS compatable then so be it! 90% is better than 0% XP apps can be ported to ROS. Maybe GvG and WD will come back if ROS went in this direction. Port Linux GNU code if you have to. Lets get a new GUI and a Integrated sound system. Use a open file system not FAT. Write a translator for FAT. -- David Johnson Voice Talent http://www.davefilms.us DaveFilms Digital Media - Audio [TM] Producer , Writer, Production Director/ Designer

3 3

Re: Bye bye (Lucio Diaz)
by Lucio Diaz 20 Jan '06

20 Jan '06

The solution is quite easy, is Harmut believes the code could have implemented another way, unrelated to the microsoft way, i propouse that Alex gives him the documentation and Harmut does write the code. Either if Harmut manages to make a quite diferent code for that piece of reactos, or is proved that there is no other way of writing the code Reactos developers can be safe about that particular code. And just an advice, it seems you MUST meet each other face to face, to know each other (a few beers would help) and get a working relationship.I believe there is no need of theatral posts and the such, disagreements is habitual when there is more that one person, but flaming, bashing or threatening is not the solution. Talking is. Take it easy, Lucio Diaz. ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com

1 0

Bye bye
by Hartmut Birr 20 Jan '06

20 Jan '06

Hi, I'm leaving the ReactOS project. The goals of some developers don't match my goals. Bye bye Hartmut

18 38

Re: [ros-dev] Bye bye
by Radovan Skolnik 19 Jan '06

19 Jan '06

Gentlemen, I'd never thought I'd take part in such a debate. Let me comment from a position of someone who's been folowing this project with great anticipation and high hopes. First of all I must say Alex's work and commitment to the project is outstanding. Maybe it is that he somehow makes his work most visible (I'm not trying to diminish the great work that all contributors have done). However the discussion here is about something else. I do not think the discussion should be going along the lines if things can be done any other way or not. Also I wouldn't think that what someone called 'intent' is the most important thing (it maybe would be if it saved lives of people). The thing here is not about whether Alex understands the code he put into SVN (extensively) commented. Let me provide an example here on a bit different level: suppose I like what a commercial(!) Java (or any other decompilable language) program does and decide to implement an open-source implementation. Would it be acceptable if I used decompiler to produce a readable code, study it, understand it, copy and paste those decompiled sources into my project and comment it extensively? I do not think so. The argument of understanding the code is irrelevant in this case as it is irrelevant in ReactOS's case. Is there so much difference between decompiled Java source code and disassembled binary (especially when the source has been assembly probably)? The issue here is about the method and I believe (and that makes me sad) the method Alex used was against the law and no good intent can change that. I think copy-and-paste is illegal under any circumstances (I am strong oponnent of American patent law). I wish very much that Alex and Hartmut as well continue to work on this project and we see a day when it becomes an alternative to Windows. But this case puts the project into big danger in my opinion. Just my 2cents. Best regards Radovan Skolnik

1 0

Recent Developments
by M Bealby 19 Jan '06

19 Jan '06

Recent developments have been quite heated recently, and I would just like to add in some of my own opinions. If code was directly copied from Windows then it should be removed. Period. This is against the aims and charter of this project. If Windows was only disassembled to gain information on how it works then I think this falls under fair use. Whether a spec should have been written and another person implement the spec is a topic which I'm sure will be discussed for a while to come. This is my point of view on the matter and I will not discuss it further. It is unfortunate that WaxDragon is also leaving the project, I'm sure he will be missed. But people do have lives to lead as well. I'm sure that in the future I will have to leave the ReactOS project too, and probably for the same reasons, such as family and work. Ideally I would like all developers / testers and other contributers to stay with the project, but I understand that this isn't feasible and I respect them for what they have contributed during their lifetime with the project. I devote some of my spare time to the ReactOS project for two main reasons: 1. I wish to learn more about operating system development. 2. I wanted to practice my code auditing and security skills on a project that was of a size that was not too large and mature (e.g. Linux), while not being so small to be insignificant (various other home-brew OSs). Number one is coming along nicely as I'm learning about various topics such as memory management and how drivers work. Number two is coming along as well, although much slowly as code auditing a fast moving project such as this is very time consuming and I have been very busy lately. I currently see ReactOS at the same stage of Linux in the mid nineties. People run it, play with it and contribute to it. The size of this group of people is not large, but they are usually technically minded and their number is sufficient for the project to grow and continue. Development is happening at a fast pace and keeping up can be time consuming at the moment. Lets not try and loose our drive and ambition here. You have implemented a fairly significant amount of the Windows operating system in a relatively short amount of time. You have contributed code to other projects such as WINE. You have a large number of applications that can already run on the system. You have achieved a lot, don't stop now. I think that ReactOS is at a critical stage in development and once is becomes a little more stable we will see a large increase in the number of users beta testing and trying it out. I wish the ReactOS project to succeed and it is something that I think will occur eventually. To all of ReactOS' developers, testers and supporters: You are doing a great job, don't stop now. Cheers, Martin

1 0

'Tis the season
by WaxDragon 19 Jan '06

19 Jan '06

I hereby resign from the position of Testing Coordinator. Casper, could you please disable my svn account? I am leaving for a variety of reasons. First of all, I wish to spend more of my precious free time with my family. Second, work has become more demanding of my time. There are many other reasons, including the way major project issues are handled, and the fact I have not been able to keep up with the testing and improvements I wished to implement. This decision has been a long time coming. It's been great getting to know the ReactOS developers and community, and have learned a great deal from many of you. I will still stop in IRC occasionally, and will continue to follow the project. I think the Testing Coordinator position is a very important position, and it needs to be filled. I feel that I was able to make a direct impact on the quality of ReactOS, even though I am not a real developer. I am willing to provide assistance and information to anyone who wishes to step up to the position. KEEP FILING BUGS! Andrew Munger (WaxDragon)

4 3

Where is SVN
by wac 19 Jan '06

19 Jan '06

Hi folks: I was trying to update mi local mirror and fuond that the SVN server is no longer the same. Wich is the new Address. Thanks in advance Regards Waldo Alvarez On 1/16/06, Richard <eek2121(a)comcast.net> wrote: > > I think it's time for me to hit up bugzilla, anyways, Firefox setup from > mozilla.com no longer works, it just dies, and the 'get firefox' link > results in an access denied in the middle of FF setup. > > Every 3rd or 4th boot ROS also does not have a mouse pointer. It may be > frozen, i can't tell. > > Regressions...Regressions...Regressions... > Richard > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

4 4

was bye bye
by Hartmut Birr 18 Jan '06

18 Jan '06

Hi, many people mailed to me directly. Sorry, If I didn't answered all of them. Sorry if I only answer in the evening (EU). I've a day-job and my WAF doesn't like ReactOS really. - Hartmut

1 0

Enough is enough
by Ge van Geldorp 17 Jan '06

17 Jan '06

I think having to debug Alex's latest breakage (bugcheck at the end of 2nd stage setup) so I can continue debugging one of his earlier breakages (bug 1263) is asking just a bit too much. I'll go do something non-ReactOS related for the next couple of days. GvG

3 5

Another bug...
by Richard 17 Jan '06

17 Jan '06

I think it's time for me to hit up bugzilla, anyways, Firefox setup from mozilla.com no longer works, it just dies, and the 'get firefox' link results in an access denied in the middle of FF setup. Every 3rd or 4th boot ROS also does not have a mouse pointer. It may be frozen, i can't tell. Regressions...Regressions...Regressions... Richard

1 0

uhhh...
by Richard 17 Jan '06

17 Jan '06

When you click 'view GPL' for second stage setup, a license agreement comes up for something called Gnomovision. This should not be the case. I would change it myself but i don't have my svn password handy. Richard

1 0

Strange Stretch Problem
by James Tabor 17 Jan '06

17 Jan '06

Hi all, Can anyone see the problem with this picture? Every time I move the window, it looks like back behind the window, it gets redrawn. Thanks, James

4 8

Bug in KiFastCallEntry
by Hartmut Birr 16 Jan '06

16 Jan '06

Hi, it seems we have a little bug in KiFastCallEntry. It is initialized a trap frame on the stack. It is a trap frame without the v86 segment registers. ESP points to TSS->ESP0 - sizeof(KTRAP_FRAME) + 16. 16 for the missing v86 segment register. ESP is compared with KTHREAD->InitialStack - 0x29c. 0x29c is equal to sizeof(FX_SAVE_AREA) + sizeof(KTRAP_FRAME). If the compare operation fails, it is called BadStack which results in a v86 invalid opcode exception. To bypass this bug, there is added a value of 0x10 to TSS->ESP0 in Ke386InitThreadWithContext. A friend of me has looked to WinXp. He has found a piece of code which is an exact copy of BadStack and he has found a piece of code which looks like this: _KiFastCallEntry: ... /* Use the thread's stack */ mov ebp, [esi+KTHREAD_INITIAL_STACK] ... /* Make space for us on the stack */ sub ebp, 0x29C /* Write the previous mode */ mov byte ptr [esi+KTHREAD_PREVIOUS_MODE], UserMode /* Sanity check */ cmp ebp, esp jnz BadStack ... - Hartmut

1 0

WMF Bug / SetAbortProc
by M Bealby 16 Jan '06

16 Jan '06

In case you've had you're head in the sand recently I'm sure you must know about the recent WMF bug found in all recent versions of Windows. The vulnerable function is in SetAbortProc and can be called from a malicious WMF file as they include executable code by definition. Windows automatically runs this a WMF file when previewing / displaying - including from a web page! WINE is also vulnerable, and still is. However, from a brief look at my svn repo I think ReactOS is safe. SetAbortProc is in gdi32.dll, and our version is well out of sync with WINE. I'm not sure if this is intentional (I don't know which dll's we share directly), but whoever implements this function must be very careful. More info at: http://www.microsoft.com/technet/security/bulletin/ms06-001.mspx They also have a patch there so anyone running Windows on their machine is recommended to patch it immediately. Cheers, Martin

4 3

Re: [ros-diffs] [ion] 20911: - Fix some nasty context switch bugs:
by Hartmut Birr 16 Jan '06

16 Jan '06

ion(a)svn.reactos.org wrote: > - Fix some nasty context switch bugs: > * We did not update the KPCR's stacklimit/initialstack with the new thread's stacklimit/initialstack. > * We always assumed V86 frame bias in KeInitializeThreadContext. > * We did not properly update ESP0 during context switch, to make space for the NPX frame and V86 bias. > * We did not update fs:18h to point to the new TEB. > * We did not clear out GS when switching processes, nor update the TSS's cr3. > * If a new LDT was being updated, we over-wrote EBP (which was supposed to point to the TSS) by the GDT pointer. > * We used a push/pop esp0 hack which hid the fact we never updated esp0. > Modified: trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S > Modified: trunk/reactos/ntoskrnl/ke/i386/thread.c > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S* > @@ -114,10 +114,6 @@ > > *--*/ > .globl @KiSwapContextInternal@0 > @KiSwapContextInternal@0: > > -#ifdef KDBG > - //jmp SaveTrapFrameForKDB > -SaveTrapFrameForKDB_Return: > -#endif > > > /* Get the PCR. It's faster to use ebx+offset then fs:offset */ > mov ebx, [fs:KPCR_SELF] > @@ -132,24 +128,36 @@ > > cli > > /* Save the initial stack in EAX */ > > - mov eax, [edi+KTHREAD_INITIAL_STACK] > > + mov eax, [esi+KTHREAD_INITIAL_STACK] > Now eax points to the trap frame of the thread we will switch to. > > > + /* Save the stack limit in ecx */ > + mov ecx, [esi+KTHREAD_STACK_LIMIT] > + > + /* Make space for the NPX Frame */ > + sub eax, NPX_FRAME_LENGTH > + > + /* Set the KPCR stack values */ > + mov [ebx+KPCR_INITIAL_STACK], eax > + mov [ebx+KPCR_STACK_LIMIT], ecx > + > > #ifdef CONFIG_SMP > /* Save FPU state if the thread has used it. */ > > + mov ecx, [edi+KTHREAD_INITIAL_STACK] > + sub ecx, NPX_FRAME_LENGTH > > mov dword ptr [ebx+KPCR_NPX_THREAD], 0 > test byte ptr [edi+KTHREAD_NPX_STATE], NPX_STATE_DIRTY > jz 3f > cmp dword ptr _KeI386FxsrPresent, 0 > je 1f > > - fxsave [eax-SIZEOF_FX_SAVE_AREA] > > + fxsave [ecx] > > jmp 2f > 1: > > - fnsave [eax-SIZEOF_FX_SAVE_AREA] > > + fnsave [ecx] > > 2: > mov byte ptr [edi+KTHREAD_NPX_STATE], NPX_STATE_VALID > 3: > #endif /* CONFIG_SMP */ > > - > > + > > /* Save the stack pointer in this processors TSS */ > mov ebp, [ebx+KPCR_TSS] > > @@ -158,12 +166,17 @@ > > jnz NoAdjust > The compare operation uses eax which points to the thread we will switch to. We must use the trap frame from the thread we will switch from. > /* Bias esp */ > > - //sub dword ptr ss:[ebp+KTSS_ESP0], KTRAP_FRAME_V86_GS - KTRAP_FRAME_SS > > + sub eax, KTRAP_FRAME_V86_GS - KTRAP_FRAME_SS > Eax points to the wrong stack. See above. > > NoAdjust: > > - /* Push ESP0 Value */ > - push ss:[ebp+KTSS_ESP0] > > > > + /* Set new ESP0 */ > + mov [ebp+KTSS_ESP0], eax > Now, we are using the wrong kernel stack on the next exception. - Hartmut

1 0

Revision 20911 Boot Problems
by James Tabor 16 Jan '06

16 Jan '06

Hi all, WaxDragon gets this, (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (./lib/advapi32/service/scm.c:2035) dwBufSize: 0 (subsys/system/services/rpcserver.c:1759) ScmrStartServiceW() called (ntoskrnl/ke/i386/v86m.c:678) V86GPF unhandled (was cf) Entered debugger on last-chance exception number 14 (Page Fault) Memory at 0xf000e739 could not be written: Page not present. kdb:> bt Eip: <ntoskrnl.exe:65a69 (ntoskrnl/ke/i386/v86m.c:383 (KeV86GPF))> Frames: <ntoskrnl.exe:65d92 (ntoskrnl/ke/i386/v86m.c:791 (KeV86Exception))> <ntoskrnl.exe:62a1f (ntoskrnl/ke/i386/exp.c:514 (KiTrapHandler))> <ntoskrnl.exe:64cb1 (ntoskrnl/ke/i386/trap.s:151 (KiTrapProlog2))> <00000c33> kdb:> I get this, (lib/ntdll/ldr/utils.c:1190) LdrGetExportByName(): failed to find mxdMessage (lib/ntdll/ldr/utils.c:2015) Failed to create or open dll section of 'msacm.drv' (Status c0000135) (lib/ntdll/ldr/utils.c:2015) Failed to create or open dll section of 'midimap.dr v' (Status c0000135) (./subsys/win32k/ntuser/class.c:137) Failed to lookup class atom (ClassName 'SHE LLDLL_DefView')! (ntoskrnl/ke/i386/v86m.c:678) V86GPF unhandled (was ec) Entered debugger on last-chance exception number 14 (Page Fault) Memory at 0xdeadbeef could not be written: Page not present. kdb:> bt Eip: <ntoskrnl.exe:65aa9 (ntoskrnl/ke/i386/v86m.c:383 (KeV86GPF))> Frames: <ntoskrnl.exe:65dd2 (ntoskrnl/ke/i386/v86m.c:791 (KeV86Exception))> <ntoskrnl.exe:62a5f (ntoskrnl/ke/i386/exp.c:514 (KiTrapHandler))> <ntoskrnl.exe:64cf1 (ntoskrnl/ke/i386/trap.s:151 (KiTrapProlog2))> <00003443> <00000000> kdb:> Second reboot it worked after booting linux than reboot warm, third reboot by power on reset, (ntoskrnl/ke/i386/v86m.c:678) V86GPF unhandled (was ee) Entered debugger on last-chance exception number 14 (Page Fault) Memory at 0xdeadbeef could not be written: Page not present. kdb:> bt Eip: <ntoskrnl.exe:65aa9 (ntoskrnl/ke/i386/v86m.c:383 (KeV86GPF))> Frames: <ntoskrnl.exe:65dd2 (ntoskrnl/ke/i386/v86m.c:791 (KeV86Exception))> <ntoskrnl.exe:62a5f (ntoskrnl/ke/i386/exp.c:514 (KiTrapHandler))> <ntoskrnl.exe:64cf1 (ntoskrnl/ke/i386/trap.s:151 (KiTrapProlog2))> <00002eee> <00000000> kdb:> I can repeat this over and over with real hardware, Thanks, James

3 2

Listing function prototypes
by M Bealby 16 Jan '06

16 Jan '06

Hey everyone, just a quick question. Does anyone know of an existing application that will accept a bunch of header files as input and output a list of function prototypes? It would really help with my code auditing as I'm spending a long time assembling them by hand and it takes a long while. Cheers, Martin

3 3

Re: [ros-svn] [weiden] 20891: disable starting lsass.exe for now
by Thomas Weidenmueller 15 Jan '06

15 Jan '06

weiden(a)svn.reactos.org wrote: > disable starting lsass.exe for now It seems that rpcrt4.dll has a bug that massively leaks threads in an rpc server. It seems that it leaks one thread per request. - Thomas

2 1

Re: [ros-diffs] [ion] 20887: - Update KeContextToTrapFrame to support separate ContextFlags parameters in the scenario where we want to convert more then the Context's flag specify
by Thomas Weidenmueller 15 Jan '06

15 Jan '06

ion(a)svn.reactos.org wrote: > + Context->ContextFlags &= (~CONTEXT_EXTENDED_REGISTERS) | CONTEXT_i386; This looks a bit strange... - Thomas

2 1

Re: [ros-diffs] [weiden] 20864: make the initial kernel_stack large enough to have enough space for the fx savings area
by Hartmut Birr 15 Jan '06

15 Jan '06

weiden(a)svn.reactos.org wrote: > make the initial kernel_stack large enough to have enough space for the fx savings area > Modified: trunk/reactos/ntoskrnl/ke/i386/main_asm.S > Modified: trunk/reactos/ntoskrnl/ke/i386/thread.c > Modified: trunk/reactos/ntoskrnl/ke/main.c > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/ntoskrnl/ke/i386/main_asm.S* > --- trunk/reactos/ntoskrnl/ke/i386/main_asm.S 2006-01-14 19:45:50 UTC (rev 20863) > +++ trunk/reactos/ntoskrnl/ke/i386/main_asm.S 2006-01-14 20:36:01 UTC (rev 20864) > @@ -35,7 +35,7 @@ > .m1: > /* Load the initial kernel stack */ > lea _kernel_stack, %eax > > - add $0x1000, %eax > > + add $0x2000, %eax > > and $0xFFFFE000, %eax > add $(0x3000 - SIZEOF_FX_SAVE_AREA), %eax > movl %eax, %esp > > ------------------------------------------------------------------------ I think the change in all 3 files is wrong. There was a bug in main_asm.S. The code to align the stack must be: .m1: lea _kernel_stack, %eax test $0xFFF, %eax jz .m2 and $0xFFFFF000, %eax add $0x1000, %eax .m2: add $(0x3000 - SIZEOF_FX_SAVE_AREA), %eax movl %eax, %esp - Hartmut

2 1

New Diff, adds more debug print outs.
by Jerry 14 Jan '06

14 Jan '06

I made a diff to add more debug print outs. I hope this group finds it usefull. Index: ntoskrnl/ldr/loader.c =================================================================== --- ntoskrnl/ldr/loader.c (revision 20851) +++ ntoskrnl/ldr/loader.c (working copy) @@ -331,6 +331,7 @@ /* Hook for KDB on loading a driver. */ KDB_LOADDRIVER_HOOK(Filename, Module); + CPRINT("Driver Load Success: %wZ\n", Filename); return(STATUS_SUCCESS); } Index: drivers/net/ndis/ndis/miniport.c =================================================================== --- drivers/net/ndis/ndis/miniport.c (revision 20851) +++ drivers/net/ndis/ndis/miniport.c (working copy) @@ -1414,7 +1414,8 @@ if (NdisStatus != NDIS_STATUS_SUCCESS || SelectedMediumIndex >= MEDIA_ARRAY_SIZE) { - NDIS_DbgPrint(MIN_TRACE, ("MiniportInitialize() failed for an adapter.\n" )); + NDIS_DbgPrint(MIN_TRACE, ("MiniportInitialize() failed for an adapter. NdisStatus = 0x%00000000x; %d >= %d \n", + NdisStatus, SelectedMediumIndex, MEDIA_ARRAY_SIZE)); return (NTSTATUS)NdisStatus; }

1 0

Re: [ros-svn] [gedmurphy] 20836: some new toolbar icons
by Martin Fuchs 14 Jan '06

14 Jan '06

Hello Ged, > some new toolbar icons > > Updated files: > trunk/reactos/subsys/system/explorer/res/toolbar.bmp Please use only toolbar bitmaps with 15 pixels height, not 16 ! Regards, Martin

1 0

internal compiler error
by Hartmut Birr 14 Jan '06

14 Jan '06

Hi, Does somebody see this error? - Hartmut gcc -c hal\halx86\mp\processor_mp.c -o .\up\obj-i386\hal\halx86\mp\processor_mp.o -Ihal\halx86\include -Intoskrnl\include -D_DISABLE_TIDENTSSMP -D_NTHAL_ -D__USE_W32API -I. -Iinclude -Iinclude\reactos -Iinclude\libs -Iinclude\drivers -Iinclude\subsys -Iinclude\ndk -Iw32api\includ\include\crt -Iw32api\include\ddk -D_M_IX86 -D_X86_ -D__i386__ -D_REACTOS_ -DDBG -DKDBG -Wall -Wno-strict-aliasing -ftracer -momit-leaf-fram-mpreferred-stack-boundary=2 -Wpointer-arith -g -pipe -Werror -D_SEH_NO_NATIVE_NLG hal\halx86\mp\mpconfig.c: In function `HaliScanForMPConfigTable': hal\halx86\mp\mpconfig.c:563: internal compiler error: in cfg_layout_merge_blocks, at cfgrtl.c:2631 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.mingw.org/bugs.shtml> for instructions. _make: *** [.\up\obj-i386\hal\halx86\mp\mpconfig.o] Error 1 _make: *** Waiting for unfinished jobs.... gcc (GCC) 3.4.2 (mingw-special) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

4 4

Screen Shot for Real Hardware Was: [ros-kernel] David Recent Video Card Support Changes
by James Tabor 14 Jan '06

14 Jan '06

Hi All! It is time to Implement Screen Shot for real hardware! Who is up to it? 8^D James Oldies but Gold'ies Filip Navara wrote: 03/08/04 20:44 > James Tabor wrote: > >> Filip Navara wrote: >> >>> I cheated, because I used virtual machine with emulated S3 card, but >>> it looks same on real HW. If you need a screenshot feature, I'll try >>> find on of my old patches that saves screenshots to files and adapt >>> it for the current CVS. >>> >>> Regards, >>> Filip >>> >> Ya! A good work around hack is good! If you can do so. >> Thank, >> James > > > Here it is. Few notes: > 1) Beware, it's hack! > 2) It's a not little hack, it's a big hack! > 3) Saves the screenshot to c:\reactos\screenshot.bmp. > 4) Press ALT-PRINTSCREEN in any usual window (not console) to take the > screenshot. > > - Filip > > > ------------------------------------------------------------------------ > > Index: drivers/video/videoprt/videoprt.c > Index: lib/user32/windows/defwnd.c > =================================================================== > RCS file: /CVS/ReactOS/reactos/lib/user32/windows/defwnd.c,v > retrieving revision 1.124 > diff -u -r1.124 defwnd.c > --- lib/user32/windows/defwnd.c 22 Feb 2004 23:40:58 -0000 1.124 > +++ lib/user32/windows/defwnd.c 8 Mar 2004 20:26:40 -0000 > @@ -949,10 +949,205 @@ > return GetSysColorBrush(COLOR_WINDOW); > } > > +/* > + * CreateBitmapInfoStructure > + * > + * Creates a bitmap info structure for saving a bitmap into a file. > + */ > + > +PBITMAPINFO FASTCALL > +CreateBitmapInfoStructure(HDC hDC, HBITMAP hBmp) > +{ > + BITMAP bmp; > + PBITMAPINFO pbmi; > + WORD cClrBits; > + > + /* Get the width, height and the colordepth of the image. */ > + if (!GetObjectW(hBmp, sizeof(BITMAP), (LPSTR)&bmp)) > + { > + return NULL; > + } > + > + /* Convert the color format to a count of bits. */ > + cClrBits = (WORD)(bmp.bmPlanes * bmp.bmBitsPixel); > + > + /* > + * Allocate memory for the BITMAPINFO-structure. This structure > + * contains a BITMAPINFOHEADER-structure and an array of RGBQUAD > + * datastructures. > + */ > + if (cClrBits <= 8) > + pbmi = (PBITMAPINFO)LocalAlloc(LPTR, sizeof(BITMAPINFOHEADER) + sizeof(RGBQUAD) * (1 << cClrBits)); > + else > + pbmi = (PBITMAPINFO)LocalAlloc(LPTR, sizeof(BITMAPINFOHEADER)); > + > + > + /* Initialize the fields in the BITMAPINFO-structure. */ > + pbmi->bmiHeader.biSize = sizeof(BITMAPINFOHEADER); > + pbmi->bmiHeader.biWidth = bmp.bmWidth; > + pbmi->bmiHeader.biHeight = bmp.bmHeight; > + pbmi->bmiHeader.biPlanes = bmp.bmPlanes; > + pbmi->bmiHeader.biBitCount = bmp.bmBitsPixel; > + > + if (cClrBits <= 8) > + pbmi->bmiHeader.biClrUsed = 1 << cClrBits; > + > + pbmi->bmiHeader.biCompression = BI_RGB; > + > + /* > + * Compute the number of bytes in the array of color indices > + * and store the result in biSizeImage. > + */ > + > + pbmi->bmiHeader.biSizeImage = (pbmi->bmiHeader.biWidth + 7) / 8 * pbmi->bmiHeader.biHeight * cClrBits; > + > + /* > + * Set biClrImportant to 0 to indicate that all of the device > + * colors are important. > + */ > + > + pbmi->bmiHeader.biClrImportant = 0; > + > + /* And finally return the info-structure. */ > + return pbmi; > +} > + > +/* > + * SaveBitmap > + * > + * Saves a bitmap to a specified file. > + */ > + > +HRESULT FASTCALL > +SaveBitmap(PWCHAR strFileName, HDC hDC, HBITMAP hBMP) > +{ > + HANDLE hf; > + BITMAPFILEHEADER hdr; > + PBITMAPINFOHEADER pbih; > + LPBYTE lpBits; > + DWORD dwTotal; > + DWORD cb; > + BYTE *hp; > + DWORD dwTmp; > + PBITMAPINFO pbi; > + > + pbi = CreateBitmapInfoStructure(hDC, hBMP); > + if (pbi == NULL) > + { > + return E_FAIL; > + } > + > + pbih = (PBITMAPINFOHEADER)pbi; > + lpBits = (LPBYTE)GlobalAlloc(GMEM_FIXED, pbih->biSizeImage); > + > + if (!lpBits) > + { > + return E_FAIL; > + } > + > + /* > + * Retrieve the colortable (RGBQUAD-array) and the bits > + * (array of palette indices) from the DIB. > + */ > + > + if (!GetDIBits(hDC, hBMP, 0, (WORD)pbih->biHeight, lpBits, pbi, DIB_RGB_COLORS)) > + { > + return E_FAIL; > + } > + > + > + /* Create the .BMP file. */ > + > + hf = CreateFileW( > + strFileName, > + GENERIC_READ | GENERIC_WRITE, > + (DWORD)0, > + NULL, > + CREATE_ALWAYS, > + FILE_ATTRIBUTE_NORMAL, > + (HANDLE)NULL); > + > + if (hf == INVALID_HANDLE_VALUE) > + { > + return E_FAIL; > + } > + > + hdr.bfType = 0x4D42; /* 0x42 = "B", 0x4D = "M" */ > + > + /* Compute the size of the entire file. */ > + hdr.bfSize = (DWORD)(sizeof(BITMAPFILEHEADER) + pbih->biSize + pbih->biClrUsed * sizeof(RGBQUAD) + pbih->biSizeImage); > + hdr.bfReserved1 = 0; > + hdr.bfReserved2 = 0; > + > + /* Compute the offset to the array of color indices. */ > + hdr.bfOffBits = ( DWORD ) sizeof( BITMAPFILEHEADER ) + pbih->biSize + pbih->biClrUsed * sizeof( RGBQUAD ); > + > + /* Copy the BITMAPFILEHEADER into the .BMP file. */ > + if (!WriteFile(hf, (LPVOID)&hdr, sizeof(BITMAPFILEHEADER), (LPDWORD)&dwTmp, NULL)) > + { > + return E_FAIL; > + } > + > + > + /* Copy the BITMAPINFOHEADER and RGBQUAD array into the file. */ > + if (!WriteFile(hf, > + (LPVOID)pbih, > + sizeof(BITMAPINFOHEADER) + pbih->biClrUsed * sizeof(RGBQUAD), > + (LPDWORD)&dwTmp, NULL)) > + { > + return E_FAIL; > + } > + > + > + /* Copy the array of color indices into the .BMP file. */ > + dwTotal = cb = pbih->biSizeImage; > + hp = lpBits; > + > + if (!WriteFile(hf, (LPSTR)hp, (int)cb, (LPDWORD)&dwTmp, NULL)) > + { > + return E_FAIL; > + } > + > + > + /* Now close the .BMP file. */ > + if (!CloseHandle(hf)) > + { > + return E_FAIL; > + } > + > + /* Free the memory reserved. */ > + GlobalFree((HGLOBAL)lpBits); > + > + return S_OK; > +} > + > VOID FASTCALL > DefWndScreenshot(HWND hWnd) > { > - > + HDC hScreenDC = GetDC(0), hDC; > + HBITMAP hBmp, hSaveBmp; > + > + DbgPrint("Screenshot\n"); > + hBmp = CreateCompatibleBitmap( > + hScreenDC, > + GetSystemMetrics(SM_CXSCREEN), > + GetSystemMetrics(SM_CYSCREEN)); > + hDC = CreateCompatibleDC(hScreenDC); > + hSaveBmp = SelectObject(hDC, hBmp); > + BitBlt( > + hDC, > + 0, > + 0, > + GetSystemMetrics(SM_CXSCREEN), > + GetSystemMetrics(SM_CYSCREEN), > + hScreenDC, > + 0, > + 0, > + SRCCOPY); > + SaveBitmap(L"c:\\reactos\\screenshot.bmp", hDC, hBmp); > + SelectObject(hDC, hSaveBmp); > + DeleteObject(hBmp); > + DeleteDC(hDC); > } > > LRESULT STDCALL > Index: subsys/win32k/objects/dib.c > =================================================================== > RCS file: /CVS/ReactOS/reactos/subsys/win32k/objects/dib.c,v > retrieving revision 1.42 > diff -u -r1.42 dib.c > --- subsys/win32k/objects/dib.c 19 Feb 2004 21:12:10 -0000 1.42 > +++ subsys/win32k/objects/dib.c 8 Mar 2004 20:27:00 -0000 > @@ -23,6 +23,7 @@ > #include <windows.h> > #include <stdlib.h> > #include <win32k/bitmaps.h> > +#include <win32k/color.h> > #include <win32k/debug.h> > #include "../eng/handle.h" > #include <ntos/minmax.h> > @@ -259,7 +260,7 @@ > } > > // Converts a device-dependent bitmap to a DIB > -#if 0 > +#if 1 > INT STDCALL NtGdiGetDIBits(HDC hDC, > HBITMAP hBitmap, > UINT StartScan, > @@ -278,7 +279,7 @@ > UINT coloruse) /* [in] RGB or palette index */ > #endif > { > -#if 0 > +#if 1 > BITMAPINFO Info; > BITMAPCOREHEADER *Core; > PBITMAPOBJ BitmapObj; > @@ -377,8 +378,7 @@ > Info.bmiHeader.biWidth == BitmapObj->bitmap.bmWidth && > Info.bmiHeader.biHeight == BitmapObj->bitmap.bmHeight && > Info.bmiHeader.biPlanes == BitmapObj->bitmap.bmPlanes && > - Info.bmiHeader.biBitCount == BitmapObj->bitmap.bmBitsPixel && > - 8 < Info.bmiHeader.biBitCount) > + Info.bmiHeader.biBitCount == BitmapObj->bitmap.bmBitsPixel) > { > Info.bmiHeader.biSizeImage = BitmapObj->bitmap.bmHeight * BitmapObj->bitmap.bmWidthBytes; > Status = MmCopyToCaller(Bits, BitmapObj->bitmap.bmBits, Info.bmiHeader.biSizeImage); > @@ -390,7 +390,7 @@ > } > RtlZeroMemory(&InfoWithBitFields, sizeof(InfoWithBitFields)); > RtlCopyMemory(&(InfoWithBitFields.Info), &Info, sizeof(BITMAPINFO)); > - if (BI_BITFIELDS == Info.bmiHeader.biCompression) > + if (Info.bmiHeader.biCompression == BI_BITFIELDS) > { > DCObj = DC_LockDc(hDC); > if (NULL == DCObj) > @@ -419,6 +419,22 @@ > BITMAPOBJ_UnlockBitmap(hBitmap); > return 0; > } > + if (Info.bmiHeader.biBitCount <= 8) > + { > + DCObj = DC_LockDc(hDC); > + if (NULL == DCObj) > + { > + SetLastWin32Error(ERROR_INVALID_HANDLE); > + BITMAPOBJ_UnlockBitmap(hBitmap); > + return 0; > + } > + NtGdiGetPaletteEntries( > + DCObj->w.hPalette, > + 0, > + 1 << Info.bmiHeader.biBitCount, > + (LPPALETTEENTRY)&UnsafeInfo->bmiColors); > + DC_UnlockDc(hDC); > + } > } > else > { > @@ -516,7 +532,7 @@ > if (bits && lines) > { > /* If the bitmap object already have a dib section that contains image data, get the bits from it */ > - if(bmp->dib && bmp->dib->dsBm.bmBitsPixel >= 15 && info->bmiHeader.biBitCount >= 15) > + if(bmp->dib) > { > /*FIXME: Only RGB dibs supported for now */ > unsigned int srcwidth = bmp->dib->dsBm.bmWidth, srcwidthb = bmp->dib->dsBm.bmWidthBytes; > @@ -702,6 +718,44 @@ > } > break; > > + case 8: /* 8 bpp dstDIB */ > + { > + switch(bmp->dib->dsBm.bmBitsPixel) { > + case 8: /* 8 bpp srcDIB -> 8 bpp dstDIB */ > + { > + /* FIXME: BI_BITFIELDS not supported yet */ > + for (y = 0; y < lines; y++, dbits+=dstwidthb, sbits+=srcwidthb) > + memcpy(dbits, sbits, srcwidthb); > + } > + break; > + > + default: /* ? bit bmp -> 8 bit DIB */ > + DPRINT1("FIXME: 8 bit DIB %d bit bitmap\n", > + bmp->bitmap.bmBitsPixel); > + break; > + } > + } > + break; > + > + case 4: /* 4 bpp dstDIB */ > + { > + switch(bmp->dib->dsBm.bmBitsPixel) { > + case 4: /* 4 bpp srcDIB -> 4 bpp dstDIB */ > + { > + /* FIXME: BI_BITFIELDS not supported yet */ > + for (y = 0; y < lines; y++, dbits+=dstwidthb, sbits+=srcwidthb) > + memcpy(dbits, sbits, srcwidthb); > + } > + break; > + > + default: /* ? bit bmp -> 4 bit DIB */ > + DPRINT1("FIXME: 4 bit DIB %d bit bitmap\n", > + bmp->bitmap.bmBitsPixel); > + break; > + } > + } > + break; > + > default: /* ? bit DIB */ > DPRINT1("FIXME: Unsupported DIB depth %d\n", info->bmiHeader.biBitCount); > break;

1 0

Re: [ros-dev] Patent on FAT
by James Tabor 13 Jan '06

13 Jan '06

Hi all, I think this is important to share to the discussion. From one of the developers with FreeDOS, Eric Auer. Thanks, James -------- Original Message -------- Subject: [Freedos-user] re: FAT and other file systems Date: Fri, 13 Jan 2006 17:16:34 +0100 (MET) From: Eric Auer <eric(a)coli.uni-sb.de> Reply-To: freedos-user(a)lists.sourceforge.net To: freedos-user(a)lists.sourceforge.net Hi James, > > And I think it is not more difficult to write HFS or FFS in the kernel > > of FreeDOS than ReiserFS or XFS or all the other candidates. I would like to comment this as follows: The Linux kernel modules for ext3+jbd take 131+59k of memory. Reiserfs takes 243k (243*1000 bytes, too lazy to convert to units of 1024 bytes). On the other hand, FAT core takes 38k and you use it with either MSDOS (8k) or VFAT (13k) implementations. Only the VFAT (long file name enabled) module of Linux is affected by the 3 MS patents mentioned on the MS homepage. > There is no way around this, unless someone will write a disclaimer, "Before > you install FreeDos, do you want to enable Fat32 Patented Features"? Microsoft WANTS you to believe that they patented FAT32. Actually they patented their clever but twisted way to store short and long filenames in the same directory, in a way which allows LFN-unaware operating systems to use the drive without getting confused by the LFN data and usually also without damaging the LFN data either. But you already point that out yourself: > We are > facing the same issue with Ros. When I use FreeDos, I use the basic 8.3 > file system, so I don't see that as a major problem. The point here is the > patent is about LFN, basic 8.3 is not effected. So the disclaimer would only be displayed when you install the DOSLFN package: "Install DOSLFN, which might have patent issues?". FreeDOS as a DOS operating system itself is not affected by that problem. Plus MS does have a disclaimer about their licensing, too: http://www.microsoft.com/whdc/hwdev/download/hardware/fatgen103.pdf which is more than 5 years old by now... allows you to be compatible to all their FAT (including LFN) stuff for the purpose of booting, OS installation, diagnosis, firmware, similar things. They also tell that making/installing operating systems may use all aspects of FAT. You could see this in a pessimist way (you are allowed to develop and compile your OS on a LFN enabled host system) or in a more optimistic way (your operating system itself is allowed to use LFN because it simply is an operating system). MS is targetting two groups at the moment: Vendors of USB sticks who preinstall files on their sticks, and vendors of cams and mp3 players and similar devices. FreeDOS is neither of those. But I did notice that my hardware mp3 player does not support LFN. It only shows the id3 text, if available, as "long song name", and is limited to showing the SHORT file name as song name otherwise. Looks like the vendor of the player did not want to pay MS for each device. Digicams have similar issues - they usually generate filenames like dsc0815 dot jpg and store all extra "title/name" information inside the file (jpeg comment, EXIF data...?). Eric PS: I assume that you mean ReactOS, the free open WinNT clone, when you mention Ros. ReactOS without LFN would not be the same... ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Freedos-user mailing list Freedos-user(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user

3 2

Patent on FAT
by Murphy, Ged (Bolton) 13 Jan '06

13 Jan '06

I'm reading reports of a US patent on FAT. What's going on and how will this effect us? The US patent rules are seriously out of control :( 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

15 22

MS's patent claims for FAT
by Wierd_w 13 Jan '06

13 Jan '06

I have found the full texts for the patents for FAT. The links are very long, so I expect them to get clipped. Regardless, here it goes anyway. http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=… http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=… http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=… Those are all three patents listed by the MS FAT patent notification page at MS. I note how their claims arent specific about what kind of 'memory storage' the FAT structure is located in--- MS is being really paranoid about it. Still, IANAL, but I would say this is grounds for an equitable estoppel. MS has allowed royalty free use of FAT for how many years now? How many industries rely on FAT support, as a De-Facto standard for floppies and flash media? Sounds like a textbook case for Equitable Estoppel. http://www.nolo.com/definition.cfm/Term/7F1E56D5-7EC1-4CEB-86B3943F6990FF77… (First item) I would bring this to the FSF's attention. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

RE: [ros-dev] Patent on FAT
by Murphy, Ged (Bolton) 13 Jan '06

13 Jan '06

Another twist in the tale : http://www.linux-watch.com/news/NS2809681376.html 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

Compilation Units - Dealing with the lack of PCH in Wine
by Steven Edwards 13 Jan '06

13 Jan '06

Hi, I have manually made a compilation unit and a patch with a 1 line diff for uuid+shell32 and took my build from 30+ secs down to 9 on gcc. Alex reported a drop from 22 to 1 on msvc. We need to create a master source file for each Wine dll like the one attached and add some hacks for the errors that popup. I have not tested the resulting shell32.dll but it should work the same. I do not think we can automate generation of the compilation unit sources for the Wine code due to the hacks we will need to add like in the attached file. -- Steven Edwards - ReactOS and Wine developer "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

2 1

trunk is broken
by Hartmut Birr 12 Jan '06

12 Jan '06

Hi, I'm not able to install ros from the current trunk on real hardware. At the end of the second stage setup I see a reset, which seems to be a triple fault. After the reset, I'm again on the second stage setup. - Hartmut

2 2

Broken Message Dispatching in Win32k
by Alex Ionescu 12 Jan '06

12 Jan '06

Hi, After applying my user-mode callback patch, I sometimes see a bugcheck caused by my debugging code. It seems that we do user-mode callbacks with Kernel APCs disabled (just like we also did them with PreviousMode == KernelMode, thank God that I had to "break" HEAD to find this huge bug... but that's another story). The old code "worked" because it did not check for this serious mistake. Normally, I've noticed that messages are sent through co_IntSendMessage which is called with KernelApcDisable == -1. That function calls some unlocking functions and then does the Callback, which is called with KernelApcDisable == 0, which is good. However, co_IntSendMessage is sometimes being called from co_MsqPeekHardwareMessage. DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable); WaitObjects[1] = MessageQueue->NewMessages; WaitObjects[0] = &HardwareMessageQueueLock; do { UserLeaveCo(); WaitStatus = KeWaitForMultipleObjects(2, WaitObjects, WaitAny, UserRequest, UserMode, FALSE, NULL, NULL); UserEnterCo(); DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable); while (co_MsqDispatchOneSentMessage(MessageQueue)) { DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable); } DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable); } while (NT_SUCCESS(WaitStatus) && STATUS_WAIT_0 != WaitStatus); In this loop, the first KernelApcState is -1. After the wait, it becomes -2. Now normally there is nothing to dispatch, so the function continues, and the -2 later becomes a -3 after another lock, then gradually goes down to -2, then back to -1. So the function enters with -1 and exits with -1, which is normal. However, if the Message Queue *does* have a message on it, then co_MsqDispatchOneSentMessage ends up being called. Remember that after the wait we're now at -2. So that function will then call co_IntSendMessage at -2, which will lower ir it to -1 before the callback. But now the callback runs at -1, which means Kernel APCs are disabled... so we bugcheck. I have absolutely NO knowledge of Win32k Message Queues/MesssageSending, but something defintely seems wrong to me here...can anyone help please? Best regards, Alex Ionescu

2 1

Re: [ros-svn] [hbirr] 20793: - We cannot access the OwnerTable without locking the resource.
by Hartmut Birr 12 Jan '06

12 Jan '06

hbirr(a)svn.reactos.org wrote: > - We cannot access the OwnerTable without locking the resource. > - The shared waiters may wait also on the semaphore. It makes no sense to boost a waiting thread. > - The thread header is initialized like KeWaitForSingleObject (?, ?, ?, TRUE, ?). During the boost, > possible the dispatcher lock is released but the thread block (WaitNext) isn't changed. > > > > Updated files: > trunk/reactos/ntoskrnl/ex/resource.c > > _______________________________________________ > Ros-svn mailing list > Ros-svn(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-svn > > Oops, I've copied the wrong commit message. The correct is: - We cannot access the OnerTable without locking the resource. - The shared waiters may wait also on the semaphore. It makes no sence to boost a waiting thread. - The thread header is initialized like KeWaitForSingleObject (?, ?, ?, TRUE, ?). During the boost, possible the dispatcher lock is released but the thread block (WaitNext) isn't changed. - Hartmut

1 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