Ros-dev

ros-dev@reactos.org

2 participants
5791 discussions

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

21 Feb '05

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

3 4

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

21 Feb '05

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

1 0

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

21 Feb '05

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

2 1

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

21 Feb '05

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

1 0

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

21 Feb '05

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

4 4

Welcome Herve
by Alex Ionescu 21 Feb '05

21 Feb '05

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

2 1

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

20 Feb '05

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

1 0

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

20 Feb '05

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

2 2

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

20 Feb '05

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

4 3

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

20 Feb '05

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

2 1

Jump to page:

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