ReactOS Microsoft Visual C/C++ 6.0 IDE files

This is the Microsoft Visual C/C++ 6.0 project workspace and project
files for a few of the ReactOS binaries. They are ONLY included as a
convenience, and is NOT to be considered supported, or even correct.
If you build a binary that misbehaves using these files, you _might_
be able to get in touch with someone to fix the problem
         BUT DO NOT COUNT ON IT!

The only supported build system for ReactOS is the one documented at
www.reactos.com.

------------------------------------------------------------------
Please, before you start playing with this, read the whole of
this document.

Before you can use these project files, you _need_ to make a successful
build using the normal ReactOS build system. There are some vital files
that needs to be created, and currently only the normal build creates these.

Once that is done, you need to generate the kernel-mode service "table"
file by running nmake (from this point on you can use the "native"
MSVC tools) from the directory MSVC6\iface\native.
This will generate MSVC6\ntoskrnl\nt_zw_msvc.c, an MSVC compatible inline-
assembler version of the file otherwise known as reactos\ntoskrnl\nt\zw.c.

Next, go to def_converter and run nmake. This builds the tool to convert
the .def files for HAL and the kernel from the MinGW format to something
more suitable for the MSVC linker, and also generates these .def files
to their target location [1].

Now you should be set to fire up the IDE and load the project workspace.


When building HAL or the kernel for the first time using these
project files, just doing it the "normal" way _will not work_.
The linker will complain about missing library, and it will fail.

The reason for this is a circular dependency between these two binaries.

Currently you need to follow these procedures [2]:

- Select hal as your active project.
- Select Project/Settings.
- Select the Link tab.
- Select "General" from the Category drop-list.
- Temporary remove the explicit linker library
  (e.g. "..\ntoskrnl\Debug\ntoskrnl.lib")
- Select "Customize" from the Category drop-list.
- Check the "Force file output" checkbox.
- Build hal.
- Uncheck "Force file output".
- Put back the removed import library.
- Now build the ntoskrnl. Do NOT try to build hal again until
  you have sucessfully built the kernel, and the linker has
  generated its import library!
- Now you can "Clean" hal, and build it as usual.

If everything worked as expected, you should now have both ntoskrnl.exe
and hal.dll freshly built.


LIMITATIONS/DEVIATIONS (from the MinGW build):
- Since there can only be one resource file/project, the kernel had
to choose between either its version resource, or its message table.
The messages won.
- Do NOT open the .rc files in the IDE's resource editor. Chances are
it will assume ownership over them and fill them up with at least
conditional compilation macros.


NOTES:

[1] This is needed due to differences in handling of decorated names
in .def files. While both MinGW GCC and MSVC generates decorated names
in the same way for at least plain cdecl and stdcall C functions, the
MSVC linker expects names in the .def file to be either

- an exact match of the decorated name, in case it exports the
  decorated name from the linked binary, or
- just the name without any decoration, in case it exports just the
  name of the symbol from the linked binary (to allow for e.g.
  GetProcAddress using the undecorated name) - but keeps the decorated
  names in the import library to handle and "redirect" linker requests
  for those decorated symbols, and point them to the undercorated names
  in the binary exporting them - so that a binary A, at link time,
  importing symbols from binary B of the form "_name@0" will resolve
  that symbol from the import library, but the linked binary A will
  reference it as just "name".

The ROS .def files contains a mix, "half-decorated", where the leading
undescores are missing, but the trailing "@n" (for stdcall functions)
are present.
 

[2] Theoretically it could be possible to use a hal.lib generated by the
following procedure, removing the need for the manual steps above.

  cd MSVC6\hal\Debug
  lib \def:..\..\..\reactos\hal\hal\hal.def

but I have not tested it, and take no responsibility for its effectiveness.