bd451f240f
CORE-9023
FIXES:
======
- Fix parsing of the multiboot options string.
NOTE: They are not yet treated in a case-insensitive manner!
- Fix a bug in ArcOpen() so that it correctly skips the first path
separator (after the adapter-controller-peripheral ARC descriptors).
The path separator can be either a backslash or a slash (both are
allowed according to the specs); they were also already handled
correctly in other parts of the code.
- Fix DissectArcPath() so as to:
* **OPTIONALLY** (and not mandatorily!) return the path part that follows
the ARC adapter-controller-peripheral elements in the ARC path;
* make it correctly handle the (yes, optional!!) partition() part in the
ARC path, for the multi(x)disk(y)rdisk(z) cases.
ENHANCEMENTS:
=============
- Directly retrieve the default OS entry as we enumerate them and
build their list (i.e. merge the GetDefaultOperatingSystem() helper
within InitOperatingSystemList()).
- Directly use the opened 'FreeLoader' INI section via its ID in the
different functions that need it.
- Make the custom-boot and linux loaders honour the boot options they are
supposed to support (see FREELDR.INI documentation / template).
This includes the 'BootDrive' and 'BootPartition' (alternatively the ARC
'BootPath').
This also allows them to take into account the user-specified choices in the
FreeLdr custom-boot editors.
- Modify the FreeLdr custom-boot editors so as to correctly honour
the priorities of the boot options as specified in the FREELDR.INI
documentation / template.
- Use stack trick (union of structs) to reduce stack usage in the
FreeLdr custom-boot editors, because there are strings buffers that are
used in an alternate manner.
- Extract out from the editors the LoadOperatingSystem() calls, and
move it back into OptionMenuCustomBoot(), so that when this latter
function is called there is no risk of having a stack almost full.
- When building the ARC-compatible argument vector for the loaders, add
the mandatory "SystemPartition" path. This allows the loaders to NOT
call the machine-specific MachDiskGetBootPath() later on (this data is
indeed passed to them by the boot manager part of FreeLdr).
- Improve the FsOpenFile() helper so as to make it:
* return an adequate ARC_STATUS instead of a mere uninformative BOOLEAN;
* take open options, as well as a default path (optional) that would be
prepended to the file name in case the latter is a relative one.
- Make RamDiskLoadVirtualFile() return an actual descriptive ARC_STATUS
value, and make it take an optional default path (same usage as the one
in FsOpenFile() ).
+ Remove useless NTAPI .
- UiInitialize() and TuiTextToColor(), TuiTextToFillStyle(): load or
convert named settings into corresponding values using setting table and
a tight for-loop, instead of duplicating 10x the same parameter reading
logic.
- UiInitialize(): Open the "Display" INI section just once. Remove usage
of DisplayModeText[] buffer.
- UiShowMessageBoxesInSection() and UiShowMessageBoxesInArgv(): reduce
code indentation level.
ENHANCEMENTS for NT OS loader:
==============================
- Don't use MachDiskGetBootPath() but use instead the "SystemPartition"
value passed via the ARC argument vector by the boot manager
(+ validation checks). Use it as the "default path" when calling
FsOpenFile() or loading the ramdisk.
- Honour the FreeLdr-specific "Hal=" and "Kernel=" options by converting
them into NT standard "/HAL=" and "/KERNEL=" options in the boot
command line.
Note that if the latter ones are already present on the standard "Options="
option line, they would take precedence over those passed via the separate
"Hal=" and "Kernel=" FreeLdr-specific options.
Also add some documentation links to Geoff Chappell's website about
how the default HAL and KERNEL names are chosen depending on the
detected underlying platform on which the NT OS loader is running.
|
||
|---|---|---|
| .github | ||
| base | ||
| boot | ||
| dll | ||
| drivers | ||
| hal | ||
| media | ||
| modules | ||
| ntoskrnl | ||
| sdk | ||
| subsystems | ||
| win32ss | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmessage | ||
| .travis.yml | ||
| apistatus.lst | ||
| appveyor.yml | ||
| CMakeLists.txt | ||
| CODE_OF_CONDUCT.md | ||
| CODEOWNERS | ||
| configure.cmd | ||
| configure.sh | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| COPYING.ARM | ||
| COPYING.LIB | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| CREDITS | ||
| Doxyfile | ||
| INSTALL | ||
| overrides-gcc.cmake | ||
| overrides-msvc.cmake | ||
| PreLoad.cmake | ||
| PULL_REQUEST_MANAGEMENT.md | ||
| README.md | ||
| toolchain-clang.cmake | ||
| toolchain-gcc.cmake | ||
| toolchain-msvc.cmake | ||
Quick Links
Website • Official chat • Wiki • Forum • JIRA Bug Tracker • ReactOS Git mirror • Testman
What is ReactOS?
ReactOS™ is an Open Source effort to develop a quality operating system that is compatible with applications and drivers written for the Microsoft® Windows™ NT family of operating systems (NT4, 2000, XP, 2003, Vista, Seven).
The ReactOS project, although currently focused on Windows Server 2003 compatibility, is always keeping an eye toward compatibility with Windows Vista and future Windows NT releases.
The code of ReactOS is licensed under GNU GPL 2.0.
ReactOS is currently an Alpha quality operating system. This means that ReactOS is under heavy development, things may not work well and it can corrupt the data present on your hard disk. It is recommended to test ReactOS on a virtual machine or on a computer with no sensitive or critical data!
Building
To build the system it is strongly advised to use the ReactOS Build Environment (RosBE). Up-to-date versions for Windows and for Unix/GNU-Linux are available from our download page at: "Build Environment".
Alternatively one can use Microsoft Visual C++ (MSVC) version 2010+. Building with MSVC is covered here: "Visual Studio or Microsoft Visual C++".
Binaries
To build ReactOS you must run the configure script in the directory you want to have your build files. Choose configure.cmd or configure.sh depending on your system. Then run ninja <modulename> to build a module you want or just ninja to build all modules.
Bootable images
To build a bootable CD image run ninja bootcd from the
build directory. This will create a CD image with a filename bootcd.iso.
See "Building ReactOS" for more details.
You can always download fresh binary builds of bootable images from the "Daily builds" page.
Installing
By default, ReactOS currently can only be installed on a machine that has a FAT16 or FAT32 partition as the active (bootable) partition. The partition on which ReactOS is to be installed (which may or may not be the bootable partition) must also be formatted as FAT16 or FAT32. ReactOS Setup can format the partitions if needed.
Starting 0.4.10, ReactOS can be installed using the BtrFS file system. But consider this as an experimental feature and thus regressions not triggered on FAT setup may be observed.
To install ReactOS from the bootable CD distribution, extract the archive contents. Then burn the CD image, boot from it, and follow the instructions.
See "Installing ReactOS" Wiki page or INSTALL for more details.
Testing
If you discover a bug in ReactOS search on JIRA first - it might be reported already. If not report the bug providing logs and as much information as possible.
See "File Bugs" for a guide.
NOTE: The bug tracker is not for discussions. Please use #reactos Freenode IRC channel or our forum.
Contributing 
We are always looking for developers! Check how to contribute if you are willing to participate.
You can also support ReactOS by donating! We rely on our backers to maintain our servers and accelerate development by hiring full-time devs.
More information
ReactOS is a Free and Open Source operating system based on the Windows architecture, providing support for existing applications and drivers, and an alternative to the current dominant consumer operating system.
It is not another wrapper built on Linux, like WINE. It does not attempt or plan to compete with WINE; in fact, the user-mode part of ReactOS is almost entirely WINE-based and our two teams have cooperated closely in the past.
ReactOS is also not "yet another OS". It does not attempt to be a third player like any other alternative OS out there. People are not meant to uninstall Linux and use ReactOS instead; ReactOS is a replacement for Windows users who want a Windows replacement that behaves just like Windows.
More information is available at: reactos.org.
Also see the media/doc subdirectory for some sparse notes.
Who is responsible
Active devs are listed as members of GitHub organization. See also the CREDITS file for others.
Code mirrors
The main development is done on GitHub. We have an alternative mirror in case GitHub is down.
There is also an obsolete SVN archive repository that is kept for historical purposes.