Triggered by a fix attempt by M.Harmstone in PR #1905.
- Introduce #defines and helper functions so as to initialize the
descriptors in a human-readable and tractable way, without magic values.
- Rework some comments.
- Document what the changes are in (Longhorn and) Vista+.
Data has been obtained through using the WinDbg command: dg 0x00 0xFF
(for example), that lists all the selectors from 0x00 to 0xFF included.
See https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/dg--display-selector-
for more details.
of a search result again.
The feature regressed by 0.4.13-dev-1133-g
a3ee648d8b
I chose the shorter solution of Brock Mammen instead
of the patch of Doug Lyons from PR1960.
Still many thanks to Doug Lyons for his encouragement
in creating a fix as well and performing
regression-testing.
I intend to merge that back into 0.4.13RCs as well.
- Implement support for the "RDIMAGELENGTH" and "RDIMAGEOFFSET" boot
options. Fixes CORE-15432.
- Separate the initialization of the global gInitRamDiskBase /
gInitRamDiskSize variables from the FreeLdr command-line, and the
actual initialization of the internal variables of the RamDisk.
The latter are initialized via calls to RamDiskInitialize().
- Implement 'SeekRelative' mode in RamDiskSeek().
- Make RamDiskLoadVirtualFile() internal function that gets called by
RamDiskInitialize(), and we use the latter in the NT loader instead.
Basically it appeared that without this fix, the CPU was somehow residing
in an inconsistent state, that made it crash when a full 16-bit real-mode
to 32-bit protected mode transition occurred. (Encountered when trying
to load Linux, see problem description below.)
In that situation, Bochs reports that the CPU is in "compatibility mode".
The fix is based from information from Fig.1-6 "Operating Modes of the
AMD64 Architecture" (page 12) and Chapter 14 (pages 429-446) of the
"AMD64 Architecture Programmer’s Manual Volume 2: System Programming"
https://www.amd.com/system/files/TechDocs/24593.pdf
*** THE PROBLEM ***
When booting Linux using x86 FreeLdr everything goes well.
When trying to do the same using x64 FreeLdr, the Linux code (both the
boot sector, the setup sector and the main kernel contents) is all
correctly loaded and relocated in memory as in the x86 case. We then pass
control to the decompressing code that appears to succeed. However, once
it has finished and "Parsing ELF file..." step has been run, the next
step "Booting the kernel..." crashes with a CPU Triple-Fault.
This problem **DOES NOT HAPPEN** when booting from GRUB.
Log excerpt from Bochs:
<snip>
00089459736i[BIOS ] Booting from 07c0:0000
00089782775i[SER ] com1: FIFO enabled
00095994535i[BIOS ] int13_harddisk: function 41, unmapped device for ELDL=81
00095998517i[BIOS ] int13_harddisk: function 08, unmapped device for ELDL=81
00397139785i[BIOS ] KBD: unsupported int 16h function 03
00397143625i[BIOS ] *** int 15h function AX=e980, BX=0000 not yet supported!
00523008104e[CPU0 ] interrupt(long mode): vector must be within IDT table limits, IDT.limit = 0x0
00523008104e[CPU0 ] interrupt(long mode): vector must be within IDT table limits, IDT.limit = 0x0
00523008104i[CPU0 ] CPU is in compatibility mode (active)
00523008104i[CPU0 ] CS.mode = 32 bit
00523008104i[CPU0 ] SS.mode = 32 bit
00523008104i[CPU0 ] EFER = 0x00000500
00523008104i[CPU0 ] | RAX=00000000e0000011 RBX=0000000000000000
00523008104i[CPU0 ] | RCX=0000000000000000 RDX=0000000000000000
00523008104i[CPU0 ] | RSP=00000000004f8000 RBP=000000000082e003
00523008104i[CPU0 ] | RSI=0000000000099800 RDI=00000000c0611000
00523008104i[CPU0 ] | R8=0000000000109000 R9=0000000000009020
00523008104i[CPU0 ] | R10=00000000000007e3 R11=000000000000e958
00523008104i[CPU0 ] | R12=0000000000000000 R13=0000000000000000
00523008104i[CPU0 ] | R14=0000000000000000 R15=0000000000000000
00523008104i[CPU0 ] | IOPL=0 id vip vif ac vm RF nt of df if tf SF zf af PF cf
00523008104i[CPU0 ] | SEG sltr(index|ti|rpl) base limit G D
00523008104i[CPU0 ] | CS:0010( 0002| 0| 0) 00000000 ffffffff 1 1
00523008104i[CPU0 ] | DS:0018( 0003| 0| 0) 00000000 ffffffff 1 1
00523008104i[CPU0 ] | SS:0018( 0003| 0| 0) 00000000 ffffffff 1 1
00523008104i[CPU0 ] | ES:0018( 0003| 0| 0) 00000000 ffffffff 1 1
00523008104i[CPU0 ] | FS:0018( 0003| 0| 0) 00000000 ffffffff 1 1
00523008104i[CPU0 ] | GS:0018( 0003| 0| 0) 00000000 ffffffff 1 1
00523008104i[CPU0 ] | MSR_FS_BASE:0000000000000000
00523008104i[CPU0 ] | MSR_GS_BASE:0000000000000000
00523008104i[CPU0 ] | RIP=0000000000409327 (0000000000409327)
00523008104i[CPU0 ] | CR0=0xe0000011 CR2=0x0000000000409327
00523008104i[CPU0 ] | CR3=0x005b5000 CR4=0x000000a0
00523008104i[CPU0 ] 0x0000000000409327: (instruction unavailable) page not present
00523008104p[CPU0 ] >>PANIC<< exception(): 3rd (13) exception with no resolution
<snip>
- Introduce "Relocator16Boot()". So far its aim is just to correctly set
the CPU state (segments, registers, flags) to what is expected by a
given boot image before running it.
This function can be seen as the embryonic state of a future boot relocator
(see e.g. GRUB or SYSLINUX) that would also relocate the boot image at
the correct places. (Such feature is needed when boot images have to
be loaded in memory areas that cover where the boot loader is in memory.)
- Implement ChainLoadBiosBootSectorCode() around it.
- Replace BootOldLinuxKernel() and BootNewLinuxKernel() by a new
BootLinuxKernel() function (in assembly) that relocates the kernel
to a given position and then boot it, using Relocator16Boot().
Ideally the relocation should be done by a future boot relocator...
Implementation notes for Relocator16Boot():
===========================================
For setting the CPU state the function is based on a similar code as the
Int386() helper, namely it takes a pointer to REGS structure and pass
this information through the 32->16 bits call before setting the CPU state
in accordance.
New stack segment/pointer and code segment/pointer are also specified.
For passing these values through the 32->16 bits call the 16-bit BSS
memory offsets "BSS_CallbackReturn" and "BSS_RealModeEntry" (respectively)
are reused.
On Windows <= 2003 (and current ReactOS), this is the "InfName" value
in the "HKEY_LOCAL_MACHINE\CurrentControlSet\Control\BiosInfo\" key.
(The default file name found there is 'biosinfo.inf'.)
On Vista+, this is the "InfName" value in the
"HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Errata\" key.
(The default file name found there is 'errata.inf'.)
For 1st-stage setup, the file is specified in the "InfName" value of
the "BiosInfo" section in the TXTSETUP.SIF file.
Co-authored-by: Hermès Bélusca-Maïto <hermes.belusca-maito@reactos.org>
* Shell Find Improvement to make Search Item general by adding asterisks before and after before search and show sub-directories in find listing. CORE-16152
GCC Linux build had no issues with the last commit but
MSVC x86 & x64 v18.0.31101.0 choked on it with
error C4133: 'function' : incompatible types - from 'D3D_PRIMITIVE *' to 'DWORD *'
and similar.
I could not retest with that exact version of MSVC, but the mentioned problems
vanished for me when compiling locally with MSVC 16.0.40219.1 x86.
Fingers crossed, that this makes the builders happy again!
Avoid regressions CORE-14955 "Ddraw fullscreen crashes" and CORE-15652
This brings us back to before guilty commit 0.4.10-dev-55-g
7af3969e9f
and therefore downgrades
dll/directx/wine/
D3D8,D3D9,DDRAW,D3DCOMPILER_43,WINED3D
to WineStaging 3.3.
Also downgrades related header sdk/include/reactos/wine/wined3d.h
and for the first time also media/doc/README.WINE
Same versions of these dlls we had in every ros rls since 0.4.10rls.
Amine Khaldi agreed to perform this revert also for master now.
Purpose of this revert is to fix crashes when Ddraw apps switch
into fullscreen with VBEMP and inbuilt Mesa.
I tested, before:
DxDiag crashed when switching to fullscreen (CORE-14955),
Diablo II crashed immediately (CORE-15652),
Monster-Truck-Madness 2 demo crashed after main menu
Afterwards all of these apps do run.
DXTN does still work after that, even with VBEMP and inbuilt Mesa.
squashed commit of 0.4.13-RC-2-g
67dd70e5ef
and 0.4.13-RC-3-g
9f1e2cd172
CORE-16400
- Replace "Verdana", "Verdana Bold", "Verdana Bold Italic" and "Verdana Italic" fonts by duplicating "DejaVu Sans" fonts and renaming them.
- Replace LICENSE file.
I made these font files by using FontForge. Their family name is "Verdana". Their display names are "Verdana", "Verdana Bold", "Verdana Bold Italic" and "Verdana Italic". Their font filenames are verdana.ttf, verdanab.ttf, verdanaz.ttf and verdanai.ttf. The Underline Positions are hacked by adding an integer value for workaround of FontForge's bug.
