unicode.h includes windef.h, which includes winnt.h, which has the handling for the wchar_t type. As it's the first included header, no other wchar_t type will be defined before.
- Remove the wchar_t definition from the Makefile as the winnt.h header will define it as "unsigned short" automatically.
svn path=/trunk/; revision=28423
A host can only have one special wchar_t definition, so we don't need to define all. Also _WCHAR_T_DEFINED is the only definition used for overriding the wchar_t setting by applications.
So use the previous logic to check and define the wchar_t definitions for the host and at the end check for _WCHAR_T_DEFINED. In all cases, define _WCHAR_T_DEFINED.
Additionally, __need_wchar_t has to be undefined after including "ctype.h" as "ctype.h" defines it.
svn path=/trunk/; revision=28422
copyright assigment:
* Copyright (C) 1993,1994,1996,1997 John Brezak, Erik Bos, Alex Korobka.
* Copyright (C) 1999 Marcus Meissner
async.c was original licensed under the GNU Lesser General Public License v2.1
svn path=/trunk/; revision=28419
The actual problem was that we'd overrun the end of the handle count array
when decrementing. This also led to a handle leak (observed). Stop correctly
when we find the handle we want.
svn path=/trunk/; revision=28415
These are C++ files, so they should be built with g++ like it's done for the other tools. Usually they can also be built with gcc, but Collibri from IRC reported that broken gcc interfaces exist, which lead to problems with these files.
svn path=/trunk/; revision=28414
wrc.h includes wrctypes.h, which includes windef.h, which includes winnt.h. And winnt.h contains our wchar_t check, which has to be done before including ctype.h to enable building on Mac OS X hosts.
svn path=/trunk/; revision=28413
We don't only need to check if wchar_t has already been defined, but also report this to all known hosts and operating systems.
svn path=/trunk/; revision=28410
This unifies the way of 64-bit compatibility and also enables cabman to compile with MSVC.
The remaining "unsigned long"'s have to be used for casting pointers as the pointers are always 64-bit on 64-bit machines.
- Silence some warnings in MSVC 2005 and also add a MSVC project file.
When you compiled the zlib library with RosBE, you can now easily use this project file without any changes to compile cabman with MSVC.
svn path=/trunk/; revision=28393
I had to break some SVN locks to add my latest commit. Here I'm undoing some of them now:
builddep.h - Remains unlocked. It just contains basic type definitions and include statements
infcommon.h - Just unlocked this file. It just contains one basic definition and two type definitions
infhost.h - Remains unlocked. It just contains the function prototypes for functions in the other source files
infhostgen.c - Locked again as I did not check this file
infhostget.c - Locked again as I did not check this file
infhostglue.c - Remains unlocked. It just contains a DbgPrint function, which can be found in many ReactOS source files
infhostput.c - Locked again as I did not check this file
inflib.mak - Just unlocked this file. No reason for a makefile to be locked.
README.txt - Just unlocked this file. No reason for a readme file to be locked.
svn path=/trunk/; revision=28390
This is now done by adding a "typedefs64.h" header file, which uses int's instead of long's for 32-bit values. As far as I know, this is the only way to avoid the problem that a long has a size of 64-bit on 64-bit systems.
This header file is now used in the host makefiles of cmlib, inflib and mkhive. It is also suitable for the other host tools, which need 32-bit values (will do some changes there in the next few days).
Unfortunately, Live-CDs still do not work because of another bug (see bug #2290).
But I compared the hives created by 32-bit Debian Linux and 64-bit Debian Linux and after these changes, they are exactly the same.
See issue #2272 for more details.
svn path=/trunk/; revision=28389
it will take some times getting native DirectX working in user mode.
Wine Have manger ported their DirectX to Windows, And after some help
from wine (Roderick Colenbrander aka Thunderbird), That mean we got
now DirectX8 support in ReactOS from wine DirectX (base on opengl).
(rember disable the SSE in mesa before trying it, and it is untested
in ReactOS)
svn path=/trunk/; revision=28386