viviskas
commented
3 years ago - []() @snyk-bot This XML file does not appear to have any style information associated with it. The document tree is shown below.
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
- status: open --> closed-fixed
- assigned_to: Kenneth Davis
This bug can be closed then (by whomever has access to do so) and I will create another bug to track upx --lzma support
BINGO!
replacing --lzma with --best and everything is back to normal!
however this is strange, as I have compiled quite a few kernels using --lzma.
however this can wait to another day; case closed for me for now.
I need to look into the upx decompressor logic to see why though; the kernel jumps past the config section, then jumps past size bytes (where size is the packed kernel size) to the trailer which shifts the kernel down and then jumps to the start of the packed kernel. I wonder how much stack the lzma decompressor needs or if it is some other change ... Please let me know if changing the UPX setting gets your compiled kernel to boot for you?
lzma isn't supported for upx
change:
set XUPX=upx --lzma
to:
set XUPX=upx --8086 --best
or something similar
I attach the output of the build process.
yes, UPX. I also don't remember seeing these EXEFLAT messages, but I can be wrong.
of course if EXEFLAT doesn't work proper, this would look similar ;)
The boot code you are using is from 2002, in 2003 and 2004 there were several changes including one Bart has as fix FAT12 - not saying it is related, but it may be worthwhile to update your boot sector at some point. That said, nothing in the boot protocol should have changed since then so it should work. You don't mention seeing the 123 portions from the kernel, so it looks like the issue is when control is transferred to the kernel as the first thing the kernel should do is print 1. Are you using a UPX'd kernel? The releases are. I suspect an issue with exeflat. The differences in GetFatBlock are from compiling for 8086 vs 386; I have attached the corresponding disassembly from my 386 build which is identical to yours except my wdis doesn't add all the word ptr comments, the binary values are the same.
I am going to do some testing to see if I can reproduce the boot issue - try older boot.asm source and with/without UPX/386/etc.
Hallo Herr Kenneth Davis,
am Dienstag, 29. Juni 2021 um 15:46 schrieben Sie:
I will have a look this afternoon. What version of Watcom are you
using,
when comparing the .MAP files, I noticed that I had watcom 1.9
installed, while you used 2.0. so I installed the most recent windows
watcom, but the result (non bootable) remained the same.
by looking at the getFATblock code, I see that register calling
conventions are used. could this be the difference?
what os are you building from,
Windows XPand what command are you using
to build?
windows cmdDid you make the disk bootable with sys built at same
time or some other method?
long time ago, I don't know. but replacing kernel.sys by older kernels
reproducibly cures the problem.Thank you.
I will have a look this afternoon. What version of Watcom are you using, what os are you building from, and what command are you using to build? Did you make the disk bootable with sys built at same time or some other method? Thank you.
follow up:
when I replace my kernel.sys with the kernel from https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/2043/ everything works fine. that's good.
now I note that my fat32 kernel has a size of 44.489 byte, while the official is 46.485 byte.
that's really strange as I have no options added or removed wrt the distribution.
comparing the map files (official KWC.map to my kernel.map), I note size differences between almost all functions. a few bytes may or may be not expected, when the compiler is of slight different age. But I note that the size of my GetFatBlock at 0x7d is significant smaller then official 0x96.
could someone compare these few lines of disassembly and see if that makes any sense?
use
WDIS fattab.obj > fattab.cod
for disassembly.
I have so far no idea what this might be related to ...
- [ ]
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
This bug can be closed then (by whomever has access to do so) and I will create another bug to track upx --lzma support
BINGO!
replacing --lzma with --best and everything is back to normal!
however this is strange, as I have compiled quite a few kernels using --lzma.
however this can wait to another day; case closed for me for now.
I need to look into the upx decompressor logic to see why though; the kernel jumps past the config section, then jumps past size bytes (where size is the packed kernel size) to the trailer which shifts the kernel down and then jumps to the start of the packed kernel. I wonder how much stack the lzma decompressor needs or if it is some other change ... Please let me know if changing the UPX setting gets your compiled kernel to boot for you?
lzma isn't supported for upx
change:
set XUPX=upx --lzma
to:
set XUPX=upx --8086 --best
or something similar
I attach the output of the build process.
yes, UPX. I also don't remember seeing these EXEFLAT messages, but I can be wrong.
of course if EXEFLAT doesn't work proper, this would look similar ;)
The boot code you are using is from 2002, in 2003 and 2004 there were several changes including one Bart has as fix FAT12 - not saying it is related, but it may be worthwhile to update your boot sector at some point. That said, nothing in the boot protocol should have changed since then so it should work. You don't mention seeing the 123 portions from the kernel, so it looks like the issue is when control is transferred to the kernel as the first thing the kernel should do is print 1. Are you using a UPX'd kernel? The releases are. I suspect an issue with exeflat. The differences in GetFatBlock are from compiling for 8086 vs 386; I have attached the corresponding disassembly from my 386 build which is identical to yours except my wdis doesn't add all the word ptr comments, the binary values are the same.
I am going to do some testing to see if I can reproduce the boot issue - try older boot.asm source and with/without UPX/386/etc.
Hallo Herr Kenneth Davis,
am Dienstag, 29. Juni 2021 um 15:46 schrieben Sie:
by looking at the getFATblock code, I see that register calling
conventions are used. could this be the difference?
I will have a look this afternoon. What version of Watcom are you using, what os are you building from, and what command are you using to build? Did you make the disk bootable with sys built at same time or some other method? Thank you.
follow up:
when I replace my kernel.sys with the kernel from https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/2043/ everything works fine. that's good.
now I note that my fat32 kernel has a size of 44.489 byte, while the official is 46.485 byte.
that's really strange as I have no options added or removed wrt the distribution.
comparing the map files (official KWC.map to my kernel.map), I note size differences between almost all functions. a few bytes may or may be not expected, when the compiler is of slight different age. But I note that the size of my GetFatBlock at 0x7d is significant smaller then official 0x96.
could someone compare these few lines of disassembly and see if that makes any sense?
use
WDIS fattab.obj > fattab.cod
for disassembly.
I have so far no idea what this might be related to ...
_ Help critical secure !