mirror of
https://github.com/reactos/reactos.git
synced 2024-08-30 23:28:58 +00:00
|
||
---|---|---|
.. | ||
def_converter | ||
hal | ||
iface/native | ||
ntoskrnl | ||
.cvsignore | ||
ReactOS.dsw | ||
README.txt |
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.