- Ros-dev - ReactOS.org

Roadmap / List of tasks / Attn. all developers

by Aleksey Bragin

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.

19 years, 5 months

13
15
0 0

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

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

19 years, 5 months

3
2
0 0

RE: [ros-dev] Re: [ros-diffs] [amunger] 21474: DHCP Client fixes and enhancements

by Murphy, Ged (Bolton)

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

19 years, 5 months

1
0
0 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

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

19 years, 5 months

1
0
0 0

RE: ncpa

by Ge van Geldorp

> 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

19 years, 5 months

1
0
0 0

RE: [ros-diffs] [greatlrd] 21453: Start Implement HEL 1. Start im plement HEL Inisate 2. Start implement HEL GetAvailMem

by Murphy, Ged (Bolton)

> + 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

19 years, 5 months

1
0
0 0

Re: [ros-diffs] [tretiakov] 21429: [AUDIT] msgina is clean.

by Ged Murphy

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?

19 years, 5 months

5
6
0 0

Re: [ros-diffs] [gedmurphy] 21413: update Wine sync doc

by Thomas Weidenmueller

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

19 years, 5 months

2
1
0 0

Re: [ros-diffs] [tretiakov] 21409: Implement NdrCContextMarshall()

by Ged Murphy

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, > > > >

19 years, 5 months

1
1
0 0

RE: [ros-dev] Alpha workstation

by Michael Rich

> 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

19 years, 5 months

1
0
0 0

RE: [ros-dev] Alpha workstation

by Michael Rich

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.

19 years, 5 months

2
1
0 0

[Fwd: Re: [ros-diffs] peterw: 21369 - /trunk/reactos/CREDITS]

by Filip Navara

19 years, 5 months

3
3
0 0

System for manual regression testing

by Maarten Bosma

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

19 years, 5 months

3
6
0 0

Mailing list ros-diffs

by Aleksey Bragin

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.

19 years, 5 months

2
1
0 0

The WRK and what it means for ReactOS

by Alex Ionescu

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

19 years, 5 months

6
9
0 0

The Future of the Desktop

by Rick Langschultz

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.

19 years, 5 months

7
7
0 0

RE: [ros-dev] The Future of the Desktop

by Murphy, Ged (Bolton)

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

19 years, 5 months

1
0
0 0

RE: [ros-dev] The WRK and what it means for ReactOS

by Murphy, Ged (Bolton)

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

19 years, 6 months

1
0
0 0

Time for another change

by Steven Edwards

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

19 years, 6 months

6
5
0 0

r21332

by Alex Ionescu

> [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

19 years, 6 months

3
2
0 0

Putting MIDL output into svn repository.

by Saveliy Tretiakov

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.

19 years, 6 months

3
6
0 0

Alpha workstation

by Steven Edwards

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

19 years, 6 months

5
8
0 0

RE: [ros-dev] Wine sync

by Murphy, Ged (Bolton)

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

19 years, 6 months

11
21
0 0

dev blogging

by Ged Murphy

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

19 years, 6 months

1
0
0 0

Perl support in ROS

by Adam Kennedy

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

19 years, 6 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev