- Ros-dev - ReactOS.org

compile error
by Wesley Parish 28 Feb '05

28 Feb '05

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

1 0

Floppy Disk
by James Tabor 28 Feb '05

28 Feb '05

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

1 0

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

26 Feb '05

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

1 0

subversion problem
by Hartmut Birr 26 Feb '05

26 Feb '05

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

2 1

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

26 Feb '05

Agreed. It'll be good for publicity too. Regular minor releases are better than infrequent major releases. Gedi. -----Original Message----- From: Jason Filby [mailto:jason.filby@gmail.com] Sent: 23 February 2005 17:57 To: ReactOS Development List Subject: [ros-dev] Release 0.2.6 Hi all The consensus on IRC appears to be that we need another 0.2.x release. The reason is that 0.3 is our "network" release and there's still some work to do to justify this. Everyone agree? Cheers Jason _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

9 12

ReactOS Wallpaper List
by Klemens Friedl 26 Feb '05

26 Feb '05

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

3 5

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

25 Feb '05

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

2 2

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

24 Feb '05

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

2 1

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

24 Feb '05

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

6 5

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

24 Feb '05

Jonathan Wilson wrote: > (do we have a DHCP client yet? If not, how hard would > writing one be?) I'm hoping to get started on one very soon. Gedi _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

1 0

Release 0.2.6
by Jason Filby 24 Feb '05

24 Feb '05

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

5 5

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

23 Feb '05

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

1 0

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

22 Feb '05

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

3 2

State of the WIDL
by Eric Kohl 22 Feb '05

22 Feb '05

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

4 7

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

22 Feb '05

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

1 0

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

22 Feb '05

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

4 6

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

21 Feb '05

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

3 4

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

21 Feb '05

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

1 0

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

21 Feb '05

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

2 1

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

21 Feb '05

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

1 0

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

21 Feb '05

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

4 4

Welcome Herve
by Alex Ionescu 21 Feb '05

21 Feb '05

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

2 1

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

20 Feb '05

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

1 0

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

20 Feb '05

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

2 2

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

20 Feb '05

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

4 3

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