mirror of
https://github.com/reactos/reactos.git
synced 2024-11-01 12:26:32 +00:00
103 lines
4.2 KiB
Plaintext
103 lines
4.2 KiB
Plaintext
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.
|