JWASMD: padding bytes between segments are uninitialized
Brought to you by:
japheth
Menu
▾
▴
#256 JWASMD: padding bytes between segments are uninitialized
In JWASMD (not JWASM) padding bytes between segments are uninitialized. This is very likely due to memory not being initialized in the DOS version as JWASM does not have this problem. This problem is easily seen with your DEBUG as it uses multiple segments.
IIRC this happens with certain OSes only ( FreeDOS? )
I run PC DOS 7.0. I do have other versions of MS-DOS/PC DOS but I only have PC DOS 7.0 installed on my system. FreeDOS doesn't really count as it's not real DOS.
This seems like it would be more of a C library issue with malloc than any version of DOS. If allocated memory isn't initialized then of course whatever happened to be there which wasn't overwritten (in this case padding between segments) would be used.
> This seems like it would be more of a C library issue with malloc than any
> version of DOS.
IIRC it's not a memory allocation issue, but an issue related to file positioning (in a "new" file ). And AFAIR it works well in MS-DOS ( including NTVDM ), but fails in FreeDOS ( and apparently DR-DOS ).
File positioning (INT 21h function 42h) has nothing to do with memory allocation. When memory is allocated in DOS via INT 21h function 48h, DOS only writes the MCB header, it doesn't clear memory. The issue doesn't always appear for me either, it only happens when something else happened to be in memory so the unwritten bytes between segments get written out because they were skipped.
I did say I was running PC DOS 7.0. You do know that MS-DOS and PC DOS were derived from the codebase with IBM essentially being the first OEM of MS-DOS which is why they have OEM ID 00h.
> File positioning (INT 21h function 42h) has nothing to do with memory allocation.
And who did claim otherwise?
> When memory is allocated in DOS via INT 21h function 48h, DOS
> only writes the MCB header, it doesn't clear memory.
Well, yes, I guess that's right. However, please be aware the jwasmd's memory allocation is done via the DOS extender, using extended memory - this means, DOS is not involved at all here.
Issue also occurs with JWASMR.
Issue also happens with MS-DOS 6.22 though that was to be expected since MS-DOS and PC DOS originated from the same codebase. They only started to diverge after DOS 5 though even then there were no API functionality differences to maintain compatibility since both were retail products at that point.
I looked at the source code and I see why it isn't due to uninitialized memory as fseek and fwrite are being used to write a buffer for each segment. Unfortunately this should always be an issue in DOS since the file pointer is being advanced to skip bytes via fseek for segment alignment so the skipped bytes are indeterminate. Even the documentation for the Win32 SetFilePointer function says that when it is used to write beyond EOF to increase the file size the intervening bytes are uninitialized though Windows always seems to zero them which is why the problem isn't seen with JWASM or JWASMD/JWASMR in a NTVDM.