Hi Aitor,
Aitor Santamaría Merino escreveu:
This gets complicated when Kernel is 386 optimized. MS-DOS never
modified this because it is 16-bit. It could be argued that if a
kernel is to be compatible it cannot modify them either.
Now the other way round: can the kernel be sensistive to 386 r
Hi,
Alain escribió:
tom ehlert escreveu:
IMO, scince FS, GS, and the high parts of EAX,... aren't used by MSDOS
as well, drivers can get away when they destroy these resisters,
so it's a good idea to save them as well.
This gets complicated when Kernel is 386 optimized. MS-DOS never
modi
Eric Auer escreveu:
But again, the problem only shows up if you use 386 optimizations
in the kernel. You can also reduce the fortification cost by telling
OpenWatcom "this function is known to trash those registers" instead
of adding extra code to save all registers all the time (even at
place
At 05:47 PM 7/25/2005 -0300, Alain wrote:
Hi Michael, Eric, Arcady and Jeremy,
I have just read all this thread at once. It sounds just like a big quiproquo.
1) Eric pinpointed one problem to a register modification
2) He found out that new compile options could solve it, temporaryly only
mea
Hi Alain,
> 1) Eric pinpointed one problem to a register modification
Yes. EMM386 modifies registers that do not even exist on 8086,
and it does so only during EMM386 initialization. As the MS DOS
kernel is 100% 8086 compatible, it does not hurt there.
> 2) He found out that new compile options
tom ehlert escreveu:
IMO, scince FS, GS, and the high parts of EAX,... aren't used by MSDOS
as well, drivers can get away when they destroy these resisters,
so it's a good idea to save them as well.
This gets complicated when Kernel is 386 optimized. MS-DOS never
modified this because it is
Hi Michael, Eric, Arcady and Jeremy,
I have just read all this thread at once. It sounds just like a big
quiproquo.
1) Eric pinpointed one problem to a register modification
2) He found out that new compile options could solve it, temporaryly
only meant it as a test. It is *not* clear at all
At 02:58 PM 7/25/2005 +0200, Eric wrote:
Hi, while the XMS spec is not specific about the internal version
number of himem, RBIL is:
Call the XMS driver "Get XMS version number" function with:
AH = 00h
Return: AX = XMS version (in BCD, AH=major, AL=minor)
BX = internal revision
Hi... some new thoughts on the "EMM386 trashes 386-specific registers
(and only such!) during init (but not during other activities)" problem:
MS DOS _kernel_ was plain 8086 compatible, so even though you were
supposed to preserve ALL registers, you could trash all THOSE registers
which MS DOS wou
Hi, while the XMS spec is not specific about the internal version
number of himem, RBIL is:
Call the XMS driver "Get XMS version number" function with:
AH = 00h
Return: AX = XMS version (in BCD, AH=major, AL=minor)
BX = internal revision number (in BCD for HIMEM.SYS)
DX =
Hello Kenneth,
>> I agree that device drivers should not modify any register when you call
>> them, but I admit that I do not remember WHERE I have read that device
>> drivers MUST not modify any registers. In particular, fixing EMM386 would
> Well PC-DOS tech reference states regarding the The I
At 06:16 PM 7/24/2005 +0200, Eric Auer wrote:
Talking about HIMEM: please make the version number BCD as recommended in
RBIL, as some programs do not display "3.0b" (binary) correctly as 3.11 ;-).
The correct answer explicitly documented in the XMS specification: The XMS
version number coded
Eric Auer wrote:
...
I agree that device drivers should not modify any register when you call
them, but I admit that I do not remember WHERE I have read that device
drivers MUST not modify any registers. In particular, fixing EMM386 would
...
Well PC-DOS tech reference states regarding the The
Hi, while it would definitely take a lot more than a few minutes
for me to install OpenWatcom and compile a new kernel (always using
Turbo C for that until now), luckily Jeremy already did the test.
Thanks for that!
> My question is, does any other software destroy important registers?
A comment
14 matches
Mail list logo
