The patched kernel behaves very strangely! :-( It outputs an error
for DEVICE=C:\DOS\HIRAM.EXE line and doesn't load it and repeates
this with many other lines (but not all). For my simpler floppy
configuration, it doesn't load HIMEM64.EXE without even showing an
error!
The
Also, where documented VDISK header (where I may read about this)?
BO It's in the VCPI spec. Available at many places including here:
BO www.dose.se/docs/osdoc/unsorted/ProtectedMode/VCPI.txt
No, there sayed only about signature and showed how to copy word value
from offset 0x1E. :(
On Tue, 23 Mar 2004, Arkady V.Belousov wrote:
Bart, let me remind me %subject% issue: why FD returns nonzero field
for FAT32 in (and only in) current BPB?
most likely because of dsk.c: pbpbarray-bpb_ndirent = 512;
Why that line is there? I don't know. It was already in the first FAT32
On Mon, 22 Mar 2004, Eric Auer wrote:
Hi, about add_far() pointer normalization: I think it would be
better to normalize earlier. If you have a pointer, you normally
have a pointer to a STRUCTURE. If the end of the structure ends
up with an offset 0x then having the POINTER normalized is
On Mon, 22 Mar 2004, Luchezar Georgiev wrote:
:\elv_3e5.1
I mean i:\elv_3e5.1
Sorry for my typo!
should be fixed now. remove_lfn_entries() calls dir_read with the offset
== -1 which is not possible for normal directories (. and ..) but is
possible for root directories. So the 65535 check
On Mon, 22 Mar 2004, Luchezar Georgiev wrote:
But what if it was the first entry in the root directory? Then the
new_diroff++ in dir_read() will make it -1!
remove_lfn_entries() checks for fnp-f_diroff == 0. The first entry can't
have any LFN entries connected to it.
Bart
On Mon, 22 Mar 2004, tom ehlert wrote:
AVB (BTW, is protection
AVB from wrapping HMA pointer into IVT by replacing wrapping into start of HMA
AVB worth of code?)
a working kernel is worth a lot of code (even if you don't see the
reason immediately)
HANDS OFF THE KERNEL, please.
in the end
That's strange. Then MS-DOS DEBUG would also leak handles...
the difference is that msdos debug calls int21/ah=26 instead of 55. Here's
a kernel bug inspired by the RBIL comment this function is implemented
using the same code as AH=26h taken too literally...
Reality is that the only things
On Wed, 17 Mar 2004, Luchezar Georgiev wrote:
The patch below should fix the ZIP media change not detected bug, *if* my
assumption about ZIP driver setting both DF_FIXED and DF_CHANGELINE is
right. Never hurts to assume that this MAY happen though...
If the ZIP drive has its own device driver
On Sun, 7 Mar 2004, Luchezar Georgiev wrote:
The following log comment is slightly incorrect:
prf.c
Log Message:
Borland C (unlike Turbo C) didn't like this pseudo register use.
Actually, *both* Turbo and Borland C didn't like it!
This is strange. The old code has been there for
On Sun, 7 Mar 2004, Luchezar Georgiev wrote:
EXACTLY! Now I see that put_unsigned() and put_string in prf.obj have a
CBW instruction that does just that! So, what do you suggest? I think that
we can just apologise to KR and change c in put_console() to char.
or cast to unsigned char. That's
On Wed, 3 Mar 2004, Luchezar Georgiev wrote:
On Tue, 2 Mar 2004 21:06:03 + (GMT), Bart Oldeman wrote:
at first sight it looks good to me, thanks! The one thing I saw that might
have to be changed is the location of the new stack. Since RBIL table 1690
(very end of interrupt.g
On Mon, 1 Mar 2004, Arkady V.Belousov wrote:
__O\_/_\_/O__
int absread(int DosDrive, int nsects, int foo, void *diskReadPacket);
#pragma aux absread = \
int 0x25 \
sbb ax, ax\
parm [ax] [cx] [dx]
Following this discussion I looked at when and why I removed the
code we're talking about from HMA_TEXT.
It's not as easy as a mere code save.
It goes all the way back to kernel 2024a released Apr 16 2001. Before that
kernel there was a p_0() function in task.c.
Around that time we were making
On Wed, 11 Feb 2004, Luchezar Georgiev wrote:
INIT_FMEMCPY: |INIT_FMEMCPY:
enter 8,0|pushBP
mov DX,4[BP] |mov BP,SP
mov EAX,0Ah[BP]|
101 - 115 of 115 matches
Mail list logo
