> -----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
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
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
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
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
>
>
>
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
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
> 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.
Hi All,
I have a 100% reproducable crash in Win32k due to a bad value being passed to PeakMessage. Run
taskmgr and attempt to double click on the top left corner to close the application.
Thanks
Steven
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
Hi ea,
It seems this smss commit is actually missing some code.
In client.c, you changed SmCreateClient.
Now this file doesnt compile since you are using "SM_CONNECT_DATA_SIZE",
which isnt defined anywhere in the tree.
Just for a recall: you forgot to include <sm/helper.h> in smss.h (see 13663)
=====
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word