Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[E. C. Masloch via Freedos-devel]

On at 2024-05-03 23:54 -0400, Steve Nickolas via Freedos-devel wrote:
So I've had some thoughts regarding the MS-DOS 4 source drop, regarding 
things I'd like to do with the code.  I'm not really that good of a 
coder and probably would only be able to do some of them myself.  (I'd 
kill for a 3.3 drop - would obviate a lot of these things!  And 5 and 
6.2 even more.)


First big issue, and one I can only partially resolve.  I'm taking a 
strict approach to the contents of the TOOLS folder - want to get rid of 
it and replace it with open-source equivalents.  That means, most 
practically, OpenWatcom 1.9 (there's prolly other options but the more 
like MSC it is the less torturous porting is going to be).  And the 
code's going to need to be dinked as far as possible to roll in Watcom 
instead of MSC - that's going to be a major pain in the neck.


As mentioned before, JWasm is probably going to be useful to replace the 
MASM v5.10 for this. Me, I'm working with the original toolchain for now 
even though it is (free but) closed source.


Some of the code's pretty braindead, too.  Especially what looks to have 
come from IBM.  I mean...house styles vary, but Algolization is still 
just hideous-looking.  But it goes beyond that - think some of the 
utilities are going to need major rewrites.  I'm thinking of writing a 
new front-end around the FDISK code, but I haven't really been able to 
take the code and sort through everything to figure out what parts I'll 
need in order for FDISK to...fdisk (and don't know enough about int13, 
MBR or FAT to do it my damnself).  I was looking into D-Flat, but my 
brain melted - might have to write bespoke UI code.


Additionally, the whole "Message Server" thing.  (I think the broken 
TYPE command when COMMAND.COM is run under FreeDOS is related to this.)  
I'd like to have the feature reduced to compatibility only and use good 
old-fashioned AH=9 like older DOS versions.  It'll probably also iron 
out some of the compile issues I've had trying to port the C stuff to 
Watcom!


The broken TYPE (and COPY) command in the shell is actually due to the 
Extended Attributes functions that the MS-DOS v4.01 kernel "supports". 
In fact, these functions are just placeholders that return an empty list 
and ignore all writes. I wrote about this to dosemu2 [1], as the TYPE 
and COPY commands were broken on dosemu2 redirector drives (even when 
running both command.com and the kernel from the MS-DOS release). The 
error is the command will (on FreeDOS) display "Extended Error 1" when 
trying to display a file using TYPE, or (on MS-DOS on a redirector 
drive) "Invalid function - ". I patched command.com in my fork 
to not require these functions [2].


Writing of which, I also identicalised the binaries to both MS-DOS v4.00 
(matching the original release minus build fixes and encoding problems) 
[3] as well as the MS-DOS v4.01 release [4]. I compared the files to the 
content of disks found at the Internet Archive [5]. The v4.01 patch 
comes from hharte's fork on github [6], but I verified that it matches 
the v4.01 release. I also wrote about the process (regarding the v4.00 
work) on our forum [7]. The most difficult part involved creating a 
small unpacker utility for the select.dat files [8], to allow comparing 
the binary differences in the uncompressed data rather than being stuck 
with the compressed files.


An error that remains is that on the FreeDOS kernel, commands like "ver 
/r" and "mem /p" (using unsupported switches) will not display "Invalid 
switch" or "Invalid switch -  /p" but rather "Parse Error 3".


After these things are ironed out, I guess the next phase would be, 
unless another code drop obviates the effort, to recreate features of 
later versions.  I've actually done this with some apps.  (The obvious 
question: Why not use what FreeDOS already has?  A: Because I'd like to 
have the entirety of the project under a single license - that being the 
X license Microsoft and IBM are already using.)  High memory support - 
big feature of 5.0 - that's a big part of why 5 was considered a _good_ 
version of DOS and 4 wasn't.


I already added one MS-DOS v5 feature: Device drivers are passed the 
maximum valid address that they may allocate [9]. This allows loading 
lDebug as a device driver, albeit an lDebug bugfix is also needed [10].


Regards,
ecm


[1]: https://github.com/dosemu2/dosemu2/issues/2206
[2]: https://hg.pushbx.org/ecm/msdos4/rev/cf97c97c1d9b
[3]: https://hg.pushbx.org/ecm/msdos4/shortlog/63a05668c5f3
[4]: https://hg.pushbx.org/ecm/msdos4/rev/51ad27d225a8
[5]: https://archive.org/details/ms-dos-4.00-and-4.01
[6]: 
https://github.com/hharte/MS-DOS/commit/7e51e4249ee0e6185b4e3eed9902c5cf786f052a#comments

[7]: https://www.bttr-software.de/forum/forum_entry.php?id=21755
[8]: https://hg.pushbx.org/ecm/msdos4/rev/9a0f75e8c341
[9]: https://hg.pushbx.org/ecm/msdos4/rev/814a8eb71ce4
[10]: https://hg.pushbx.org/ecm/ldebug/rev/6c4bbd544091

Re: [Freedos-devel] MS-DOS 4.0 source released as open source under MIT license

[E. C. Masloch via Freedos-devel]

On at 2024-04-26 14:28 -0500, Jim Hall via Freedos-devel wrote:

On Fri, 26 Apr 2024, Bernd Böckmann via Freedos-devel wrote:


Microsoft and IBM released the source code of MS-DOS 4.0 under MIT
license [1]. To me, it looks fairly complete.


On Fri, Apr 26, 2024 at 2:25 AM Steve Nickolas via Freedos-devel
 wrote:


Everything but himem, dosshell, gwbasic, and parts of xmaem/xma2ems,
apparently.  I got most of it compiled using the tools in the archive.



How did you compile it? I'm having trouble getting the compile to work.

Here's what I'm doing: I've booted my system using FreeDOS but using
their tools. My C: drive is FreeDOS, and my D: drive is empty except
for the SRC directory from the MS-DOS 4.0 release on GitHub. I set up
my environment by editing the SETENV.BAT and running it:


@echo off
echo setting up system to build the MS-DOS 4.01 SOURCE BAK...
set COUNTRY=usa-ms
set BAKROOT=D:
rem BAKROOT points to the home drive/directory of the sources.
set LIB=%BAKROOT%\src\lib
set INIT=%BAKROOT%\src\tools
set INCLUDE=%BAKROOT%\src\inc
set PATH=%BAKROOT%\src\tools;C:\freedos\bin
set CL=%INIT%\CL.EXE
set LINK=%INIT%\LINK.EXE
set MASM=%INIT%\MASM.EXE


This is my PATH:


D:\>path
PATH=D:\src\tools;C:\freedos\bin



Yes, I'm really running the Microsoft NMAKE from their tree:


D:\>nmake

Microsoft (R) Program Maintenance Utility   Version 1.00.05
Copyright (c) Microsoft Corp 1987, 1988. All rights reserved.

NMAKE : fatal error U1051: usage : 'NMAKE' [-bcdeinpqrst -f makefile -x stderrfi
le] [macrodefs] [targets]
Stop.



But when I try to build it, it fails in the MAPPER directory with
"line too long":


D:\>cd src
D:\SRC>nmake


I had similar errors, in mapper/getmsg.asm, select/select2.asm, and 
select/usa.inf


For me these turned out to be errors involving a single-byte character 
being expanded to a three-byte UTF-8 encoded value. When nearly a whole 
line (of 80 columns) is filled with these EF BF BD strings then MASM 
(the version shipped with the repo) doesn't like the total line length 
in bytes. I eventually fixed this by running: (After manually deleting a 
few lines to work around the problem.)


> sed -i -re 's/\xEF\xBF\xBD|\xC4\xBF|\xC4\xB4/#/g' FILENAMES...

I had many more errors, starting with nosrvbld.exe running on eg 
boot/boot.skl complaining it couldn't find something. The something was 
named as a bunch of gibberish text however. This, and some other 
problems, turned out to be because git and/or Microsoft spat out text 
files with LF line endings whereas many of the DOS tools expect CR LF 
line endings. The following command worked for me:


> find -iname '*.bat' -o -iname '*.asm' -o -iname '*.skl' -o -iname 
'zero.dat' -o -iname 'locscr' | xargs unix2dos -f


(The zero.dat and locscr files are used to redirect numbers into 
exe2bin's relocation number prompt. Failure to unix2dos those ended up 
hanging dosemu2 and/or ConnectBot, and spamming notifications to 
ConnectBot. Likely related to the old problem of int 21h service 0Ah not 
properly detecting and handling an EOF.)


To successfully compile the C program parts, I had to fix the setenv.bat 
script (apart from using another drive) to point to the headers and 
libraries that actually ship with the repo:


$ cat src/e.bat
@echo off
echo setting up system to build the MS-DOS 4.01 SOURCE BAK...
set CL=
set LINK=
set MASM=
set COUNTRY=usa-ms
set BAKROOT=e:
rem BAKROOT points to the home drive/directory of the sources.
set LIB=%BAKROOT%\src\tools\bld\lib
set INIT=%BAKROOT%\src\tools
set INCLUDE=%BAKROOT%\src\tools\bld\inc
set PATH=%BAKROOT%\src\tools;%PATH%


To boot the kernel, I used lDebug's command BOOT PROTOCOL MSDOS6 hda1/ 
to boot off a file system that I created using my bootimg.asm script. I 
had to set -D_OEM_NAME="'IBM  3.1'" to make the kernel accept my file 
system; with my default it calculated a wrong (at least) Sectors per 
Cluster value of 4 and failed to load the DOS module. This is my command 
line to create the image:


> nasm -I ../../lmacros/ -I ../../bootimg/ ../../bootimg/bootimg.asm 
-D_PAYLOADFILE="io.sys,msdos.sys,mem.exe,sys.com,../../ldebug/bin/callver.com,::rename,../../../.dosemu/drive_c/command.com,freecom.exe,command.com" 
-o disk.img -D_MEDIAID=0F8h -D_BPE=16 -D_ERROR_SMALL32=0 -D_SPF=256 
-D_SPI=128000 -D_SPC=2 -D_MBR -D_MBR_PART_TYPE=fat16_chs 
-D_CHS_HEADS=128 -D_CHS_SECTORS=32 -D_OEM_NAME="'IBM  3.1'"



Regards,
ecm


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FDISK does not respect DLASortByDriveNo config of the kernel

[C. Masloch via Freedos-devel]

On at 2024-01-04 17:46 +0100, Bernd Böckmann via Freedos-devel wrote:

Hi Eric,


I would assume the kernel parameter is neither meant to be queried
at runtime nor is it used by a significant number of people at all.
There is no external API, but you may pull it from RAM, possibly.


No, the CONFIG block is not preserved in memory anywhere. It is loaded 
at linear 602h when the kernel is being loaded in the FreeDOS load 
protocol. Prior to my new exeflat format [1] a UPX-compressed kernel 
would copy it to 5E2h where it would possibly survive for longer, but 
this is no longer the case. The memory at 600h is re-used as the initial 
PSP later.



I would only read kernel RAM directly if the kernel tells me the address, for 
example by using a newly introduced FreeDOS INT 21h extension returning a 
pointer to the config data and its version. Otherwise, if the address changes 
for whatever reason, that would break compatibility.


There are some FreeDOS extensions on interrupt 21h function 33h 
subfunctions [2], including the well-known 21.33FF for a version string 
(now also supported by RxDOS and Enhanced DR-DOS). 21.33F9 seems to be 
the highest unused subfunction number.



Alternatively, you could extract settings from the kernel file of the
boot drive or (better?) try and compare your view of which drive is
which to the kernel in terms of sizes and labels for local drives.


Comparing if the drive letters agree beteween DOS and FDISK should be doable. 
The DPBs should provide everything that is needed, I think. But I have to 
investigate this. It makes only sense doing this once after FDISK started. As 
soon as any operations are performed by the user, the assignments differ anyway.


You actually want to inspect what I call the UPBs, the Unit Parameter 
Blocks. These are called Drive Data Tables by the Interrupt List [3] and 
by the FreeDOS kernel [4], and UDSC (Unit Descriptor?) by EDR-DOS [5]. 
Note that they contain two BPBs, which are actually EBPBs for 
FAT32-enabled FreeDOS and EDR-DOS (probably the same for MS-DOS v7.10 
too). But not so for FAT32-disabled FreeDOS.



Also, that detection thing could provide a command line way for some
"just detect and return errorlevel" mode for use in batch processing.
Or maybe that feature even already is there? :-)


Jerome parses the output of FDISK /info in his installer scripts. But a more extensive and 
easier to parse query interface came into my mind previously. Something like FDISK /query 
, where  may be a bunch of supported query keys, like 
(IS_EMPTY, NUM_PRIMARIES, PART_0_TYPE etc.). First I thought that its a good idea to return 
them as error level. But it is not, because FDISK already uses them to return specific 
error codes if something goes wrong, like failure to read a sector. So currently I think it 
would be better to instead return a single value to stdout, or a list of KEY=VALUE pairs if 
multiple parameters are queried. Not exactly sure it is worth the effort, because this 
rules out using it in batch files without a helper tool, or I am wrong?!?


Key value pairs would be more difficult. A single string output can be 
picked up using FreeCOM's SET /E however, eg:


> set /e variable=fdisk /query what-to-query

Regards,
ecm


[1]: https://github.com/FDOS/kernel/pull/78
[2]: 
https://github.com/FDOS/kernel/blob/db71b1a78337e96a89b4343b8303c6b8c4e6bb14/kernel/inthndlr.c#L143

[3]: https://fd.lod.bz/rbil/interrup/dos_kernel/2f0803.html
[4]: 
https://github.com/FDOS/kernel/blob/db71b1a78337e96a89b4343b8303c6b8c4e6bb14/hdr/device.h#L205

[5]: https://hg.pushbx.org/ecm/edrdos/file/465be5fcbb65/drbio/udsc.equ



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Interim Build Delayed

[C. Masloch via Freedos-devel]

On at 2023-09-01 19:03 +0200, Bernd Böckmann via Freedos-devel wrote:

Well, I think it's me to blame ;-)

I will try to build some compression mechanism into AMB, so that the 
help files get smaller. The main FreeDOS help file would also benefit 
from that, I think.


Bernd


I recently added one of my executable compression formats to my 
debugger's online help, allowing it to "assemble" (build) the help pages 
at build time and then compress them before inclusion (by NASM incbin 
directive) into the main assembly pass. Perhaps you want to copy parts 
of this.


I used the heatshrink library, "A data compression/decompression library 
for embedded/real-time systems." [1]. It is available under the ISC 
License [2]. I created two different depackers, both under the Fair 
License (but feel free to use and copy these under any usage 
conditions). One is the executable depacker, which can deal with data 
(both compressed and decompressed) exceeding 64 KiB, using 8086 
segmented addressing [3]. The other is a bit smaller and assumes that 
all data fits in a single segment each, though the source and 
destination can be in different segments [4].


For the recent lDebug release 6 I did not yet enable these build 
options, although everything is implemented for the in-memory online 
help to be largely compressed. I'm compressing each help page as its own 
data block, unrelated to one another. Despite this, almost all of the 
data does compress down by 20% to 60%. (In heatshrink use, the 
percentage indicates how much of the uncompressed size is dropped to 
reach the compressed size.)


The depacker needs about 300 bytes in my application (for only the 
memory-to-memory depacker). The compression is done in a loop at build 
time [5]. I try every -w parameter from 10 to 14 and every -l parameter 
from 4 to 14 (but -l must be below -w), and use the best result. 
(Usually -w 10 -l 4.) (I just found that the valid ranges for the 
parameters are actually larger than this, still testing how well those 
work.) I use a slightly modified compressed file format, in which the 
first byte is the -w parameter and the second byte is the -l parameter, 
and then the original compressed data file is appended. The depacker 
needs to know the packed size to know when to end depacking. In my 
debugger's depacker, I append a NUL byte at the end for the user to know 
how long the unpacked data is, but this could be modified easily to 
return the size.


Regards,
ecm


[1]: https://github.com/atomicobject/heatshrink
[2]: 
https://github.com/atomicobject/heatshrink/blob/7d419e1fa4830d0b919b9b6a91fe2fb786cf3280/LICENSE

[3]: https://hg.pushbx.org/ecm/inicomp/file/41860de1db0e/heatshr.asm
[4]: 
https://hg.pushbx.org/ecm/ldebug/file/654bf2cbfffb/source/hshrink.asm#l208

[5]: https://hg.pushbx.org/ecm/ldebug/file/654bf2cbfffb/source/mak.sh#l309


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Booting FreeDOS kernel without a 386

[C. Masloch via Freedos-devel]

On at 2023-08-02 15:27 +0800, Paul Edwards via Freedos-devel wrote:


 > FreeDOS should run on 8086, both kernel and shell. If it doesn't,
 > that's a bug or omission.

Are you sure? I thought I was told that the standard
distribution relied on an 80386.

 > ke20xx_32.zip : binaries for 8086, FAT16, FAT32

I got this, and then renamed my kernel.sys to kernel.old,
then copied this new kernel.sys onto the disk, and then
started it under an emulator and it worked fine (as before).

I have no way of knowing whether it was actually using the
new kernel.sys.

The act of renaming kernel.sys to kernel.old would have
left it as the first file on the disk. I was under the
impression that the boot sector of Freedos would allow
the kernel.sys to reside as something other than the
first file, so I expected this to be a valid test and
to skip the kernel.old and use the new kernel.sys.


Yes, this is valid. All FreeDOS kernel loaders only load based on the 
filename, not the position of the file data or directory entries within 
the file system.



Please let me know if this is an invalid test.

Regardless, I then burned the image onto the CF and
booted on the Book 8088 and I got the same problem.
"loading freedos" followed by incessant beeping.


The only boot loader that displays this message is boot32lb.asm [1]. 
This boot loader happens to display the message, first thing [2]. 
However, after this it starts using 386-only instructions.


I assume that your file system is FAT32? Otherwise I don't know how you 
could get this message. How large is your file system?


Anyway, FreeDOS's SYS utility determines whether to use the 386+ LBA 
FAT32 loader or the 8086 CHS FAT32 loader based on whether the current 
machine's first HDD (unit 80h) has LBA extensions available or not [3]. 
This obviously fails in your case as you don't want to boot from the 
same machine as what you're using to install.


It isn't fully documented in the help page [4], but you can choose which 
FAT32 loader is installed using the /FORCE option, setting it either to 
/FORCE:LBA or /FORCE:CHS [5]. This will cause the use of "fat32chs" 
(from the source file boot32.asm rather than boot32lb.asm) [6]. The CHS 
FAT32 loader is also 8086-compatible.


I also copied some files to a directory on my server [7]. The sys.com 
and kernel.sys are both from my automatic kernel build [8]. Likewise the 
fat12com.bin, fat16com.bin, fat32chs.bin (8086), and fat32lba.bin 
(386+). It also has command.com from my automatic FreeCOM build [9]. The 
original FreeDOS FAT12 and FAT16 loaders are always 8086-compatible.



Other than that there is instnone.com, created from the instsect repo 
[10] + lmacros [11] like so:


nasm -I ../../../proj/lmacros/ ../../../proj/instsect/instsect.asm -o 
instnone.com -D_FAT12=0 -D_FAT16=0 -D_FAT32=0


This DOS program can be used to install a boot sector loader into a 
FAT12, FAT16, or FAT32 file system. The build options are to disable 
embedding any loaders into the program itself. You can use the /S 
options to load loaders from external files, which must be either 512 
bytes in size or (for the FAT32 FSIBOOT loaders) 1024 bytes. The 
instsect program can operate on DOS drives or on image files, using the 
/M option. Command help is available using the /? option.



There are also three FreeDOS-compatible boot loaders that I wrote, in 
the files boot12c.bin, boot16c.bin, and boot32.bin. These were created 
from the ldosboot repo [12] + lmacros [11] like so:


nasm -I ../../../proj/lmacros/ ../../../proj/ldosboot/boot.asm 
-D_COMPAT_FREEDOS -D_LBA=0 -D_RPL=0 -o boot12c.bin


nasm -I ../../../proj/lmacros/ ../../../proj/ldosboot/boot.asm 
-D_COMPAT_FREEDOS -D_LBA=0 -D_RPL=0 -o boot16c.bin -D_FAT16


nasm -I ../../../proj/lmacros/ ../../../proj/ldosboot/boot32.asm 
-D_COMPAT_FREEDOS -o boot32.bin


The boot32.bin loader uses my FSIBOOT method, requiring the FAT32 file 
system to have an FSINFO sector. Other than that, it will try to use LBA 
and fall back to CHS if not found. It will try to query the geometry 
using int 13h function 08h. And it will use the hidden sectors passed 
from an MBR loader, if detected. And of course it is all 8086-compatible.


The boot12c.bin and boot16c.bin loaders are also 8086-compatible and 
detect the geometry and hidden sectors like the FAT32 loader. However, 
they will never use LBA. If a sector to read is outside the 
CHS-addressable space, then the loader will detect this [13] and display 
the error code letter "R" [14]. The RPL support is also in part disabled 
in these files. Disabling some options is needed to make the loaders fit 
into the available space for the FreeDOS kernel load protocol.



You can use any of the *.bin files with instsect by running a command 
like this:


instnone.com /S12=boot12c.bin /S16=boot16c.bin /S32=boot32.bin E:

The drive letter E: is of course an example. It can be replaced by an 
/M= option to install into an image file instead of a DOS drive. As 
specified in 

Re: [Freedos-devel] ANSI for DOS

[C. Masloch via Freedos-devel]

On at 2023-07-31 08:44 -0500, Jim Hall via Freedos-devel wrote:

FYI: Your post was 104 lines and 618 words. How-to articles on
websites are between 500 and 800 words, so this email was a bit long.
:-/

The point is you have released a new microemacs?


There is some more context to all of this in our forum [1], for those 
who may be interested.


I think the point was to ask for FreeCOM to support escape sequences 
that a terminal may send instead of scancodes. Consider these parts:



Since I only run the one fullscreen app, I thought I wouldn't
be affected by reassigning the cursor keys.

However, it turns out that there was something I was using -
freecom! So now I can't do command recall.


...


I was thinking that maybe the freecom folk would like to add
ANSI escapes as an option. How else can you handle when
the ctty or whatever the DOS command is to redirect input
to a com port? If you attach a VT100, you will need to handle
the ANSI escapes.


...


Note that I have a different goal to most people. Most people
want to run DOS-era software. I want to redefine the DOS era
now that the "rush to market" is long over.


I think this is a decent idea. In my debugger's "getinput" function [2], 
which may be used instead of the DOS interrupt 21h function 0Ah line 
input editing function, I accept a number of escape sequences for keys 
like the Arrow keys, Home, End, etc.


The "getc" function may return a scancode in the upper byte (ah), either 
from the DOS interrupt 21h function 08h (it can pass on scancodes by 
first emitting a zero byte, then the scancode) or from the ROM-BIOS 
interrupt 16h. These scancodes are handled first [3].


If none of those matched, we check for an escape sequence started by an 
Esc byte (1Bh) in the lower byte (al), followed by an "[" and then one 
or two bytes specifying what keypress is being passed on [4]. This works 
with the escape sequences sent by some older revisions of dosemu2 in 
"-dumb -td -kt" mode, and also with those sent by my Linux terminal when 
running picocom connected to the serial I/O of the debugger.


So the OP seems to be asking to add support for such escape sequences to 
FreeCOM's line editor. (I believe FreeCOM never uses int 21h function 
0Ah, which is how it can provide its own line editing and history 
facility -- much like lDebug does if you "INSTALL GETINPUT".)


Regards,
ecm


[1]: https://www.bttr-software.de/forum/forum_entry.php?id=20443
[2]: 
https://hg.pushbx.org/ecm/ldebug/file/40e54cb4f0db/source/lineio.asm#l2802
[3]: 
https://hg.pushbx.org/ecm/ldebug/file/40e54cb4f0db/source/lineio.asm#l3098
[4]: 
https://hg.pushbx.org/ecm/ldebug/file/40e54cb4f0db/source/lineio.asm#l3121



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] trying to understand execrh.asm -- calls to EXECRH cause my 286 system to lock up

[C. Masloch]

On at 2023-05-09 21:02 -0500, rehsd.i...@gmail.com wrote:

Thanks again, Eric, for the previous info. I've done a bit more digging but
haven't found the root cause of the issue yet. I have tried forcing LBA
(using sys & sys config). I have also added a bit more debugging info on
boot. I added more details to the following webpage, including a video
walkthrough trying to better describe the issue, in case anyone is bored or
just looking for a challenge. In execrh(), there are a pair of calls (likely
to a disk driver); the first of these calls ("call far the strategy") is
where I run into the issue. I'm not sure what "strategy" means in this
context.


The so-called strategy and interrupt entrypoints to DOS device drivers 
are just part of the device interface, used by both block device drivers 
(sector-based) and character device drivers (text-/byte-based).


You can read more about the device driver header in the interrupt list 
[1], and also about the request header contents used by the various 
function numbers [2]. There are some books describing this, too.


Technically, the two entrypoints are always far-called from the kernel 
back to back, and the actual work by the device driver can happen in the 
strategy entrypoint or in the interrupt entrypoint. Traditionally, the 
strategy only ever saves the pointer it received into a buffer internal 
to the device, and then the interrupt actually carries out the requested 
command.



Possibly, the right information isn't being passed into the
execrh() routine, due to a failure at an earlier point. I plan to start
stripping down the kernel next -- to simplify testing and see what I can
learn.
https://www.rehsdonline.com/post/troubleshooting-freedos-boot-on-my-286-syst
em-hangs-on-execrh-call-in-kernel


If the strategy call doesn't return to the kernel soon it probably 
called a bad pointer. Look at the source for the block device header 
[3]. It uses GenStrategy as its strategy entrypoint, this only saves the 
pointer [4]. The interrupt entrypoint is specific to the block device 
[5], and it dispatches into a table in the C sources [6]. If you use a 
kernel debugger you can break on and step into the far calls to the 
strategy and interrupt entries to make sure they work as expected.


Regards,
ecm


[1]: https://fd.lod.bz/rbil/interrup/dos_kernel/2152.html#table-01646
[2]: https://fd.lod.bz/rbil/interrup/dos_kernel/2f0802.html#table-02595
[3]: 
https://github.com/FDOS/kernel/blob/afe7fbe068bf7f3cc99dc01bf8e402311095757b/kernel/io.asm#L165
[4]: 
https://github.com/FDOS/kernel/blob/afe7fbe068bf7f3cc99dc01bf8e402311095757b/kernel/io.asm#L202
[5]: 
https://github.com/FDOS/kernel/blob/afe7fbe068bf7f3cc99dc01bf8e402311095757b/kernel/io.asm#L521
[6]: 
https://github.com/FDOS/kernel/blob/afe7fbe068bf7f3cc99dc01bf8e402311095757b/kernel/dsk.c#L132



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] stack setup in BIOS, prior to loading FreeDOS

[C. Masloch]

On at 2023-05-13 18:09 -0500, rehsd.i...@gmail.com wrote:

I am working to get FreeDOS running on my 286 system. As part of this, I am
trying to improve my BIOS code. As I look at the stack setup when the system
initializes, I am using the following.

; org 0x
xor ax, ax
mov ds, ax
mov bp, 0x8000
mov ss, ax
mov sp, bp
mov ax, 0xf000  ; ROM data
mov es, ax

Based on https://en.wikibooks.org/wiki/X86_Assembly/Bootloaders and
https://github.com/kaneton/appendix-bios (and as I understand it), 0x8000 is
used for bp and sp upon system initialization. I expect FreeDOS changes the
location of the stack multiple times during boot as the boot sector is
loaded/moved and as the kernel is loaded.

Am I OK with the stack setup I am using prior to loading FreeDOS, or should
I consider a different/better approach?


Assuming 512 Bytes per sector, your choice of 0:8000h for ss:sp is 
sufficient to allow the initial boot sector loader entry to utilise 512 
Bytes of stack space (linear 7E00h to 8000h). This is fine. However, in 
my bootloadable debugger I chose to use 0:7C00h for loading a sector 
(MBR or partition boot sector) instead, which gives a much larger stack 
[1]. For its BOOT PROTOCOL CHAIN command I use some common loader code 
which happens to set ss:sp to 0:7BF0h (sp = 7C00h minus 10h) by default [2].


You're correct that DOS loaders and kernels will relocate the stack 
several times. Therefore it really doesn't matter much what default 
stack you set up before you run the loader, it just shouldn't collide 
with any memory that is in use (IVT, BDA, EBDA if any, boot sector 
itself, video memory, ROMs).


Here's where FreeDOS's kernel sets up a new stack early on: [3]

And here, as an example, the FAT12/FAT16 boot sector loader also sets up 
its own stack early on: [4]  This sets up the stack as 1FE0h:7BA0h, 
after relocating the loader itself to that position to make space for 
the kernel file data.


One more note: You should always set ss in the instruction immediately 
before the one that sets sp. You're already doing that here. It is 
important to keep in mind if you edit your sources, however. This is 
because writing only ss will generally lock out interrupts until after 
the next instruction has run, to allow atomic changes of the current stack.


Regards,
ecm


[1]: https://hg.pushbx.org/ecm/ldebug/file/861707b9adc5/source/boot.asm#l789
[2]: 
https://hg.pushbx.org/ecm/ldebug/file/861707b9adc5/source/boot.asm#l2529
[3]: 
https://github.com/FDOS/kernel/blob/afe7fbe068bf7f3cc99dc01bf8e402311095757b/kernel/kernel.asm#L220
[4]: 
https://github.com/FDOS/kernel/blob/afe7fbe068bf7f3cc99dc01bf8e402311095757b/boot/boot.asm#L183



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Logger v0.1 (beta)

[C. Masloch]

On at 2023-05-02 17:50 -0400, jer...@shidel.net wrote:

Hi,


On May 2, 2023, at 2:15 PM, C. Masloch  wrote:

On at 2023-05-01 23:55 -0400, jer...@shidel.net wrote:

Hi All,
Yesterday, I released the new version of Logger. It has come a long way since 
the first Alpha release and works great. I made some final decisions on a 
couple aspects and it is now in the Beta stage. Other than some probable byte 
squeezing, there is only one other possible feature I might add before the 
final version 1.0 is released (see below).
https://fd.lod.bz/repos/current/pkg-html/logger.html 
<https://fd.lod.bz/repos/current/pkg-html/logger.html>
Here is a summary of the major changes and final decisions I made since the 
Alpha-7 release:
  * Interface can export the log as HTML in full color.
  * Driver supports VESA mode changes.
  * Driver supports AMIS and IISP.
  * Driver provides the ability to check status, enable/disable logging,
clear and append the log through an API.
  * API is usable through AMIS or by direct far call to driver by other
programs.
  * Driver and Interface will be released as a single dual-mode binary.
(popular request)
  * Release includes very small and simple API examples. (For example, a
141 byte COM program with source to append the log.)
  * Release includes UPX’d driver only version for usage on limited
capacity media like boot floppies when needed.
Adding AMIS, IISP and the API increased the memory resident footprint of the 
driver by approximately 30%. But, that is still only a total memory footprint 
of 1,472 bytes for the 0.1-BETA version. I think those features are worth the 
couple hundred bytes required for their support. There is no API documentation 
at present. Instead, I included simple examples that include all the different 
API functions.


I reviewed your AMIS implementation [1]. Here's what I noted:

* You still use the jmp / jmp / retf structure for the IISP headers. The simplest 
improvement is to put the "retf" before the header, which already saves you two 
bytes per header.


I changed that this morning. Just haven’t pushed a commit yet. The IISP macro 
can now accept an label for that RETF. If no label is provided, it would use 
the jmp/jmp/retf. Providing a label saves 4 bytes. But, I like the idea of 
putting the RETF before the header. So, I’ll adjust the macro to do that when a 
RETF label is not supplied.


Your latest code [1] has an error: If only one parameter is given, it 
will write a retf, then the header, then (as before) a jmp and retf. The 
second retf at .FarReturnIISP appears to be unused, and it seems you 
forgot to delete it once you implemented the %1_FAR_RETURN placement 
before the header.



[1]: 
https://gitlab.com/DOSx86/logger/-/blob/68952313d0bfa91321a3451b2a335ada70e7504a/source/logger/common.inc#L263



* The %%PrivateEntry code could hardcode the bx response in an immediate "mov bx, 
imm16" instruction, saving at least 2 bytes. Like the multiplex number you could 
patch this instruction's data if it isn't a constant.


Great catch. Don’t know what I was thinking when I used the value stored in the 
Device Header for direct driver calls. It could move from version to version. 
But, It won’t change during execution.



* The %%Uninstall response code 06h is commented by you as "cannot remove, loaded in config.sys" 
but in the specification it says "disabled, but can not be removed from memory because loaded from 
CONFIG.SYS". The "disabled" indicates that you should have disabled your resident program when 
you return this function code. (As I mentioned before, the uninstall function return codes in the current 
AMIS leave things to be desired.)


Thanks, I mis-read that as being the “uninstall function” is disabled.

I’m going to change it to 0x05 “not safe, try again later” or maybe just 0x01 
“unsuccessful” would be better.


I would go with 01h or 00h. Let me look it up, ah yeah I am returning 
zero in my debugger. [2]



[2]: https://hg.pushbx.org/ecm/ldebug/file/73873421b18d/source/amis.asm#l46


Later when I add TSR mode support, I’ll probably have that supplied by the 
interface portion and not use 0x03, 0x04 or 0x07.


* In %%InterruptList you can share the "mov dx, cs" instruction (followed by 
iret) with the %%Respond code if you re-order the instructions in the latter.

* Your %%GetDriverInfo is wrong. ah should receive the "device-driver flags". You should return the value 1 (program 
loaded from CONFIG.SYS). And al should receive the "number of device driver headers supplied by program". You set al = 
0FFh currently. To set both ah and al at once, you can use a "mov ax, imm16" instruction. That is, "mov ax, 
0101h". (This function is one of the few AMIS functions that modify ah. The "return at dx:bx with ax destroyed" 
for uninstall is the other.)


I was just returning ah as 0 (unable to det

Re: [Freedos-devel] Logger v0.1 (beta)

[C. Masloch]

On at 2023-05-01 23:55 -0400, jer...@shidel.net wrote:

Hi All,

Yesterday, I released the new version of Logger. It has come a long way 
since the first Alpha release and works great. I made some final 
decisions on a couple aspects and it is now in the Beta stage. Other 
than some probable byte squeezing, there is only one other possible 
feature I might add before the final version 1.0 is released (see below).


https://fd.lod.bz/repos/current/pkg-html/logger.html 



Here is a summary of the major changes and final decisions I made since 
the Alpha-7 release:


  * Interface can export the log as HTML in full color.
  * Driver supports VESA mode changes.
  * Driver supports AMIS and IISP.
  * Driver provides the ability to check status, enable/disable logging,
clear and append the log through an API.
  * API is usable through AMIS or by direct far call to driver by other
programs.
  * Driver and Interface will be released as a single dual-mode binary.
(popular request)
  * Release includes very small and simple API examples. (For example, a
141 byte COM program with source to append the log.)
  * Release includes UPX’d driver only version for usage on limited
capacity media like boot floppies when needed.


Adding AMIS, IISP and the API increased the memory resident footprint of 
the driver by approximately 30%. But, that is still only a total memory 
footprint of 1,472 bytes for the 0.1-BETA version. I think those 
features are worth the couple hundred bytes required for their support. 
There is no API documentation at present. Instead, I included simple 
examples that include all the different API functions.


I reviewed your AMIS implementation [1]. Here's what I noted:

* You still use the jmp / jmp / retf structure for the IISP headers. The 
simplest improvement is to put the "retf" before the header, which 
already saves you two bytes per header.


* The %%PrivateEntry code could hardcode the bx response in an immediate 
"mov bx, imm16" instruction, saving at least 2 bytes. Like the multiplex 
number you could patch this instruction's data if it isn't a constant.


* The %%Uninstall response code 06h is commented by you as "cannot 
remove, loaded in config.sys" but in the specification it says 
"disabled, but can not be removed from memory because loaded from 
CONFIG.SYS". The "disabled" indicates that you should have disabled your 
resident program when you return this function code. (As I mentioned 
before, the uninstall function return codes in the current AMIS leave 
things to be desired.)


* In %%InterruptList you can share the "mov dx, cs" instruction 
(followed by iret) with the %%Respond code if you re-order the 
instructions in the latter.


* Your %%GetDriverInfo is wrong. ah should receive the "device-driver 
flags". You should return the value 1 (program loaded from CONFIG.SYS). 
And al should receive the "number of device driver headers supplied by 
program". You set al = 0FFh currently. To set both ah and al at once, 
you can use a "mov ax, imm16" instruction. That is, "mov ax, 0101h". 
(This function is one of the few AMIS functions that modify ah. The 
"return at dx:bx with ax destroyed" for uninstall is the other.)



I also briefly checked out your example programs [2].

* Unneeded cld in Driver_locate

* You handle all return codes in al except al == 0FFh by jumping to 
.Next, so a single comparison and branch would suffice instead of two.


* "inc bh" already sets the Zero Flag if the multiplex number wrapped 
around, so you don't need to run a "test bh, bh" afterwards.


* The PrintLoop "cmp si, 82h" instruction is confusing to me. Either it 
is wrong, or I don't understand it. Seems like at least a comment would 
be appropriate.


* It would be more efficient to write a zero terminator behind the 
command line tail, then write the entire command line in one call to the 
multiplexer. If you were willing to display them in the same colour you 
could even add in the CR LF sequence after the text, to reduce the 
number of calls to one instead of two.



[1]: 
https://gitlab.com/DOSx86/logger/-/blob/38ff575223bc8739dbdfc3251a08b19b99299fac/source/logger/hookamis.inc#L116
[2]: 
https://gitlab.com/DOSx86/logger/-/blob/38ff575223bc8739dbdfc3251a08b19b99299fac/doc/logger/devel/log-msg.asm



The addition of the API and inclusion of the UPX’ed driver only version 
makes the size of the single dual-mode binary much less important for 
usage on boot floppy diskettes. For example, if it were used with the 
FreeDOS install media, only 2.6kb would be required for the driver. If 
non-user visible debug messages are desired, the simple 141 byte demo 
“add message” program could be used. This would consume about 3kb of 
disk space instead of the roughly 10kb used buy the dual-mode binary. As 
a bonus, having a batch execute the small demo program repeatedly would 
be much faster than launching the bigger program to 

Re: [Freedos-devel] Logger

[C. Masloch]

A few additions to my prior mail:

On at 2023-05-01 13:04 +0200, C. Masloch wrote:

On at 2023-04-28 13:51 -0400, jer...@shidel.net wrote:

Hi All,

Logger is coming along great and I’m currently working on the final 
ALPHA-8 version. Once that is done, it will be time for a BETA or two. 
Then finally version 1.0.


Your IISP headers could store the required retf at a place other than 
after the header. This would save the short jump that you use to skip 
the retf. If you put the int 2Dh handler right after the resident device 
strategy handler, you could re-use the strategy handler's retf for the 
int 2Dh IISP header. Likewise the int 10h IISP header if it is close 
enough.


In my IISP header macro, iispentry [1], I can pass a label to use for 
the retf in one of the parameters. Also, it now by default aligns the 
IISP header to a word-boundary to slightly speed up accesses of the 
ieNext pointer.


It is good that your ieEntry jump already is the expected 10EBh, a jump 
to what I call ieStart. This is required for fully standard IISP 
headers, and Ralf Brown's programs expect this exact value there.


Other than that I didn't look at all your code yet for more optimisations.


[1]: https://hg.pushbx.org/ecm/ldebug/file/ab7d7f8b72d5/source/AMIS.MAC#l44


You can use a "jmp strict short" instruction in NASM to make sure that a 
short jump is assembled, and an error raised otherwise.


Here's the results of building my compressed dual-mode Logger 
executable, compressed using LZIP (high ratio, slow) and LZSA2 (faster):


This wasn't very readable so I will list the commands separately:

This is the LZIP compression command:

logger/BIN$ lzip -9vvfkc LOGGER.COM > logger.lz
LOGGER.COM:  1.650:1, 60.62% ratio, 39.38% saved, 9240 in, 5601 out.


This is the assembler command to build the inicomp stage:

logger/BIN$ nasm ../../inicomp/inicomp.asm -I ../../lmacros/ -I 
../../inicomp/ -D_LZD -o loggerlz.com -D_PAYLOAD_FILE="'logger.lz'" 
-D_IMAGE_EXE=1 -D_IMAGE_EXE_AUTO_STACK=0 -D_DEVICE=1 
-D_DEVICE_ZERO_ENTRYPOINT=1 -D_DEVICE_ATTRIBUTE=8000h 
-D_DEVICE_NAME="'LOGGERxx'" -D_IMAGE_EXE_CS=-16 -D_IMAGE_EXE_IP=256 
-D_IMAGE_EXE_GET_COM_STACK -D_BOOTLDR=0 -D_ALLOW_OVERLAPPING=0

../../inicomp/lzd.asm:698: warning: localvariables has 14688 bytes [-w+user]
../../inicomp/inicomp.asm:1320: warning: inilz: 2992 bytes used for 
depacker [-w+user]



The -I switches above are needed so that NASM finds the include files. 
The lmacros and inicomp repo are both available from my hg repositories [1].


The -D_LZD switch tells inicomp what depacker to use.

-o specifies the output filename.

-D_PAYLOAD_FILE= specifies the payload file, and must be passed twice 
quoted from bash to NASM so that NASM ends up with a quoted string define.


-D_IMAGE_EXE enables the exe mode handling. Likewise, -D_DEVICE enables 
the device mode handling.


-D_IMAGE_EXE_AUTO_STACK disables passthrough of the depacker's stack. 
Instead, the ss:sp is set up as -16:0FFFEh from the program image 
address. That is, ss = PSP and sp = 0FFFEh.


-D_DEVICE_ZERO_ENTRYPOINT enables the jump within the device header, 
required for flat .COM style dual-mode executables.


-D_DEVICE_ATTRIBUTE and -D_DEVICE_NAME should be set up to match the 
compressed device driver header's.


-D_IMAGE_EXE_CS and -D_IMAGE_EXE_IP set up the initial cs:ip as -16:256, 
matching the normal flat .COM style entry.


-D_IMAGE_EXE_GET_COM_STACK is required to set up the expected stack for 
the depacker. It uses ss as the upper limit of memory available to it 
for depacking.


-D_BOOTLDR=0 and -D_ALLOW_OVERLAPPING=0 are some small optimisations.


This is the LZSA2 compression command:

logger/BIN$ lzsa -c -f2 --prefer-ratio -v LOGGER.COM logger.sa2
Compressed 'LOGGER.COM' in 0.072056 seconds, 0.12 Mb/s, 1141 tokens 
(8.09816 bytes/token), 9240 into 6050 bytes ==> 65.4762 %

Compared 'logger.sa2' in 3.9e-05 seconds, 225.947 Mb/s


Finally, the assembler command to build the LZSA2-packed executable. 
This is the same as above but with -D_LZSA2 and the different output and 
payload filenames.


logger/BIN$ nasm ../../inicomp/inicomp.asm -I ../../lmacros/ -I 
../../inicomp/ -D_LZSA2 -o loggersa.com -D_PAYLOAD_FILE="'logger.sa2'" 
-D_IMAGE_EXE=1 -D_IMAGE_EXE_AUTO_STACK=0 -D_DEVICE=1 
-D_DEVICE_ZERO_ENTRYPOINT=1 -D_DEVICE_ATTRIBUTE=8000h 
-D_DEVICE_NAME="'LOGGERxx'" -D_IMAGE_EXE_CS=-16 -D_IMAGE_EXE_IP=256 
-D_IMAGE_EXE_GET_COM_STACK -D_BOOTLDR=0 -D_ALLOW_OVERLAPPING=0
../../inicomp/inicomp.asm:1320: warning: inilzsa2: 1392 bytes used for 
depacker [-w+user]



This is the resulting files:

logger/BIN$ ls -lgG
total 48
-rw-r--r-- 1 9240 May  1 11:10 LOGGER.COM
-rw-r--r-- 1 5601 May  1 12:21 logger.lz
-rw-r--r-- 1 8608 May  1 12:21 loggerlz.com
-rw-r--r-- 1 6050 May  1 12:21 logger.sa2
-rw-r--r-- 1 7456 May  1 12:21 loggersa.com
logger/BIN$


Regards,
ecm


[1]: https://hg.pushbx.org/ecm/

Re: [Freedos-devel] Logger

[C. Masloch]

On at 2023-04-28 13:51 -0400, jer...@shidel.net wrote:

Hi All,

Logger is coming along great and I’m currently working on the final ALPHA-8 
version. Once that is done, it will be time for a BETA or two. Then finally 
version 1.0.


Your IISP headers could store the required retf at a place other than 
after the header. This would save the short jump that you use to skip 
the retf. If you put the int 2Dh handler right after the resident device 
strategy handler, you could re-use the strategy handler's retf for the 
int 2Dh IISP header. Likewise the int 10h IISP header if it is close enough.


In my IISP header macro, iispentry [1], I can pass a label to use for 
the retf in one of the parameters. Also, it now by default aligns the 
IISP header to a word-boundary to slightly speed up accesses of the 
ieNext pointer.


It is good that your ieEntry jump already is the expected 10EBh, a jump 
to what I call ieStart. This is required for fully standard IISP 
headers, and Ralf Brown's programs expect this exact value there.


Other than that I didn't look at all your code yet for more optimisations.


[1]: https://hg.pushbx.org/ecm/ldebug/file/ab7d7f8b72d5/source/AMIS.MAC#l44



For fun, I decided to implement a single binary compiler directive. When 
enabled, it generates a single COM that acts as both the driver and interface 
program. But, I am unsure if I will use that or the dual (SYS+COM) build for 
the 1.0 release.

Mostly, it comes down to the size of the binary. At present, both the driver and 
interface programs are UPX compressible. Their uncompressed size are about 3k & 
6k respectively. So, when space may be tight on a boot floppy, the driver will only 
need about 2.5k (UPX’d) of diskette space. Also if the interface program is used in 
batch files to append debugging comment messages (not shown to the user) directly 
to the log, it requires loading just the 4k (UPX'ed) interface program .

When compiled as a single COM for both the driver and interface, UPX 
compression cannot be used and the binary is about 9k at present. Because there 
is some common (or at least similar code) shared between the driver and 
interface, this could most likely be reduced by 1 or 2k in some future version. 
But that level of optimization will not happen anytime soon. I have other 
things of much higher priorities that need doing.

So, the single COM will require almost 4 times the space of the dual binary 
format. While it may not matter much for Hard Drives, CD-ROMs and USB sticks, 
it could matter a lot for a floppy.

I guess for version 1.0, it could include the SYS and the single binary COM. 
But, that could be confusing. Probably better to go with either the dual 
binaries or just the single binary. And, I am leaning towards the dual binaries 
for version 1.0.


I adjusted my inicomp stage slightly, originally an lDOS boot iniload 
stage, to allow using it to compress the dual-mode (single binary) 
Logger. First change was to allow setting up a stack based on the flat 
.COM style entrypoint [2]. The second option is for a very small 
optimisation that disables boot-loaded mode entrypoints into the stage 
[3]. Then I modified Logger's log-drvr.asm to use the entrypoints 
expected by inicomp for the device header [4].


During rebuilding Logger I found that a very recent NASM version, like 
2.16 ish, is required to build. This is because you use the istruc 
support of struc local labels, which was added to the standard macros in 
[5]. Rebuilding also required to work around a new NASM problem [6]. The 
new macros could be used in an older NASM as well, if you included some 
%unmacro lines and the new macros in your sources. NASM is under the 
2-clause BSD license [7] so you could copy their macros.


Here's the results of building my compressed dual-mode Logger 
executable, compressed using LZIP (high ratio, slow) and LZSA2 (faster):


logger/BIN$ lzip -9vvfkc LOGGER.COM > logger.lz 
  LOGGER.COM:  1.650:1, 60.62% ratio, 39.38% saved, 9240 in, 
5601 out.  logger/BIN$ nasm ../../inicomp/inicomp.asm -I 
../../lmacros/ -I ../../inicomp/ -D_LZD -o loggerlz.com 
-D_PAYLOAD_FILE="'logger.lz'" -D_IMAGE_EXE=1 -D_IMAGE_EXE_AUTO_STACK=0 
-D_DEVICE=1 -D_DEVICE_ZERO_ENTRYPOINT=1 -D_DEVICE_ATTRIBUTE=8000h 
-D_DEVICE_NAME="'LOGGERxx'" -D_IMAGE_EXE_CS=-16 -D_IMAGE_EXE_IP=256 
-D_IMAGE_EXE_GET_COM_STACK -D_BOOTLDR=0 -D_ALLOW_OVERLAPPING=0

../../inicomp/lzd.asm:698: warning: localvariables has 14688 bytes [-w+user]
../../inicomp/inicomp.asm:1320: warning: inilz: 2992 bytes used for 
depacker [-w+user]
logger/BIN$ lzsa -c -f2 --prefer-ratio -v LOGGER.COM logger.sa2 
Compressed 'LOGGER.COM' in 0.072056 seconds, 0.12 Mb/s, 1141 
tokens (8.09816 bytes/token), 9240 into 6050 bytes ==> 65.4762 % 
   Compared 'logger.sa2' in 3.9e-05 seconds, 
225.947 Mb/s  logger/BIN$ nasm 
../../inicomp/inicomp.asm -I ../../lmacros/ -I ../../inicomp/ -D_LZSA2 
-o loggersa.com 

Re: [Freedos-devel] CPU flags register not updating on interrupt calls

[C. Masloch]

On at 2023-05-01 01:45 -0500, Rugxulo wrote:

Hi,

On Sun, Apr 30, 2023 at 4:54 PM  wrote:


In, kernel/pcb.h, I see some notes about “offsets must match the assembly 
process”
and a couple of different layouts for the offsets. Could this be related to the 
issue I am having?
I am using NASM 2.16.01 and Watcom 1.9.


Someone reported that there was a regression in OMF/OBJ for NASM
2.16.01 regarding 16-bit segments.

Try reverting to NASM 2.15.05 instead:

* 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/2.15.05/

Or, for really having fun, try the ancient 0.98.39 16-bit version:

* 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/


Please point to the exact bug report if you make claims like this. It 
wasn't actually anything to do with such a regression however.


Regards,
ecm


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] CPU flags register not updating on interrupt calls

[C. Masloch]

On at 2023-04-30 17:19 -0500, rehsd.i...@gmail.com wrote:
Not sure if it’s bad etiquette to reply to your own post, but… I may 
just need to change out my “iret” with “ret 2”. I’m doing some testing…


Rich


In NASM you can indeed use this as an alternative, but you need *far* 
return, that is "retf 2". However, I do not recommend this choice.


Instead, you can use a lahf or rcr \ rol trick to pass back either all 
arithmetic status flags (excepting the Overflow Flag) or only the Carry 
Flag. The core of your problem is that you were trying to set the 
current flags *in the interrupt handler*. But once you run an iret 
instruction, it pops the flags off the interrupt return stack frame. So 
to return flags to your caller, you either have to go with retf 2 (with 
all its problems) or modify the flags image in the stack frame before 
you run iret.


I recently commented on similar problems in [1] and [2]. I also gave an 
example from my SEEKEXT tool [3]:


.iret_CF:
push bp
mov bp, sp
rcr byte [bp + 6], 1; flip
rol byte [bp + 6], 1; flop
pop bp
iret

One of the reports [2] also contains an lahf example:

push bp
mov bp, sp
push ax
lahf
; bp + 0 = saved bp
; bp + 2 = ip
; bp + 4 = cs
; bp + 6 = fl
mov byte [bp + 6], ah
pop ax
pop bp
iret


[1]: https://github.com/640-KB/GLaBIOS/issues/20
[2]: https://github.com/MobyGamer/softhddi/issues/1
[3]: https://hg.pushbx.org/ecm/seekext/file/bbfcfa0d1c0b/resident.asm#l254


Regards,
ecm


*From:* rehsd.i...@gmail.com 
*Sent:* Sunday, April 30, 2023 4:53 PM
*To:* freedos-devel@lists.sourceforge.net
*Subject:* CPU flags register not updating on interrupt calls

Hi, everyone. I’m new here. This is my first post. 

I am currently working on getting FreeDOS running on my homebrew 286 
system. I am running into an issue where interrupt calls from FreeDOS to 
my BIOS are not showing updated values for the CPU flags register after 
the call. This happens with built-in interrupt calls in FreeDOS or 
custom calls I am making. Here’s a simple test function that I added to 
FreeDOS’s main.c (I call it just before signon()):


*void test_interrupt()*

*{*

*    iregs regs;*

*    regs.a.x = 0x1122;*

*    regs.b.x = 0x0033;*

**

*regs.c.x = 0x4455;*

*    regs.d.x = 0x6677;*

*    regs.di = 0x8899;*

*    regs.si = 0xaabb;*

**

*init_call_intr(0x15, );*

**

*printf("\nInt test: ");*

*    printf("ax=%04X  bx=%04X  cx=%04X  dx=%04X  di=%04X  si=%04X 
flags=%04X\n",regs.a.x,regs.b.x,regs.c.x,regs.d.x,regs.di,regs.si,regs.flags);*


*}*

In the assembly code for the BIOS interrupt service routine (I’m just 
using interrupt 0x15 for testing), I update the flags register. When I 
try to read the updated flags register back in FreeDOS, I am not getting 
the values that I expect. For example, if I use something like the 
following in my interrupt service routine, when I read regs.flags in 
test_interupt() above, the carry flag may or may not be set properly 
(same with the zero flag).


*  mov  ah, 0b0101  ;SF, ZF, AF, PF, and 
CF flags (bits 7, 6, 4, 2, haveand 0, respectively) – other flags are left 
unchanged by CPU*


*  sahf*

*iret*

In, kernel/pcb.h , 
I see some notes about “offsets must match the assembly process” and a 
couple of different layouts for the offsets. Could this be related to 
the issue I am having? I am using NASM 2.16.01 and Watcom 1.9.


Suggestions or things I could look into?

I have posted additional details here 
, 
including a video walk-through of what I am seeing.


Thank you!

Rich



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Extension proposal

[C. Masloch]

(Replying to multiple mails again.)

On at 2023-04-21 19:03 -0400, jer...@shidel.net wrote:

Hi Tom,


On Apr 21, 2023, at 2:01 PM, tom ehlert  wrote:

Hi ecm,



[1]: 
https://gitlab.com/DOSx86/logger/-/blob/aae3dfddcdacfea18950a96ce9449767c20b2d66/source/logger/common.inc#L267


this got me looking into this 'too slow' detection method.
and it is indeed slow. as in molasse. let me explain.


a) isn't

  %%Comparing:
inc di
lodsb
cmp al, [es:di]
jne %%Next
loop%%Comparing

more or less the definition of

repe cmpsw

??


Yes, more or less it was a  “repe cmpsb”

That was a while ago and I forget the reasoning I did it that way. Possibly, 
not requiring a case-specific match.


b) decompiling the actual code, it's basically


  for (seg = 10; seg < 0xa000; seg++)
{
if (fmemcmp(MK_FP(seg, 9), "LOGGER", DriverLength))
{
return found_our_driver_at(seg);
}
}
   return failure;

that's indeed slow as it compares all memory up to 0xa000 to lookup the driver,
or up to the drivers address (which is much better most of the time.


Yup it is a very slow way to locate the driver. It was only meant to be 
temporary until better method was implemented.

The better method will most likely be INT 0x2D (AMIS).

During the development stage, locating the driver needed to be done quickly so 
other things could be developed and tested.

That process went something like this:

1) We could walk the MCB chain…. That will require some overhead and 
complexity. Too big of a pain for now (see below).


Commented by me below.


2) We could walk the device driver chain. Thats fairly straight forward and 
easy enough to implement. Lets do that… Hmmm, not all device drivers are 
showing up in the chain and logger is not being seen. Let’s not worry about 
that for now and do something else.


Don't know how you managed to do that, it is indeed straightforward.


3) We could hook an interrupt somewhere. Yeah, that will be good and reliable. 
Lets do that. But, which one will not cause any conflicts or collisions. Hmmm, 
lets worry about it later and just get something that works for now.
4) Well a brute force search will work. It is slower than a glacier and as 
clever as a stone. But, it will work well enough that I can get to work on 
writing and testing the important stuff.
5) Brute force search it is then with a very few optimizations… For now, good 
enough.

Even though the delay incurred when launching the interface program is not very 
noticable, it is way to slow.

Now that the important stuff has been written and is being tested, the brute 
force search needs to go.


when I mentioned microseconds, I had the DOS memory chain in mind where you 
would have
to compare 20-50 locations to your drivers name.


I did consider walking the MCB chain to find it. But, that comes with its own 
set of problems. Some blocks contain sub-blocks.


SD "system data" blocks with sub-MCBs are a fact on most kernels, but 
they're not terribly complicated to detect and handle. First two name 
bytes are "SD" and the owner is 8. Sub-MCBs have signature letters 
indicating the type of the block rather than "M" link / "Z" no link, and 
they always span the entire space up to the end of the container SD block.



The upper memory blocks may or may not be linked into the primary MCB chain.


This is more of a problem. You can ignore a "Z" (ie, treat it as if it 
is an "M") if you know that the next block after the "Z" block is the 
first UMCB. You can find the first UMCB by trying to call interrupt 2Fh, 
function 1261h, CY; if it returns NC then ax = first UMCB. Or if the 
kernel does not support that function, switch off the UMB link, walk 
until "Z", switch on the UMB link, walk until you're past the MCB that 
was "Z" prior to this (but is now "M"). Of course, you want to preserve 
the original UMB link state around this. Example code is in my TSR 
example [1].


For a single search, it may be more efficient to just do the UMB link 
state enabling around your MCB walker as is, and honor any "Z" as the 
final end marker then.



[1]: https://hg.pushbx.org/ecm/tsr/file/749e0f25364c/transien.asm#l96



There are other aspects involving interaction between the Driver, Interface and 
Log that are also just “good enough for now” and will probably be changed a 
great deal.

It is an alpha version for a reason.

:-)



On at 2023-04-23 19:17 -0400, jer...@shidel.net wrote:
For “fun”, I implemented initial versions of both the 0x2b interrupt hook and a partial 0x2d implementation to locate the Logger device driver. 


The 0x2d version is very bare bones and does not include several functions 
required to be “fully compliant”. It only responds to the install check 
function for whichever multiplexer it allocates. Other function requests only 
respond with AL=0x00 which i guess is “not 

Re: [Freedos-devel] Extension proposal

[C. Masloch]

I'm responding to all of your mails (Jerome's) so far.

On at 2023-04-21 06:55 -0400, jer...@shidel.net wrote:

Hi All,

At present, the interface program for Logger just performs a slightly 
optimized brute force search for the Logger device driver. Although 
reliable, it is very slow compared to providing a simple interrupt call 
to test for installation.


I agree that scanning memory is not good enough. However, you could find 
the DOS device driver chain and scan it for your driver. It starts with 
the "NUL" device header in the DOS data segment (get approximate 
location with interrupt 21h function 52h) and ends when an offset of the 
"next device" pointer is 0h.


I also examined your implementation so far [1]. Here's some things I 
noticed:


1. You misspellt "it's location", should be "its".
2. You start the search at paragraph 0100h. It is a remote possibility 
for the initial low memory area part of DOS to take up less than 4096 
bytes however.

3. Your %%Comparing loop can use lodsb \ scasb or even cmpsb in fact.
4. If SEARCH_LOW is defined then when bx is equal to dx (your .COM 
application's ds) and dx was above 0A000h it will loop back to %%Next, 
incrementing bx again. I don't understand the logic behind this. If bx 
was below-or-equal 0A000h then you set it to 0A000h here. I'm fairly 
sure this is not very good, because your application can load lower than 
the device driver but the latter can still be below 0A000h.

5. push bx \ pop es is not very useful when mov es, bx is also 2 bytes.
6. A comment at %%Done says that upon reaching there with CY, es equals 
"undefined (0x)". This is only true for when the SEARCH_LOW option 
is in use. Otherwise it might end at 9FFFh, I think.
7. It is confusing to initialise di to 9 for the segment to check then 
have it immediately incremented to 10 (the offset of the device driver 
name in the device header) in the first iteration of %%Comparing. Could 
do with a comment, at least.


The CMPDD macro (just above what I linked in [1]) is neat to be sure. 
The conditional code mechanism [2] also looks good.



[1]: 
https://gitlab.com/DOSx86/logger/-/blob/aae3dfddcdacfea18950a96ce9449767c20b2d66/source/logger/common.inc#L267
[2]: 
https://gitlab.com/DOSx86/logger/-/blob/aae3dfddcdacfea18950a96ce9449767c20b2d66/source/logger/common.inc#L1102



Looking at the different interrupts, I think I 
have come up with a solution that will work well for Logger and any 
other driver or program that needs such a check. So, I’d like to propose 
a “standard” we could use. I’d like to get your feedback on what I’m 
thinking…


As the others have mentioned, there is a "standard" already. AMIS 
provides everything you propose, and more. And if you think you don't 
want to support all of the bits, even those required for specification 
compliance, you can always pick and choose what to include.


Looking at RBIL, interrupt 0x2b is barely used by anything. Under MS-DOS 
and FreeDOS, this simply points to an IRET. Under IBM ROM-DOS, AH 
functions 0x00-0x03 do some things. But, all other calls do nothing.


https://fd.lod.bz/rbil/interrup/dos_kernel/2b.html 



This is precisely the rationale of why AMIS (eventually) ended up on 
interrupt 2Dh. It is not generally in use, and points to an iret on 
MS-DOS v3 compatibles by default. I'm about to add a check for its 
validity to my TSR applications, which checks that the segment is 
nonzero and the offset is not equal to 0h [3]. (This check is only 
for the example for now, but I will pick it into all my TSRs eventually.)



[3]: https://hg.pushbx.org/ecm/tsr/rev/aafe8caaf4f5


An install check issuing this interrupt would be simple to perform. A 
program could set the Carry Flag,


Carry Flag is a nonstarter for a multiplex interrupt check, because you 
either need to return with retf 2 (likely scrambling the Direction Flag 
and Trace Flag and Interrupt Flag), or do a complicated dance to pass 
the CF or most arithmetic status flags to the fl word on the interrupt 
stack frame, eg using lahf [4] [5] (arithmetic flags except Overflow 
Flag) or a little rcr \ rol trick [6] (modifies Carry Flag only).



[4]: https://github.com/640-KB/GLaBIOS/issues/20
[5]: https://github.com/MobyGamer/softhddi/issues/1
[6]: https://hg.pushbx.org/ecm/seekext/file/bbfcfa0d1c0b/resident.asm#l254


load AH/AX with “check for install” 
function and set DS:BX to point to an identifier string (minimum 8 
characters, no maximum). Then call the interrupt.


AMIS already provides a standard way to do this. Instead of providing a 
pointer to the resident handlers, however, it returns a pointer to the 
resident's signatures. Those take up at least 17 bytes, 8 bytes intended 
for "manufacturer", the next 8 bytes for "product", and then up to 64 
bytes for a longer descriptive name (NUL-terminated). This longer string 
is optional in that it can just hold the empty string, and in that case 
you 

Re: [Freedos-devel] Slowdown-Units ratings and a CPU-bound depacker be nchmark

[C. Masloch]

On at 2023-04-05 03:32 +, Bret Johnson wrote:

The article is found at
https://pushbx.org/ecm/dokuwiki
/doku.php?id=blog:pushbx:2023:0321_cpu_performance_comparison


I mostly agree with you and your article, but:


fine that you agree,  but at most 50% of the article is even close to
'right'.


You're the one who said, "I mostly agree with you and your article, but:", not 
me.


Conclusion

CPU-bound benchmarks are much faster on a modern machine than they
are on older ones.
The frequency increase does not actually suffice to explain the
speedup.
Some things, like doing I/O, were not sped up nearly as much
however.



I tried posting a much longer response to this, but it was
apparently rejected by the moderators.  Here's a shorter one.


As I already mentioned in the other reply to this thread, feel free to 
send me more specific replies to that article.



I/O has also vastly speedup (we have SSD speeds of up to 6 GB/sec).
Just not by doing IN/OUT, but by using memory mapped PCI devices.



I think you're confusing two different things -- MMIO and DMA/Bus-
Mastering.



He is NOT.


I wasn't talking about ecm being confused, I was talking about you.  AFAIK, ecm 
never tested either MMIO or bus-mastering so never said anything about them.


Yes, the only tests I did involved running Slowdown with and without the 
one port I/O instruction patched out in the waste loop. However, Tom is 
correct that this specific *port* I/O access to that particular port is 
not representative of all possible ways of doing I/O.


Regards,
ecm


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Slowdown-Units ratings and a CPU-bound depacker be nchmark

[C. Masloch]

On at 2023-04-04 21:09 +0200, tom ehlert wrote:

Dear Bret,


The article is found at

https://pushbx.org/ecm/dokuwiki/doku.php?id=blog:pushbx:2023:0321_cpu_performance_comparison



I mostly agree with you and your article, but:


fine that you agree,  but at most 50% of the article is even close to
'right'.




Conclusion

CPU-bound benchmarks are much faster on a modern machine than they
are on older ones.
The frequency increase does not actually suffice to explain the
speedup.
Some things, like doing I/O, were not sped up nearly as much
however.



I tried posting a much longer response to this, but it was
apparently rejected by the moderators.  Here's a shorter one.


I don't think that the mailing lists are moderated that way? Anyway, 
Bret, you can send any additional comments to me per email or as a 
comment on the blog.



I/O has also vastly speedup (we have SSD speeds of up to 6 GB/sec).
Just not by doing IN/OUT, but by using memory mapped PCI devices.



I think you're confusing two different things -- MMIO and DMA/Bus-Mastering.


He is NOT.


Who's "he"? In case this was meant to refer to me, it is wrong because 
I'm not a "he".



Whether I/O is PMIO or MMIO is pretty much irrelevant to the speed.
For example, I/O port 201h (the analog joystick) and I/O port 92h
(which controls A20 on some computers) are both VERY slow and would
not be any faster if they were MMIO instead of PMIO.


this is plain bullshit.


The speed depends on the I/O device, not the type of I/O mapping.

which is nonsense.


  Plus, I/O
_can't_ be cached, whether PMIO or MMIO, so the cache(s) are irrelevant to I/O.


yes. I/O device data can't be cached. you are such a clever person to
discover this fact. WOW.



SSD speeds are fast because they use bus-mastering, not because
they use MMIO.  The I/O ports are used to "control" the device, but
the data from the SSD is transferred in and out of RAM using
bus-mastering (which is fast because it doesn't use the CPU at all).


I understand that you don't have the faintest clue how modern PCI devices
work. Just go ahead with undertaining us ...


Tom


Regards,
ecm




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Slowdown-Units ratings and a CPU-bound depacker benchmark

[C. Masloch]

Hello!

Inspired by recent discussions on the list I prepared an article about 
Bret's SLOWDOWN, its Slowdown-Units rating, and a comparison of two 
different depackers on three different machines. I believe that the 
depackers are a better test case for how fast a CPU actually is, because 
they do not perform any I/O. I found that patching out the "in al, dx" 
instruction in SLOWDOWN's Waste function greatly increased the 
Slowdown-Units detected for a 686 machine and an AMD A10 machine, 
whereas on the NEC V20 this patch did not affect the SU 17 rating. I 
used my debugger both as the test data to unpack repeatedly, as well as 
to script the patches to a SLOWDOWN loaded in a process.


Arguably the in instruction should stay in SLOWDOWN as is, because 
actual use cases may involve at least a small number of I/O accesses, 
but Bret also made some claims about the speed of CPUs, which is a 
narrower field that I think should not include I/O. As my article 
depicts, more recent CPUs are more than 1000 times as fast as old ones. 
(Obviously, memory plays a part in that, but I think allowing memory 
effects still does not mean I/O too should always be considered.)


I did find one bug in SLOWDOWN, which is a division overflow, as well as 
another questionable part where it attempts to run a wbinvd instruction 
when that may not be allowed by the VM. (At least, in dosemu2 KVM it 
failed for me.)


The article is found at 
https://pushbx.org/ecm/dokuwiki/doku.php?id=blog:pushbx:2023:0321_cpu_performance_comparison


Regards,
ecm


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] IFS API

[C. Masloch]

On at 2023-02-22 01:05 +, Yll Buzoku wrote:

Hi Aitor,

Preface:

The following holds true for PC-DOS 3.3, though I have no reason to 
suspect anything I say holds any different for any DOS version from 3.1 
onwards.


The LoL, SDA, CDS, and SFT layouts differ somewhat between MS-DOS 
versions 3.x, 4.x, and 5.x I believe. And a few calls (like the 2F.11 
service to implement 21.6C Extended Open/Create) are version-specific.


My understanding of what is expected of the redirector 
interface is due to having disassembled the DOS 3.3 kernel to understand 
how it works and may not be 100% accurate. Also, DOS 3.0 has some unique 
quirks but as far as the following is concerned, I suspect it works more 
or less the same as later DOS versions. DOS versions before that had no 
redirector interface.


DOS has two 128-byte buffers in the Swappable Data Area. Initially, on a 
file-based request, such as AH=3Dh (OPEN), DOS will parse the passed 
filename into one of these buffers and place a pointer to it in another 
SDA variable. This parsing routine expects 8.3 names at all stages in 
the pathname except at the very beginning where if the pathname begins 
with \\ DOS understands this as referencing a path on a network machine 
and allows a valid MS-NET machine name as the first component of the path.


FCB functions work like this too, but the way DOS handles them is a bit 
more convoluted, though you can imagine FCB handling by DOS as 
converting the FCB request to a normal file request, then proceeding as 
normal and at the end synchronising the FCB fields before returning 
control back to the application. Of course, you can only act upon files 
on drives with drive letters when using FCBs.


If the parsing routine ascertains that the request is to be run on a 
network drive, either due to a \\ pathname specification or due to a 
drive letter being specified that refers to a registered, mounted 
network drive (see CDS Flags to see how this is determined), DOS will, 
at the point of the file operation, redirect the call to the relevant 
Int 2Fh AH=11xxh Network Redirector function (RBIL has these more or 
less completely listed) for the DOS call made. For example, for OPEN 
(AH=3Dh), DOS will call Int 2Fh AX=1116h. Note that most calls don't 
work with a machine name (as most calls require a CDS and those only 
exist for drives). For example, OPEN will fail if you pass a filename 
beginning with a "\\".  On the other hand, CREATE (AH=3Ch) works for 
both cases.


Once control is transferred to the network redirector, it is then 
expected to extract the pointer to the parsed filename from the SDA and 
use it to do... whatever. Of course, it doesn't _have_ to that as the 
PSP of the task which made the request is directly accessible to the 
redirector via the SDA (or via Int 21h AH=62h, a re-entrant DOS 
function). Crucially, the PSP has a copy of the value of SS:SP of the 
program which made the request, and it is set by DOS to point to a copy 
of the callers' registers as they were on entering DOS.


I believe there exists an SDA field (or two) pointing to the user stack 
frame created by the DOS call. But yes, this is also accessible in the 
PSP, though usually the only reader of *that* pointer is DOS process 
termination (to regain the parent process's stack).


That includes 
the pointer to the original "unparsed" LFN filename in DS:DX. Therefore, 
a redirector could access the LFN passed by an application by taking the 
pointer to the path in the method described above, thus allowing the 
redirector to implement LFN's however it so chooses. This is a 
hypothetical way for a network redirector to support LFN's without a 
frontend hook for Int 21h.


That is imaginable, but comes with problems like DOS applications not 
allowing to enter pathnames that contain blanks. An application that 
uses the LFN interface (21.71) will usually allow for some escape method 
such as double quotes to enter long names that may include blanks.


File sizes however would still be limited though as the SFT would still 
be used for file management and the file size field therein is a DWORD.


A redirector can readily store additional file handle data outside the 
SFT, using some cookie in the SFT to remember a reference to its 
additional file data. Such a data structure is probably needed for any 
nontrivial redirector because the available SFT fields may not suffice 
to hold all file handle Meta data.


I added 64-bit file size support to dosemu2's MachFS, by storing the 
size and seek position in uint64_t fields in the redirector's private 
file structure and syncing this with the 32-bit SFT fields throughout 
the redirector's code.


In particular, if DOS modifies the seek (which it can do without the 
redirector's awareness, refer to the comment in [1]) then it will 
usually end up at a number that isn't all-ones (0_h) and the 
redirector will heed this value before using a seek position anywhere. 
This is done 

Re: [Freedos-devel] IFS API

[C. Masloch]

On at 2023-02-21 22:39 +0100, Aitor Santamaría wrote:

Thanks!!

Just a 5-min check so I may be wrong, but it seems to hook int13h and 
issue some Iomega ZIP HPFS driver SCSI calls to do the work.

Which is just another way to accede other filesystems. :)


iHPFS proper (not iHPFSOM which I do not know much) does not hook 
interrupt 13h, its source code (IHPFS.ASM) only hooks interrupts 2Dh (to 
provide its AMIS multiplexer) and interrupt 2Fh (for the file system 
redirector interface on service 11h). It *uses* interrupt 13h to access 
its file systems, not using a device-driver model like DOS's default 
block device(s) for DOS-native FAT FS drives.


Regards,
ecm


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] IFS API

[C. Masloch]

On at 2023-02-20 22:03 +0100, Eric Auer wrote:


Hi! As we have various drivers which use the network redirector API,
CD/DVD redirector API or both,


There is no distinction between those, that's the same file system 
redirector interface. It can be used for optical storage, for networked 
file systems, or for local hard disk partitions with file systems not 
natively supported by the DOS (eg the free software iHPFS redirector for 
HPFS drives).



Also note that the low-level format is not visible through IFS, so it
does not matter whether you use FAT32, FAT16 or NTFS. However, it may
matter whether you want long file names or files > 2 GB. For those,
I hope that the usual Win9x DOS 7.x int 21 calls have counterparts in
the network and CD redirector API space of the same DOS generations.


They do not. Redirectors that want to support Long File Names (eg 
dosemu2 MachFS) need to intercept interrupt 21h service 71h subfunctions 
manually and handle the LFN functions themselves. (Possibly in part by 
calling down to SFN functions of the DOS.)


The 64-bit file seek service originated by Enhanced DR-DOS, on interrupt 
21h service 7142h, is also not supported on redirected drives by 
default. (This service and the underlying support is required for random 
access to file data beyond the first 4 GiB - 1 Byte.)


EDR-DOS itself crashes a little when you try to call this service on a 
redirected drive's file handle (it does return an error, but that is 
rather random and not intended). The dosemu2-related fdpp project and 
dosemu2 added a redirector interface extension to use for this, first on 
interrupt 2Fh service 1142h, later moved to service 11C2h. This is 
implemented in dosemu2's mfs.c [1].


When using redirectors such as dosemu2 MachFS with DOS kernels other 
than fdpp, *someone* still has to hook interrupt 21h to make this call 
available to DOS users the way they expect. I wrote a tool called 
SEEKEXT [2] which provides the service 7142h hook on redirected drives 
and will attempt to call the dosemu2 extensions if they're available, or 
give up with an error otherwise. On local drives it just chains to the DOS.


(SEEKEXT also hooks the traditional 32-bit seek interface on service 42h 
and tries to translate the inputs and outputs to use the 64-bit seek 
function, which is also required for proper operation in case the DOS 
does not support this natively.)


For an example of the 64-bit seek DOS call, I can point to my instsect 
program which supports operation on image files. To support image files 
larger than 4 GiB (including partitions on a partitioned image file that 
may start beyond 4 GiB into the file) it tries to call the service 7142h 
first [3]. I specifically contributed the dosemu2/fdpp interface to 
enable this use case, with the DOS service 7142h intentionally done in a 
way compatible to EDR-DOS.


Other than that, dosemu2 also provides a function provided as interrupt 
2Fh service 11A6h, implemented in mfs.c as well [4]. I believe this is 
used to back function 71A6h though I am not sure who hooks interrupt 21h 
in that case, probably fdpp too.


Regards,
ecm


[1]: 
https://github.com/dosemu2/dosemu2/blob/019dcff5711b5763fe5231cbeb933715cc65a2e4/src/dosext/mfs/mfs.c#L5022

[2]: https://hg.pushbx.org/ecm/seekext/file/bbfcfa0d1c0b/resident.asm#l17
[3]: https://hg.pushbx.org/ecm/instsect/file/18edcefc9877/instsect.asm#l4363
[4]: 
https://github.com/dosemu2/dosemu2/blob/019dcff5711b5763fe5231cbeb933715cc65a2e4/src/dosext/mfs/mfs.c#L5076



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] MS-DOS compatibility issue

[C. Masloch]

Hello tom ehlert,

On at 2022-08-01 15:11 +0200, tom ehlert wrote:
> Hallo Herr C. Masloch,
> am Sonntag, 31. Juli 2022 um 22:25 schrieben Sie:

I would appreciate if you did not refer to me wrongly.

>> On at 2022-07-31 15:49 +0800, TK Chia wrote:
>>> Hello Jerome,
>>>
>>>>> Generally, I would not include an attachment. However, this is a
>>>>> tiny zip and includes the test source, build scripts and the compiled
>>>>> version.
>>>
>>> Well... I found that your ansitest.com still works with the FreeDOS 1.3
>>> kernel + nansi.sys 4.0d.  (I.e. there was no regression between FreeDOS
>>> 1.0 and 1.3.)
>>>
>>> I took a FreeDOS 1.3 "floppy edition" boot disk image, and doctored it
>>> so that it loads nansi.sys on startup and does not start the installer,
>>> then ran it under QEMU.  ansitest.com says "ANSI supported".
>>>
>>> (I will try to enclose a floppy disk image once I manage to pare it 
down

>>> to a small enough size...)
>>>
>>> Are you using devload.com to load the nansi.sys driver?  If so, this
>>> might explain the failure.  I found that if I use devload.com --- 
rather

>>> than load the driver through fdconfig.sys --- then for some reason
>>> nansi.sys's input handling routines are not triggered, and there is no
>>> ESC [ y ; x R response.  This would mean there is an issue in 
devload.com.

>
>> I haven't finished my study of DEVLOAD yet, so I cannot tell for sure.
>
>> (I started looking into it to support loading lDebug in device-driver
>> mode using DEVLOAD, which requires an allocation to the device that's
>> larger than 64 KiB. I uploaded my experimental patch [1] and also set up
>> a repo [2] for DEVLOAD on our hgweb server, but did not yet get around
>> to figuring out the specifics for some proper patches. Those will show
>> up in the repo if I get to them.)
>
>> However, I believe that DEVLOAD will not re-open the file handles held
>> by existing programs that point to the previous CON device. If NANSI
>> requires usage of its CON device to make the check work (eg to insert
>> its response string as input from the CON device), then this will not
>> work if you use DEVLOAD to load NANSI. DOS's config processing will
>> re-open all of the current (init) process's standard handles after
>> having finished loading device drivers.
>
>> When DOS creates a child process from an existing process then it will
>> duplicate the process file handles (except ones opened with the "no
>> inherit" flag), so that the new process will have a set of process
>> handles referring to the same system file handles as the parent at the
>> time of the child creation. That means if DEVLOAD doesn't close and
>> re-open (or otherwise redirect) currently open file handles to CON in
>> the shell, then that shell and all its child processes will continue to
>> refer to the prior CON device after NANSI has been loaded.
>
> your analysis seems to be correct.
>
> at least after
>
> test.bat
> devload ansitest.com
> CTTY NUL
> CTTY CON
>
> ansitest reports
> ANSI detected
>
> of course DEVLOAD could borrow the code from CTTY.
>
> but: how can DEVLOAD detect that STDIN is indeed CON, and not COM1

It would have to peek into the SFT entries for system file handles 
pointing to character devices, matching the name "CON".



On at 2022-08-01 16:05 +0200, tom ehlert wrote:



at least after



test.bat
devload ansitest.com
CTTY NUL
CTTY CON



ansitest reports
ANSI detected



of course DEVLOAD could borrow the code from CTTY.



but: how can DEVLOAD detect that STDIN is indeed CON, and not COM1


in addition: after exiting from DEVLOAD, the next program started will
get the STDIN/STDOUT/STDERR handles as duplicates from COMMAND.COM

so it seems DEVLOAD would have to change the handle of command.com,
not it's own copy. is that true?


Yes, it is true. That's what I was referring to by "then that shell and 
all its child processes will continue to refer to the prior CON device". 
DEVLOAD should look up the process handles at least of its immediate 
parent process (if not other processes too), map them to system file 
handles, check for a handle opened to a character device and a name 
match to what was loaded, then probably just patch that SFT to refer to 
the new device.


If we do patch the SFT as opposed to re-opening the new character device 
then we wouldn't have to go the process handle route at all, we can just 
intercept all currently opened character device system file handles with 
a matching name.



while it's obvio

Re: [Freedos-devel] MS-DOS compatibility issue

[C. Masloch]

On at 2022-07-31 22:44 +0200, Eric Auer wrote:


Hi!

(I started looking into it to support loading lDebug in device-driver 
mode using DEVLOAD, which requires an allocation to the device that's 
larger than 64 KiB. I uploaded my experimental patch [1] ...


However, I believe that DEVLOAD will not re-open the file handles held 
by existing programs that point to the previous CON device. If NANSI 
requires usage of its CON device to make the check work ... will not 
work if you use DEVLOAD to load NANSI. DOS's config processing will 
re-open all of the current (init) process's standard handles after 
having finished loading device drivers.


Very interesting reasoning :-)


I verified in the NANSI sources that it stuffs its responses into the 
reads/readaheads done to the CON device (not into the interrupt 16h 
buffer). So that part of my story holds up.


if DEVLOAD doesn't close and re-open (or otherwise redirect) currently 
open file handles to CON in the shell, then that shell and all its 
child processes will continue to refer to the prior CON device after 
NANSI has been loaded.


Good catch. Your patch does not seem to address that yet, though?


Yes, as I intended to communicate with the separate parenthetical 
paragraph, and the fact that the patch is in a directory named after the 
early-May date 2022-05-09, this patch only addresses loading lDebug 
where the unpatched DEVLOAD fails.



Instead, it introduces multiple int3 calls (bad idea for any app
on disk, breakpoints should only be inserted dynamically in RAM)


As I wrote, it is an experimental patch. Parts of the experiment 
required breaking in specific places to verify things were working as 
expected. So therefore I left in those breakpoints, because it is not 
meant to be a "production" quality contribution yet.



and circumvents the deliberate 64k driver size limit. Although I
do not remember WHY the limit was there. Maybe compatibility?


Yes, as you commented in the source [1], "clipping the value to 64k for 
now, feels more compatible". However, this particular limit makes it so 
lDebug can never load, because it is a nice application which checks the 
limit passed by the loader instead of ignorantly allocating whatever 
amount of memory it desires. So it may be "more compatible" for some 
applications, but it makes this INcompatible with others. Albeit there 
is an idea, if I finish the proper patch we could add a switch to 
DEVLOAD to fall back to the "maximum below 64 KiB" allocation, just in 
case this is actually ever needed.


You may also notice the first and last hunks of the experimental patch. 
I found that DEVLOAD didn't properly initialise and process its 
allocation size variables. The first hunk is for initialising the word 
[EndSeg] variable, which without this was never written before calling 
the device driver's initialisation. The last hunk I'm not quite sure 
about but I believe I found that it didn't do what it was supposed to 
without the patch.


As I wrote, it is all experimental and I would have to test and confirm 
the logic to finish it properly, either with the same exact changes or 
perhaps better ones.


Regards,
ecm


[1]: https://hg.pushbx.org/ecm/devload/file/b10d4fe6d877/devload.asm#l1170


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] MS-DOS compatibility issue

[C. Masloch]

On at 2022-07-31 15:49 +0800, TK Chia wrote:

Hello Jerome,


Generally, I would not include an attachment. However, this is a
tiny zip and includes the test source, build scripts and the compiled 
version.


Well... I found that your ansitest.com still works with the FreeDOS 1.3
kernel + nansi.sys 4.0d.  (I.e. there was no regression between FreeDOS
1.0 and 1.3.)

I took a FreeDOS 1.3 "floppy edition" boot disk image, and doctored it
so that it loads nansi.sys on startup and does not start the installer,
then ran it under QEMU.  ansitest.com says "ANSI supported".

(I will try to enclose a floppy disk image once I manage to pare it down
to a small enough size...)

Are you using devload.com to load the nansi.sys driver?  If so, this
might explain the failure.  I found that if I use devload.com --- rather
than load the driver through fdconfig.sys --- then for some reason
nansi.sys's input handling routines are not triggered, and there is no
ESC [ y ; x R response.  This would mean there is an issue in devload.com.


I haven't finished my study of DEVLOAD yet, so I cannot tell for sure.

(I started looking into it to support loading lDebug in device-driver 
mode using DEVLOAD, which requires an allocation to the device that's 
larger than 64 KiB. I uploaded my experimental patch [1] and also set up 
a repo [2] for DEVLOAD on our hgweb server, but did not yet get around 
to figuring out the specifics for some proper patches. Those will show 
up in the repo if I get to them.)


However, I believe that DEVLOAD will not re-open the file handles held 
by existing programs that point to the previous CON device. If NANSI 
requires usage of its CON device to make the check work (eg to insert 
its response string as input from the CON device), then this will not 
work if you use DEVLOAD to load NANSI. DOS's config processing will 
re-open all of the current (init) process's standard handles after 
having finished loading device drivers.


When DOS creates a child process from an existing process then it will 
duplicate the process file handles (except ones opened with the "no 
inherit" flag), so that the new process will have a set of process 
handles referring to the same system file handles as the parent at the 
time of the child creation. That means if DEVLOAD doesn't close and 
re-open (or otherwise redirect) currently open file handles to CON in 
the shell, then that shell and all its child processes will continue to 
refer to the prior CON device after NANSI has been loaded.



Hello Tom,


have YOU thought about using your favorite DEBUG tool to chase down
this issue?


Diagnosing this problem with debug.com turns out to be trickier than
expected, since it involves tracing the innards of int 0x21 that
debug.com also uses for its I/O...

Thank you!


To get to the actual point of me writing this mail, there are some 
debuggers that do allow tracing interrupt 21h.


FreeDOS Debug has some support for this, which it detects by checking 
the InDOS flag. My lDebug expands this support: If you issue the command 
"r dco or= 8" then all debugger I/O afterwards is forced not to use DOS 
and the debugger will not use DOS otherwise either. (Except for the Q 
commands.) This might be more helpful for debugging DOS or other 
interrupt 21h handlers. I/O is done using the ROM-BIOS interrupt 16h and 
interrupt 10h services instead, for as long as lDebug is in its "InDOS" 
condition (either the actual InDOS flag is set and/or DCO option 8 set).


lDebug also allows to do its own I/O across a serial port [3], which 
drastically cuts down on the DOS calls made by the debugger as well. 
However, if you specifically want to debug interrupt 21h handlers you 
likely want to set the option 8 anyway, even if you use serial I/O. So 
that'd be "r dco or= 4008".


The Insight debugger that I have been working on some might also allow 
debugging DOS, because all its I/O is done using either the ROM-BIOS 
(interrupt 16h in particular) or direct screen writes to the text-mode 
video memory. However, I cannot promise this with certainty.


Another option that I didn't check yet is to use Microsoft's now free 
software version of Debug that ships in the MS-DOS version 2 release. 
That has a build option called SYSVER [4] which is intended to make the 
debugger use the CON device directly for its I/O, instead of calling 
into DOS. That is not as general as using the ROM-BIOS, but might 
suffice. However, I have not yet built Microsoft's Debug with this 
option enabled.


Yet another option is to use a debugger built into a virtual machine, 
such as dosemu2's dosdebug. I believe DOSBox and DOSBox-X also offer 
debuggers. I have heard good things about Bochs's debugger too. From my 
experiences with dosemu2 dosdebug I cannot recommend it very highly 
though, lDebug has a better interface. But it is able to debug at a very 
low-level that lDebug cannot reach.


Regards,
ecm


[1]: https://pushbx.org/ecm/test/20220509/devload.diff
[2]: 

Re: [Freedos-devel] Another implementation of GRAFTABL

[C. Masloch]

On at 2022-07-12 21:59 +0200, C. Masloch wrote:

On at 2022-07-12 15:45 -0400, Steve Nickolas wrote:



The new "new2F":

new2F:    cmp   ah, 0xB0    ; is it ours?
   je    .2
.1:   jmp   0:0
.2:   cmp   al, 1
   ja    .1  ; >1 - chain
   mov   al, 0xFF    ; needs set for both functions.
   je    .3  ; 1 - where are we?
   iret  ; 0 - are we here?
.3:   mov   word ds:[bx], entry
   mov   ds:[bx+2], cs
   iret
old2F equ   .1+1

...probably as codegolfed as it's going to get.


Found another byte to save:

Replace "je .3" then "iret" by "jne .3" then put the ".3" label before 
the "iret". You only need the one iret at the very end, and the jump 
after "mov al, 0FFh" should branch to it.


Regards,
ecm


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Another implementation of GRAFTABL

[C. Masloch]

On at 2022-07-12 15:45 -0400, Steve Nickolas wrote:
I haven't uploaded a copy of the new source anywhere yet - it'll 
probably be in the next DOSLITE source batch along with my work on a few 
other DOS commands, but I don't want to replace the copy I've already 
uploaded, and DOSLITE isn't ready to go onto anything like github or 
gitlab yet.


I strongly suggest to keep source history. If you'd rather not, you do 
not need to publish that right now but I do recommend you keep it 
privately at least. I started in 2010 [1] and it has been a great 
experience that often proved useful.


As I said, I managed to move the CP437 table into the spot reserved for 
the resident table (except for the first 3 bytes), which saved good 
memory, and with C. Masloch's optimizations and by simplifying the 
version check the file size and resident footprint went down even 
further.  (In an earlier incarnation, I had to jigger around 'jmp far 
0', but it turns out 'jmp 0:0' as mentioned was the solution to that.)


Yes, good catch, it isn't immediately obvious why NASM won't allow a 
"far" keyword there.


The resident footprint went down 1 paragraph, from 1344 to 1328 - now 
only 128 bytes larger than the official version.  (I wonder if any of 
the PSP can be just up and deallocated?)


You can deallocate the PSP (either with some tricks on the parent stack 
or just split Memory Control Blocks manually), but it will leave a 
memory "hole" in its place. This is seldom useful. (Bret's and my method 
relocate the PSP precisely to avoid creating fragmentation holes when 
allocating the final resident memory.)



The new "new2F":

new2F:    cmp   ah, 0xB0    ; is it ours?
   je    .2
.1:   jmp   0:0
.2:   cmp   al, 1
   ja    .1  ; >1 - chain
   mov   al, 0xFF    ; needs set for both functions.
   je    .3  ; 1 - where are we?
   iret  ; 0 - are we here?
.3:   mov   word ds:[bx], entry
   mov   ds:[bx+2], cs
   iret
old2F equ   .1+1

...probably as codegolfed as it's going to get.


Not quite: The "ds:" segment override prefixes are unneeded actually. 
NASM will happily emit them, but they eat memory completely 
unnecessarily. "mov word [bx], entry" already defaults to ds as its 
segment. (Unlike addresses including "[bp]" which default to ss.)


I didn't notice those at first because I assumed you were using es. 
That's what your comment in your caller says:


.21:  mov   ax, 0xB001  ; So where is it?
  mov   bx, whence  ; ES:BX gets this.
  int   0x2F


However, the Interrupt List [2] does say it uses ds:bx so your interrupt 
handler is correct, your caller's comment is incorrect.


Regards,
ecm


[1]: https://hg.pushbx.org/ecm/ldebug/rev/5eef5847c863
[2]: https://fd.lod.bz/rbil/interrup/video/2fb001.html#5274



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Another implementation of GRAFTABL

[C. Masloch]

On at 2022-07-12 15:15 -0400, Steve Nickolas wrote:

You do not use an IBM Interrupt Sharing Protocol (IISP) [11] header 
for your interrupt hook. Therefore, you could optimise this part a 
bit, from:


old2F:    dd    0x
...
.1:   jmp far   [cs:old2F]


Into this:

.1: jmp 0:0
old2F equ $ - 4


This is some self-modifying code (SMC) to stash the downlink into an 
immediate far jump instruction, instead of using the indirect far jump 
to refer to a different memory location in your code segment. The 
dollar sign is used in the equate to denote the current assembly 
position after the 5-byte instruction; it is offset by minus four so 
as to address the far pointer in the instruction's encoding. (As 
mentioned, you cannot do this if you use a standard IISP header, 
because that has a "jmp short $+18" (EBh 10h) instruction right in 
front of the downlink field.)


I believe it was from analyzing some MS-DOS 2.0 code that I got the 
technique I used here.


Your technique is the default way to do this, most TSRs ever written did 
it that way. The SMC is just a small optimisation over it. If you do use 
the IISP then the "jmp far [cs:.next]" way is the correct way. (You can 
also do "pushf" then "call far [cs:.next]" if you want to call instead 
of chain. Or chain by way of "retf", though that doesn't really have any 
advantages.)


Next, you're using "or al, al" to check a register for zero. However, 
it is more idiomatic [12] to use "test al, al" instead, which right 
away hints (to a reader or even to the processor) that no change of 
the register occurs.


Also not sure where I got the "or" idiom, but I know that it doesn't 
alter the register data.


It doesn't modify it indeed, same as "and reg, reg". I just think test 
is the preferable choice, not that it matters much.



(Regarding a here-deleted convo regarding EMS and XMS memory)

I've been thinking about how to implement other DOS commands - I'm 
basically trying to create a compact reimplementation of the MS-DOS 6.21 
userland, more or less, and I know I'm in way over my head - and trying 
to figure out XMS and EMS has been something I've been wracking my brain 
over for an idea to implement XCOPY, by creating a series of "packets" 
with commands like "create directory", "open file", "write to file", 
etc., and store as many of these "packets" in RAM, including XMS and 
EMS, as possible before dumping the data out to disk.


Certainly possible.

Also, I've been hacking on MS-DOS 2 DEBUG trying to figure out how to 
plug in MS-DOS 4 functions (EMS support and read/write on BIGFAT 
devices) without success, but that's another matter ;p


If you really want to continue to use the free software release of 
Microsoft's Debug, you may want to look into the following:


* Some notes on building the original sources, probably not needed if 
you already figured out how to manage that. [1]


* A fix to the CALL 5 bug (that was preserved all the way into the 
latest Microsoft Debug versions) [2]


* Some discussion on additional bugs in this Debug (might be fixed by 
later MS-DOS Debug) at [3], in particular the fact that it doesn't set 
itself up as self-parented and also fails to create a proper child PSP 
for the client when just assembling into the code segment. The child PSP 
problem is not relevant when loading a program into the debugger.


* For historical reference, there are some versions of the original 
86-DOS Monitor and Debug out there, some of which explicitly note that 
copyright does not apply to them.


Other than that, do have a look at FreeDOS Debug [4] or my repo of its 
history going back decades [5], as well as my fork, lDebug [6]. Another 
fork with fewer changes is debug.gen [7]. There is also Enhanced Debug 
in the same family but that one is not free software, it's not 
redistributable.


Regards,
ecm


[1]: 
http://www.bttr-software.de/forum/forum_entry.php?id=15572=0=last_answer=DESC=all

[2]: http://www.seasip.info/DOS/
[3]: 
https://stackoverflow.com/questions/72024176/how-can-i-fix-my-dosbox-it-freezes-and-auto-closed-whenever-i-use-dos-debugs-g?noredirect=1#comment127385645_72024176

[4]: https://github.com/Baron-von-Riedesel/DOS-debug/
[5]: https://hg.pushbx.org/ecm/fddebug
[6]: https://pushbx.org/ecm/web/#projects-ldebug
[7]: https://github.com/lpproj/debug.gen


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Another implementation of GRAFTABL

[C. Masloch]

On at 2022-07-12 20:01 +0200, Jose Senna wrote:

  Bret Johnson said:
  > The way it works is to make a "copy" of
  > itself at the top of conventional memory,
  > terminates itself (using a normal DOS
  > terminate process, which includes deleting
  > the original PSP), and then continues
  > running from the "copy". The "copy" decides
  > where the best place in memory is to load
  > the TSR (which can even be in one or more
  > "memory holes" left by some other program
  > or in upper memory),allocates appropriate
  > memory block(s), and then installs itself
  > in the allocated memory.


   But when it terminates, the system would
  not return to the parent of the utility,
  (COMMAND or whatever called the utility) ?
  So, how can the copy continue running
  after termination  ?


Good question! As I independently invented this method, I will answer 
quickly. You can read my reference implementation in my TSR example [1]. 
Basically, it creates a new PSP (the system structure that makes up a 
DOS process) in a temporary memory block, then bends that memory block 
to "belong to itself" (as memory blocks used for PSPs usually do). This 
means that when we terminate with service 4Ch, the temporary allocation 
is not freed because it doesn't belong to the original process.


The actual "jump" over to the new temporary process is achieved by 
twisting the parent process field and the Parent Return Address (aka 
interrupt 22h) of the original process. Their original contents (which 
refer to the shell or whatever other process EXECed our program) are 
transferred into the new temporary PSP, so that upon its termination it 
will actually return to the shell. The old original PSP is instead 
modified to refer to the new PSP as its parent, and the original PSP's 
PRA is also modified to jump into the code of the relocated process. 
(Additionally, there is a field in the *parent* PSP which indicates what 
stack to use when returning from DOS process termination to the parent.)


In part this was inspired by FreeDOS Debug (and before this actual 
shells for DOS, too, I believe even MS-DOS COMMAND.COM does this). It 
sets up its parent as itself, and its PRA to return into its own 
resident code. DOS detects the special condition of a self-parented 
process in its termination handling, and will not free memory nor close 
the file handles in this case. (Just as for service 31h TSR termination 
actually, it also neither frees memory nor closes handles, as I 
mentioned in my longer reply earlier.) That allows the shell (and the 
debugger, which touts itself a kind of shell [2]) to retain control 
after it was aborted with Control-C or upon a critical error when 
"Abort" was selected.


Regards,
ecm


[1]: https://hg.pushbx.org/ecm/tsr/file/daca203fa216/transien.asm#l988
[2]: 
https://hg.pushbx.org/ecm/ldebug/file/d8d009634290/source/debug.asm#l1319



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Another implementation of GRAFTABL

[C. Masloch]

Hi list,

On at 2022-07-12 16:29 +, Bret Johnson wrote:

For TSR's, there are additional things you can do to reduce memory.  You can 
look at the source code for my PRTSCR program (available at 
http://bretjohnson.us) that uses a BUNCH of tricks.  For example, it doesn't 
even use the DOS TSR interrupt.

The way it works is to make a "copy" of itself at the top of conventional memory, terminates itself (using a normal DOS 
terminate process, which includes deleting the original PSP), and then continues running from the "copy".  The 
"copy" decides where the best place in memory is to load the TSR (which can even be in one or more "memory 
holes" left by some other program or in upper memory), allocates appropriate memory block(s), and then installs itself in 
the allocated memory.  I learned that technique from ECM a long time ago.  It's much more complicated than a "normal" 
TSR installation, but is much more efficient in terms of ultimate memory use.


I developed this optimal installation handling first for RxANSI, based 
on Henrik Haftmann's ANSI, which I forked starting in 2008 [1]. I 
eventually adapted it into the TSR example [2] and then also for some 
other TSRs such as lClock [3].


To note is that the resident block installed this way doesn't have a PSP 
at all, just an MCB with itself as the owner and a DOS v4+ style MCB 
name for MEM type programs.



Other notes on your TSR and application:

Your GRAFTABL uses interrupt 21h service 31h to stay resident. You do 
free the environment, but to be on the safe side it is better to also 
clear the process's environment field to zero. Example code is in my TSR 
example [4]:


xor ax, ax
xchg ax, word [ cs:2Ch ]; set PSP field to zero
mov es, ax
mov ah, 49h
int 21h ; Free our environment


Further, you calculate the size of the PSP block to keep resident by 
using test, add, and shifts:


  mov   dx, trans   ; Allow everything preceding the
  test  dx, 0x000F  ;   transient portion of 
GRAFTABL to

  jz.20 ;   remain resident. (Rounded up to
  add   dx, 0x10;   the next paragraph, because 
MS-DOS

.20:  mov   cl, 4   ;   wants the size in paragraphs.)
  shr   dx, cl
  mov   ax, 0x3100
  int   0x21; TSR EXIT CODE 0

It is more efficient to change this like so:

mov dx, trans
add dx, 15
mov cl, 4
shr dx, cl

The "add dx, 15" makes the shr round up in its division. (I expect that 
the addition won't overflow here.) However, you can easily change it so 
that the addition is done by the assembler at build time, using "mov dx, 
trans + 15".


Moreover, while it is not supported in the most obvious way (like "mov 
dx, (trans + 15) / 16") you can teach NASM to do the entire calculation 
(shift or division and all) by calculating a scalar length of the 
program (as opposed to a relocatable symbol like created by your 
"trans:" label). There's an example of this in the DVORAK TSR (under GNU 
GPL v2+) by Donald Bindner [5] that goes as follows:



even 16
end_of_resident equ ($-$$ + 0100h)
...
mov dx, end_of_resident/16  ; number of paragraphs to keep
mov ax, 3100h   ; terminate resident w/ 0 return code
int 21h

As you can see, NASM allows to divide the scalar value. (Rounding up is 
not needed in this particular calculation because they already aligned 
the position of the end_of_resident equate to a 16-byte boundary.)


Here is another example [6], in FDAPM (by Eric Auer) which I extended 
with some but not all of my TSR ideas:


mov dx, (eofTSR - start + 256 + 15) >> 4
; +256 for PSP, start is at offset 100h
mov ax,3101h; go TSR, errorlevel 1
int 21h


In my TSRs and other applications I use more sophisticated calculations, 
some much more so. These are often based on different sections or 
segments of the program. I generally calculate deltas to address 
different parts and hardcode resulting values into the program at build 
time. However, the suboptimal way of calculating the amount of 
paragraphs at run time is a very common oversight.



Another problem (which is also little known) is that your use of 
interrupt 21h service 31h will retain all of your currently open process 
handles, as well as the entire system's System File Table (SFT) entries 
associated with these. This is not a problem by default because all your 
handles will be DUPlicated from the parent's, for your stdin, stdout, 
stderr, stdaux, and stdprn. That means they will share the same SFT 
entries as already used by the shell. However, if the user runs your 
program with output redirection (either to a file or a character device 
such as NUL), as in "graftabl > nul", then you will leak the SFT entry 
which was reserved for your process to use.

[Freedos-devel] Question: How to support IRQ sharing with other handlers?

[C. Masloch]

Hello list,

The recent thread on freedos-user reminded me that my debugger [1] (and 
also the serial comms test application I wrote prior [2]) has an IRQ 
handler for serial port communications [3] that doesn't allow sharing 
the IRQ with other handlers -- at least, not any installed before it. 
(In lDebugX this handler is still purely a Real/Virtual 86 Mode handler, 
which I have found can interact with DPMI running in Protected Mode in 
tricky ways. That is beyond the scope of my question however.)


The question is, how should I modify the handler to support sharing the 
IRQ? Is it enough to simply always chain to the "downlink" [4] after 
processing of my interrupt source is done? For reference, this is what 
happens (at least once each call) to determine whether to process an 
interrupt in my handler:


  in al, dx ; (read IIR) get interrupt cause
  test al, 1; did the UART generate the int?
  jnz ih_sep; no, then it's somebody else's problem

The ih_sep label a few lines down from that restores registers from the 
stack and then, as yet, does an iret.



The PS/2 and PC BIOS Interface Technical Reference [5], which is the 
original source for the IISP [6] as referenced by INTSHARE.DOC [4], has 
this to say about IRQ sharing (on page "4-5", page 166 of the PDF file):


> When the system acknowledges an interrupt request, each interrupt 
handler must determine whether it is the appropriate interrupt handler 
for the adapter presenting the interrupt request. This is accomplished 
by the handler reading the contents of the interrupt status register of 
the adapter.

>
> If the handler's device caused the interrupt, the handler must 
service the interrupt, reset the interrupt status bit, clear the 
interrupts, issue a non-specific EOI to the interrupt controller, then 
execute an IRET.

>
> If the handler's device did not cause the interrupt, the handler 
passes control to the next interrupt handler in the chain using the 
previously stored forward pointer.


This suggests I should chain to the downlink *iff* I detect that no 
interrupt was caused by my interrupt source, ie, that the "jnz ih_sep" 
branch is taken immediately on the very first check of the UART's IIR. 
If however the IIR indicates at least one interrupt was caused by the 
UART then after processing all the UART interrupts I should *not* chain 
to the downlink and return with an iret instead.


Is this what current practice suggests, too, or is it possibly just an 
artefact of this Technical Reference that is not followed commonly?



A related question is how to handle EOI. Currently I issue an EOI to 
either the primary PIC or both the secondary then primary PIC at the 
beginning of my interrupt handler, depending on which IRQ the handler is 
installed for. Should this stay as it is?


The Technical Reference (on page "4-9", PDF page 170) indicates that, 
when not "servicing" the interrupt for my interrupt source, I should 
check the EOI flag of the IISP header *in* the interrupt handler itself 
to determine whether to issue the EOI and iret, or else chain to the 
downlink. Does anyone actually do it this way?


Regards,
ecm


[1]: https://pushbx.org/ecm/web/#projects-ldebug
[2]: https://hg.pushbx.org/ecm/serialp/
[3]: 
https://hg.pushbx.org/ecm/ldebug/file/c2d96de77120/source/serialp.asm#l22

[4]: https://pushbx.org/ecm/test/2020/intshare/INTSHARE.DOC
[5]: 
https://pushbx.org/ecm/test/2020/bitsavers.trailing-edge.com%252Fpdf%252Fibm%252Fpc%252Fps2%252FPS2_and_PC_BIOS_Interface_Technical_Reference_Apr87.pdf

[6]: https://pushbx.org/ecm/doc/tsr/keephook.htm#long-workaround


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Announcement: lDebug release 3

[C. Masloch]

Hello FreeDOS developers and users,

Another 3 months have gone by and here's the next release of the 
advanced Debug re-implementation, lDebug, based on FreeDOS Debug. It is 
free/libre and builds from source using a toolchain including NASM and a 
C compiler.


Like before, there are 5 executables in the FreeDOS package's BIN 
directory. A few more choices of different compression methods are 
shipped in the SOURCE/LDEBUG/ldebug/tmp subdirectories. (Robert reported 
that the default LZMA-compressed executables may require several minutes 
to unpack on low-end machines. The fastest choice of compression method 
is likely LZ4. There are also the uncompressed executables.)


The manual has been updated to include the release 3 news [1], and also 
has received some additional parts. The packages are available from my 
server [2] in the /ecm/download/ldebug directory and its fdpkg 
subdirectory. My website [3] contains links to those and to the repo [4] 
too.



News include:

* Interrupt 8 hook (Timer) documented and made opt-in

* Interrupt 2Dh hook (AMIS, the Alternate Multiplex Interrupt 
Specification), opt-in


* Tries to unhook interrupt handlers properly if reachable by walking 
IISP (IBM Interrupt Sharing Protocol) headers and AMIS TSRs' interrupt 
lists, with options to force unhooking if individual handlers are not 
reachable.


* Expression evaluator additions: VALUE x IN y construct for range 
checking, ternary conditional cond ?? then :: else operator, LINEAR 
keyword to get linear addresses from segmented ones, string literals #"..."


* Instructions disassembled using the R command are now examined so as 
to set the READADR0 (linear address of a read access) and READLEN0 
(length in bytes) style variables, also WRITADRx and WRITLENx


* H BASE=/GROUP=/WIDTH= command to output numeric results in arbitrary bases

* Control-C handling improved: scan int 16h circular buffer for 
Control-C keypress, make Control-C abort running RE buffer and script 
files, allow lDebugX to use DOS function 0Ah in PM


* Several bug fixes

* A collection of acceptance tests

* Hosted on a new web domain (the old one ulukai.org still carries the 
same files for now but pushbx.org is preferred)



Note to the server admins: Please mirror the LDEBUG3.ZIP FreeDOS package 
from the fdpkg subdirectory!


Regards,
ecm


[1]: https://pushbx.org/ecm/doc/ldebug.htm#news-r3
[2]: https://pushbx.org/ecm/download/ldebug/
[3]: https://pushbx.org/ecm/web/#projects-ldebug
[4]: https://hg.pushbx.org/ecm/ldebug/


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[C. Masloch]

Hello Eric,

On at 2021-06-17 17:26 +0200, Eric Auer wrote:

while it is great to hear that you are doing a lot of
reading about EGA/VGA programming, I would suggest
that you use DEBUG to try a few things until you find
the first type of palette manipulation which works in
another virtual window but not in VirtualBox. Then
the next step could be trying to find setup changes
which solve the issue in VirtualBox. If none can be
found, the final option would be to patch VirtualBox.




Either that, or use DEBUG to try it out. Of course reading
and comparing source codes is a good starting point, but
EGA/VGA/CGA, as well as VESA/VBE could have some nasty
interactions which are hard to get compatible properly,
which may not be obvious from the source code.

So you can for example say "If I do those I (in) and O (out)
commands in DEBUG, or call this int 10 function, I expect
the palette to change this way and it indeed does in QEMU
or DOSEMU2, but not in VirtualBox" to get a confirmation
of where you suspect the problem to be.

It could also happen that the I/O or INT sequence you
had in mind works in none of the three, because there
are some additional preparatory I/O that you need. So
you can improve your I/O sequence and try again etc.

Note that DEBUG only offers byte-sized input and output.
For word-sized, you would have to write a test app in
any programming language you like to use for that :-)


FreeDOS Debug actually supports word-sized and dword-sized input and 
output, using the IW, ID, OW, and OD commands. My fork lDebug does 
likewise. lDebug additionally allows controlling the debugger through a 
serial port [1], which defaults to COM2 but can be configured for other 
ports too [2]. Further, lDebug allows loading script files using the Y 
command. The serial I/O and script file reading may be useful to test 
VGA output.


Regards,
ecm


[1]: https://pushbx.org/ecm/doc/ldebug.htm#interface-serial
[2]: https://pushbx.org/ecm/doc/ldebug.htm#varserial


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] weird memory map explained (was numerous problems...)

[C. Masloch]

Hello Eric,

On at 2021-05-27 12:38 +0200, Eric Auer wrote:

Sorry but given that my best guess is that you have misunderstood
the problem, you are not yet an experienced JEMMEX programmer.

Again, I ask you to use the "do not load EMM386" workaround for
now. If the topic is REALLY exciting for you, you can start by
learning how to use the protected mode features 386SWAT, IDEBUG
or other advanced debugging tools which let you trace across
real and protected modes: real mode, vm86 mode, protected mode
to understand what your BIOS is doing, or even how the internal
workings of EMM386 are. But I warn you, those are quite complex.


I'm not aware of any debugger called "IDEBUG". However, presumably you 
meant to refer to "lDebug" (first letter is noncapital L). And regarding 
lDebug, you would not be able to inspect "the internal workings of 
EMM386" with it. Let me quote my announcement of 2021-05-05:


> It runs in Real or Virtual 86 Mode, as a DOS application,
> DOS TSR, or bootloaded instead of an OS kernel. The DPMI-
> capable lDebugX also can run as a DPMI client.

EMM386 does not run as a DPMI client, so lDebug cannot debug it. 386SWAT 
may be able to debug an EMM, it seems to be more advanced in the modes 
in which it can operate.



Does it reserve a block at linear address 58000? If you use
my manual MCB edit trick, will more DOS apps work without a
crash? Which apps will keep crashing nevertheless?

Those are exciting questions which do not require the extreme
skill level of debugging protected mode usage conflicts which
you can easily avoid anyway by NOT loading EMM386 and JEMMEX.

Note that this is mostly of academic interest: NORMAL people
would just assume that if 5800:0 is reserved, the BIOS does
not cooperate sufficiently with DOS. They would install Linux
or Windows as next step and run DOS inside dosemu2 or dosbox.


I created a little script to allocate an MCB at an arbitrary address. I 
uploaded it to [1]. Usage: Install lDebug (release 2) from the FreeDOS 
package or the zipball or tarball [2]. Start LDEBUG.COM or LDEBUGU.COM 
in the directory you have the reserve.sld script file, then enter the 
following:


r v4 := 5800
r v5 :=  100
y reserve.sld

This should reserve an S MCB at "0x00058000-0x00058fff" 
if possible. You can also run the lDebug command "dm" before and after 
using reserve.sld to verify that it allocated the correct block.


Regards,
ecm

[1]: https://pushbx.org/ecm/test/reserve.sld
[2]: https://pushbx.org/ecm/download/ldebug/


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Distro autoexec/config wishes for 1.3rc4 (CPULEVEL and CALLVER updates)

[C. Masloch]

On at 2021-05-06 01:10 +0200, Eric Auer wrote:


Hi!


Also, you can use the 2 kB "CPULEVEL" tool instead of
VINFO but I guess you install VINFO everywhere anyway.



I added a bunch of things to your cpulevel and callver tools. cpulevel
now will detect NEC V20/V30 processors as 186-class too. The commit is


Exotic but nice :-) With upx --8086 the binary still fits in 2 kB :-)

If you have a real or virtual 8086, please verify that the UPX 8086
unpack header has kept the promise of not hurting 8086 compatibility.

>
> https://auersoft.eu/soft/specials/cpulevel_2021-05-06ecm.zip

I added a small feature to my debugger [1] to detect the maximum CPU 
level yet used in a given stretch of tracing disassembly. This allowed 
me to verify automatically that the UPX depacker in your binary (as well 
as the one I created myself with upx --8086) is 8086-clean. Only two 
commands are needed to achieve this; first a RE.APPEND with a condition 
that will cancel a T/P/G run if the "Maximum Machine Type" variable 
changes to nonzero, and then a TP command that runs "forever" (for a 
very long count), or until cancelled by the condition, or up to the 
process termination. This TP command is specified with the SILENT 
keyword to speed up the run, making it so only the very last register 
dumps are actually displayed.


This is the output of this run, with part of the register dumps cut for 
brevity. (About 8 KiB worth of dumps are included in this way, if no 
number is specified after the SILENT keyword.)


-re.append @if (mmt) then r dco2 or= 8000
-re
AX= BX= CX=07C2 DX= SP=FFFE BP= SI= DI=
DS=1D98 ES=1D98 SS=1D98 CS=1D98 IP=0100 NV UP EI PL ZR NA PE NC
1D98:0100 81FC940D  cmp sp, 0D94
-tp f silent
CPULEVEL - public domain by Eric Auer 2004-2008
[...]
AX=F000 BX=2E06 CX= DX=047E SP=FFFC BP= SI=0450 DI=0CCC
DS=1D98 ES=1D98 SS=1D98 CS=1D98 IP=0147 NV UP DI PL NZ NA PO NC
1D98:0147 9Cpushf
AX=F000 BX=2E06 CX= DX=047E SP=FFFA BP= SI=0450 DI=0CCC
DS=1D98 ES=1D98 SS=1D98 CS=1D98 IP=0148 NV UP DI PL NZ NA PO NC
1D98:0148 58pop ax
AX=7002 BX=2E06 CX= DX=047E SP=FFFC BP= SI=0450 DI=0CCC
DS=1D98 ES=1D98 SS=1D98 CS=1D98 IP=0149 NV UP DI PL NZ NA PO NC
1D98:0149 A900F0testax, F000
AX=7002 BX=2E06 CX= DX=047E SP=FFFC BP= SI=0450 DI=0CCC
DS=1D98 ES=1D98 SS=1D98 CS=1D98 IP=014C NV UP DI PL NZ NA PE NC
1D98:014C 746C  jz  01BAnot 
jumping

AX=7002 BX=2E06 CX= DX=047E SP=FFFC BP= SI=0450 DI=0CCC
DS=1D98 ES=1D98 SS=1D98 CS=1D98 IP=014E NV UP DI PL NZ NA PE NC
1D98:014E C606BE0C03mov byte [0CBE], 03 
DS:0CBE=02

AX=7002 BX=2E06 CX= DX=047E SP=FFFC BP= SI=0450 DI=0CCC
DS=1D98 ES=1D98 SS=1D98 CS=1D98 IP=0153 NV UP DI PL NZ NA PE NC
1D98:0153 669C  pushfd
-

Using the CPULEVEL source or listing file you can verify that this is in 
a part of the application, after its 386+ detection has succeeded. Thus 
the depacker is 8086-clean.


Just for fun I repacked the same executable using upx without the --8086 
switch. The same two commands to the debugger are used, and indeed the 
depacker ends up running at least one instruction for the 186:


[...]
AX=00EB BX=8000 CX=0010 DX= SP=FFFC BP= SI=0121 DI=0CCC
DS=1E06 ES=1E06 SS=1E06 CS=1E06 IP=0D21 NV UP EI NG NZ NA PO NC
1E06:0D21 AClodsb
AX=00E8 BX=8000 CX=0010 DX= SP=FFFC BP= SI=0122 DI=0CCC
DS=1E06 ES=1E06 SS=1E06 CS=1E06 IP=0D22 NV UP EI NG NZ NA PO NC
1E06:0D22 2CE8  sub al, E8
AX= BX=8000 CX=0010 DX= SP=FFFC BP= SI=0122 DI=0CCC
DS=1E06 ES=1E06 SS=1E06 CS=1E06 IP=0D24 NV UP EI PL ZR NA PE NC
1E06:0D24 3C01  cmp al, 01
AX= BX=8000 CX=0010 DX= SP=FFFC BP= SI=0122 DI=0CCC
DS=1E06 ES=1E06 SS=1E06 CS=1E06 IP=0D26 NV UP EI NG NZ AC PE CY
1E06:0D26 77F9  ja  0D21not 
jumping

AX= BX=8000 CX=0010 DX= SP=FFFC BP= SI=0122 DI=0CCC
DS=1E06 ES=1E06 SS=1E06 CS=1E06 IP=0D28 NV UP EI NG NZ AC PE CY
1E06:0D28 C10408rol word [si], 08 
DS:0122=2BC1

-


at [1], latest revision at [2]. callver [3] now supports 21.33FC version
setting even if implemented on another DOS version than FreeDOS (none
known, *yet*), and allows running with a new "SHOW" keyword to only list
the current version. And 21.33FF is used to show a version string, if
any, regardless of OEM code too (which is supported by the recent RxDOS
kernel versions already).


I guess you should also test whether AL is not 0xff on return,
as non-supporting DOS would not only leave DX unchanged, but
also return AL as 0xff. To test whether DX is unchanged, it
might be better to pre-set it to for example 0xfffe instead
of zero, if a version string in HMA 0x:x or 0:x is used?


A HMA version string (with segment h, FFFEh, or any other HMA 
segment) is supported by my method. I think it is solid 

Re: [Freedos-devel] Distro autoexec/config wishes for 1.3rc4 (CPULEVEL and CALLVER updates)

[C. Masloch]

On at 2021-05-03 11:05 +0200, Eric Auer wrote:


Also, you can use the 2 kB "CPULEVEL" tool instead of
VINFO but I guess you install VINFO everywhere anyway.


C:\>cpulevel
CPULEVEL - public domain by Eric Auer 2004-2007
CPU brand is GenuineIntel / CPU is family 5 model 2 revision c
  
 CPUID level 1 EAX_ EBX_ ECX_ EDX_

   values are: 052c   01bf
  
CPUID level 1 feature bits in EDX:

   [FLOATING POINT]   [VM EXT FLAGS] [debug ext][Page Size Ext.]
   [TIMESTAMP COUNT]  [Pentium MSR]  [mce exception][cmpxchg8b op]
  
C:\>echo %errorlevel%

5


Of course you can do cpulevel > NUL if you prefer silence.


Hi Eric,

I added a bunch of things to your cpulevel and callver tools. cpulevel 
now will detect NEC V20/V30 processors as 186-class too. The commit is 
at [1], latest revision at [2]. callver [3] now supports 21.33FC version 
setting even if implemented on another DOS version than FreeDOS (none 
known, *yet*), and allows running with a new "SHOW" keyword to only list 
the current version. And 21.33FF is used to show a version string, if 
any, regardless of OEM code too (which is supported by the recent RxDOS 
kernel versions already).


Regards,
ecm


[1]: https://hg.ulukai.org/ecm/cpulevel/rev/e02c80c361ea
[2]: https://hg.ulukai.org/ecm/cpulevel/file/tip/cpulevel.asm
[3]: https://hg.ulukai.org/ecm/callver/file/tip/callver.asm


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Announcement: lDebug release 2, suggest to include in FreeDOS release

[C. Masloch]

Hello FreeDOS developers and users,

I decided to push out release 2 of my FreeDOS Debug fork today, nearly 3 
months after release 1. It is based on 2008's FreeDOS Debug 1.13 first, 
staying with the Netwide Assembler source, though with many of the 
changes added to FreeDOS Debug since ported and merged in.


It is an advanced take on a simple line I/O based debugger. It can be 
controlled as a DOS application (int 21h), from a ROM-BIOS terminal (int 
10h, int 16h), through a serial port, and/or from script files. It runs 
in Real or Virtual 86 Mode, as a DOS application, DOS TSR, or bootloaded 
instead of an OS kernel. The DPMI-capable lDebugX also can run as a DPMI 
client.


lDebug is free/libre software and can be re-built entirely using a free 
toolchain. The provided scripts are for cross-compile building on a 
desktop or server Linux host system.


As before, the manual is included, in a HTML file (preferred) as well as 
a text file and PDF. The five application executables are the same as 
for the prior release too; ldebug.com and ldebugx.com are 
LZMA-compressed, ldebugu.com and ldebugxu.com are uncompressed, and all 
four can be used as DOS applications or bootloaded from the lDOS boot 
sector loaders. The included instsect application allows installing such 
a loader to a DOS drive, file system image file, or into a boot sector 
file for chainloading. All programs are intended to run on any processor 
type down to the 8088/8086 level.


Refer to my website [1] for links to the releases, repo, and most recent 
documentation on the web. Changes since release 1 (and the ones prior to 
release 1) are now listed in the manual [2]. Release 2 includes a few 
bug fixes, as well as two new features: Line editing history [3] and 
register dump change highlighting [4].


Jerome suggested [5] for me to write to the mailing lists to advertise 
this package and suggest it be included in future FreeDOS releases. I 
decided to finish release 2 for the occasion, mainly because I would 
like to get out the bug fixes added since release 1.


To the ibiblio server admins: Please mirror the LDEBUG2.ZIP file from my 
FreeDOS package subdirectory [6].


Regards,
ecm


[1]: https://ulukai.org/ecm/web/#projects-ldebug
[2]: https://ulukai.org/ecm/doc/ldebug.htm#news-r2
[3]: https://ulukai.org/ecm/doc/ldebug.htm#interface-input
[4]: https://ulukai.org/ecm/doc/ldebug.htm#interface-rdump
[5]: https://github.com/shidel/FDI/issues/14
[6]: https://ulukai.org/ecm/download/ldebug/fdpkg/


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Announcement: lDebug release 1

[C. Masloch]

On at 2021-03-04 11:06 -0600, Jim Hall wrote:

On Thu, Mar 4, 2021 at 11:02 AM C. Masloch  wrote:


On at 2021-03-03 17:20 -0600, Jim Hall wrote:

Thanks. I also noticed that you have a "draft 3" file there as of
today, so I mirrored all of the "drafts" to the ibiblio site as a
backup.


Just added draft 4 today. Changes in draft 3:

- Deleted SOURCE/LDEBUG/ldebug/doc/*.info* files to avoid needing LFNs.
(Future releases will only build PDF, HTML (.htm) and .txt files.)

Changes in draft 4:
[..]


Thanks for the new draft! I don't want to keep re-mirroring "draft"
versions, so I may wait until the next actual release before I mirror
lDebug again.


I just copied draft 4 to the LDEBUG1.ZIP file, please mirror that.

Regards,
ecm


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Announcement: lDebug release 1

[C. Masloch]

On at 2021-03-04 11:06 -0600, Jim Hall wrote:

On Thu, Mar 4, 2021 at 11:02 AM C. Masloch  wrote:


On at 2021-03-03 17:20 -0600, Jim Hall wrote:

Thanks. I also noticed that you have a "draft 3" file there as of
today, so I mirrored all of the "drafts" to the ibiblio site as a
backup.


Just added draft 4 today. Changes in draft 3:

- Deleted SOURCE/LDEBUG/ldebug/doc/*.info* files to avoid needing LFNs.
(Future releases will only build PDF, HTML (.htm) and .txt files.)

Changes in draft 4:
[..]


Thanks for the new draft! I don't want to keep re-mirroring "draft"
versions, so I may wait until the next actual release before I mirror
lDebug again.


I'd suggest waiting a few days (until Monday maybe) in case anyone else 
has comments or improvements to the package, then if nothing changed I 
will copy it to LDEBUG1.ZIP and notify you. Should still be in time for 
the next FreeDOS release I guess?


Thanks,
ecm


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Announcement: lDebug release 1

[C. Masloch]

On at 2021-03-03 17:20 -0600, Jim Hall wrote:

Thanks. I also noticed that you have a "draft 3" file there as of
today, so I mirrored all of the "drafts" to the ibiblio site as a
backup.


Just added draft 4 today. Changes in draft 3:

- Deleted SOURCE/LDEBUG/ldebug/doc/*.info* files to avoid needing LFNs. 
(Future releases will only build PDF, HTML (.htm) and .txt files.)


Changes in draft 4:

- Copied instsect.com to BIN/

- Added DOC/LDEBUG/fdbuild.txt

I also added the fdbuild.txt file to my repo [1] so that starting with a 
future release 2, we can re-use the file from the repo instead of having 
to handle / copy it around outside of version control for every build.



1. Should instsect.com be copied to BIN/ ?



From the source, INSTSECT installs a boot sector. If you intend that
users should use INSTSECT to install a boot sector, then yes - you
should include this in BIN. I didn't look too closely at your files,
so I don't know what INSTSECT is used for here.


Yes it installs a boot sector for FAT12, FAT16, or FAT32 FS drives, 
which implements the lDOS / RxDOS.3 protocol. The filename defaults to 
LDEBUG.COM to aid in loading the bootable debugger. (Recent RxDOS.COM 
kernel revisions use the same protocol.) I copied it over to BIN/ now.



2. Should I add a short file describing how to build from the zipfile?
(Essentially just repeating what I listed in the changes here.)



Yes, you should include instructions for how to build the lDebug
program from source (from the zip file). You should save this in the
DOC directory, in some obvious filename like BUILD.TXT or some such.


Done!

Regards,
ecm


[1]: https://hg.ulukai.org/ecm/ldebug/rev/737faa76f3d8


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Announcement: lDebug release 1

[C. Masloch]

On at 2021-02-22 09:32 -0600, Jim Hall wrote:

Do you mean this link [1]?



Yes that will be fine.


Done.


By the way, I just noticed that someone uploaded (presumably) my draft
FreeDOS zip package to [2]. I'd rather fix it first with all the
sources
as discussed. No harm done I guess, though.



That's the version that is still available on your website, and I 
thought it was the official version. Here's how I found it:


Apologies. This file was just intended as a draft depicting how I 
thought a FreeDOS package might look. To avoid this confusion, I renamed 
it to draft1-1.zip (and also created a subsequent draft1-2.zip file).


I just grabbed the file again, and it has the same hash signature as the 
one I downloaded before, so I think I mirrored the right one. What's the 
correct zip file that I should get instead?


I will copy one of the drafts to the final name once we've finished up 
the packaging. For now, have the second draft. Changes in this one:


1. Added the Original-site link to FreeDOS Debug 1.13

2. Moved sources from SOURCE/LDEBUG/* to SOURCE/LDEBUG/ldebug/*

3. Added additional sources: inicomp, instsect, ldosboot, lmacros, 
scanptab, tellsize. Installing the required toolchain (refer to manual) 
and manually compiling tellsize allows rebuilding all sources. (Also 
using ./makec, ./mktables, and ./mak.sh as all described in the manual.) 
Using "./mak.sh reproduce" allows reproducing the build exactly (I 
tested this in a fresh directory). All additional source trees are 
placed below SOURCE/LDEBUG/ (This is structure number 2 in my 2021-02-20 
mail.) The sources are accessible to the mak script using the default 
cfg.sh configuration, which contains relative paths to sibling 
directories of SOURCE/LDEBUG/ldebug.


Steps I took to create this file:

1. Edit the LSM file

2. Move files in SOURCE/LDEBUG/* to SOURCE/LDEBUG/ldebug/

3. Create empty directories for all the other repos

4. Clone repos into the directories, and strip off their .hgignore and 
.hg/* files with a command like this:


> for dir in *; do if [[ $dir != ldebug ]]; then hg clone 
~/webrepos/$dir $dir; rm -rf $dir/.hg*; fi; done


5. Zip the four directories (APPINFO, BIN, DOC, SOURCE)

Remaining questions:

1. Should instsect.com be copied to BIN/ ?

2. Should I add a short file describing how to build from the zipfile? 
(Essentially just repeating what I listed in the changes here.)


Regards,
ecm


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Announcement: lDebug release 1

[C. Masloch]

Accidentally replied off-list instead of to the list. Here's what I 
meant to send.


Regards,
ecm


 Forwarded Message 
Subject: Re: [Freedos-devel] Announcement: lDebug release 1
Date: 2021-02-22 12:12:01 +0100 Feb Mon
From: C. Masloch 
To: Jim Hall 

On at 2021-02-21 17:41 -0600, Jim Hall wrote:
Yes, the FreeDOS LSM format is basically the Linux LSM file format. (Our 
standard was forked from the earlier LSM version 3 format, which is why 
you see "Begin3" in our LSM files.) LSM provided a handy way to capture 
the metadata about a package, so you know who wrote it originally, who 
is the current maintainer, and where to find it.


I would use the most recent "Debug" that you based this code on. But 
since you said "the fork is in some ways far from its FreeDOS Debug 1.13 
roots" then you could instead set the "Original-site" field to the same 
value as "Primary-site". In this case, that's up to you. But to maintain 
the history, my suggestion would be to set "Original-site" to point to 
the most recent "Debug" you based this on.


Do you mean this link [1]?

By the way, I just noticed that someone uploaded (presumably) my draft 
FreeDOS zip package to [2]. I'd rather fix it first with all the sources 
as discussed. No harm done I guess, though.


Regards,
ecm

[1]: 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/debug/old/debug113.zip
[2]: 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/debug/ldebug/



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Announcement: lDebug release 1

[C. Masloch]

On at 2021-02-20 16:40 +0100, tom ehlert wrote:

Hallo Herr C. Masloch,


Not a Herr. But hello to you too,


am Samstag, 20. Februar 2021 um 12:49 schrieben Sie:


On at 2021-02-19 20:39 +0800, TK Chia wrote:

Hello Masloch,



1. Is this the right amount of sources? The macro collection, ldosboot,
instsect, and scanptab repos' contents are not included, but they are
required to rebuild everything. The tellsize tool is another component
not included. (As listed in the LSM, I crosscompile from a (Debian)
Linux host system.)


I am not quite sure --- I have not yet checked the packaging --- but
generally, if the dependencies might require additional set of secret
incantations to download and build, then I would probably prefer to have
them included in the sources.



Well, they aren't exactly "secret" considering as they are documented in
the manual [1]. But point taken.



(If the build procedure will also automatically download the
dependencies, then I guess it might be OK to exclude them.  But that is
just my opinion.)



Okay, I don't have any scripts to do that. So you'd rather I include all
the sources I take it. That yields another question: What layout should
I use?


we don't have rules for that, as long as there is a script to rebuild
the stuff with the given structure.

most projects come with a single directory, but others (kernel,
FreeCOM) have half a dozen.

the rule should be from unpack and lean back to watch the machine
compile within 30 seconds. of course this assumes your requirements
(python, pearl, ...) already installed.

probably simply copy your own structure into sources\ldebug


Can you please clarify which of the three structures I listed would that 
be that you mean? The one with SOURCE/LDEBUG/ldebug/source/ and thus 
SOURCE/LDEBUG/lmacros/ (structure number 2) or the one where there are 
additional directories directly in SOURCE like SOURCE/lmacros/ 
(structure number 1) ?



On at 2021-02-20 19:26 +0100, tom ehlert wrote:
>> 1. Is this the right amount of sources? The macro collection, ldosboot,
>> instsect, and scanptab repos' contents are not included, but they are
>> required to rebuild everything.
>
> Duh? if it's required to rebuild, why do you skip it?
>
> Just imagine yourself going to a brand new Debian system, download
> your lDebug.zip. How would you recreate lDebug? If I understand
> correctly your macro collection would be quite handy ;)

I guess so! But then, I would actually always set up the hg repos to 
retrieve the most recent revisions of all the sources. That also offers 
the revision histories, which a zipfile (as we're excluding the .hg 
state) does not have. But thanks for your opinion, I will add the 
additional sources once we figure out which layout to use.


Regards,
ecm


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Announcement: lDebug release 1

[C. Masloch]

On at 2021-02-19 20:39 +0800, TK Chia wrote:

Hello Masloch,



1. Is this the right amount of sources? The macro collection, ldosboot,
instsect, and scanptab repos' contents are not included, but they are
required to rebuild everything. The tellsize tool is another component
not included. (As listed in the LSM, I crosscompile from a (Debian)
Linux host system.)


I am not quite sure --- I have not yet checked the packaging --- but
generally, if the dependencies might require additional set of secret
incantations to download and build, then I would probably prefer to have
them included in the sources.


Well, they aren't exactly "secret" considering as they are documented in 
the manual [1]. But point taken.



(If the build procedure will also automatically download the
dependencies, then I guess it might be OK to exclude them.  But that is
just my opinion.)


Okay, I don't have any scripts to do that. So you'd rather I include all 
the sources I take it. That yields another question: What layout should 
I use?


Either:

1. Put sources for other repos in their own SOURCE subdirectories. That 
results in SOURCE/ldebug/source/debug.asm, SOURCE/lmacros/lmacros1.mac, 
etc (would work with the default cfg.sh settings) (SOURCE subdirectories 
not in allcaps to potentially support building as-is, as the scripts 
expect the names to not be capitalised if that matters on a 
case-sensitive FS)


2. Put everything into subdirectories under SOURCE/LDEBUG; move main 
lDebug sources down another level: 
SOURCE/LDEBUG/ldebug/source/debug.asm, 
SOURCE/LDEBUG/lmacros/lmacros1.mac (would also work with the default 
cfg.sh settings)


3. Keep main sources where they are but store extra sources in 
SOURCE/LDEBUG subdirectories along the main sources: 
SOURCE/LDEBUG/source/debug.asm, SOURCE/LDEBUG/extra/lmacros/lmacros1.mac 
(cfg.sh defaults would not be applicable, could go along with an ovr.sh 
pointing to the right relative directories)



4. Is the Primary-site link in the LSM fine? And: I don't think
Japheth's or Paul Vojta's sites should be linked in the LSM, considering
that the fork is in some ways far from its FreeDOS Debug 1.13 roots.


iBiblio has a short page at
http://www.ibiblio.org/pub/linux/LSM-TEMPLATE.html on the LSM format as
it applies to Linux.  Apparently it also defines an "Original-site:"
field --- it might be useful to use that, in case you would like to also
link back to Vojta's or Japheth's original Debug.


The Primary site, Alternate site and Original site for the debug LSM [2] 
are as follows:


Primary siteGitHub -- Baron-von-Riedesel/DOS-debug [3]
Alternate site  GitLab -- FDOS/base/debug [4]
Original site   http://www.japheth.de/Download/

Which site should I enter as Original-site for my LSM?

Regards,
ecm


[1]: https://ulukai.org/ecm/doc/ldebug.htm#buildingcomponents
[2]: 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/debug.html

[3]: https://github.com/Baron-von-Riedesel/DOS-debug
[4]: http://gitlab.com/FDOS/base/debug


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Announcement: lDebug release 1

[C. Masloch]

Hello FreeDOS developers,

I'll first paste the announcement I made to our BTTR Software forum [1]. 
After that I'll add a few more things specific to FreeDOS.


===

I just finished up lDebug release 1.

The release primarily includes the manual (HTML is the preferred format, 
text and PDF available too), and five executables: lDebug (86 Mode only) 
and lDebugX (DPMI capable), both of each either uncompressed or lzip 
LZMA compressed, and instsect set up to install a boot sector loader for 
FAT12, FAT16, or FAT32 which can load any of the debugger executables as 
a bootable kernel. Further executables include LZ4 or Exomizer 3 
compressed executables if one prefers those. The lzip LZMA compression 
was selected as the default method based on it compressing to the 
smallest resulting files.


All executables and loaders are supposed to work on anything down to 
8088/8086 level machines. The loaders (boot sectors as well as the 
iniload stage embedded in the executables) prefer to use LBA access if 
available, and fall back to CHS access else.


The main sources (included in the releases) amount to 43k lines:

source$ cntlines -q *.asm *.MAC *.mac
Files:  23
Bytes:  976576
Total lines:43010
 Blanks:4660
 Comment only:  8834
 Actual code:   29516

Several other source repos are required for assembly. All of those are 
available from my Mercurial repos [2]. The assembler used was NASM 
version 2.15.03 (its preprocessor is extensively used). Complete 
building requires a C compiler to build several supporting applications.


My website [3] contains links to the repo, releases, and manual on the 
web (always the most recent one), or you can directly load the lzipped 
tarball [4] (1.6 MiB) or the zipfile [5] (5.5 MiB).


To get a sense of what is new since I forked FreeDOS Debug 1.13 you can 
read the blurb on my website or at the beginning of the manual. For more 
in depth descriptions of most of the new features you'll have to read 
the manual. For a quick start, run one of the executables and enter the 
? command to get the main online help. (This should be paged according 
to the amount of rows on screen.) At the end of the main online help, 
further online help pages are referenced.


lDebug is free software, primarily under the Fair License [6], though 
the original FreeDOS Debug's MIT license and the 2-Clause BSD license 
(transitionally used for lDebug) are offered as alternatives too.


(I intend to repackage the release for a FreeDOS installer compatible 
zipfile at a later time. Meanwhile FreeDOS users can unpack this release 
manually.)


===

I consulted the FreeDOS wiki on how to package the application [7], and 
what to put into the LSM file [8]. I also reviewed the existing FreeDOS 
Debug package info [9] for direction on writing the LSM file. Finally I 
created a package that I hope can be included in a FreeDOS distribution 
[10] (5.7 MiB). For reference, here is the content of the LSM:


Begin3
Title: lDebug
Version: release 1
Entered-date: 2021-02-15
Description: advanced debugger based on FreeDOS Debug
Keywords: debug, debugger, DPMI debugger, bootable debugger
Author: Paul Vojta 
 Andreas "Japheth" Grech 
Maintained-by: C. Masloch 
Primary-site: https://ulukai.org/ecm/web/#projects-ldebug
Platforms: DOS (crosscompile from Linux with NASM and C compiler)
Copying-policy: Fair License
End

And this is how I created the package:

1. Extract from ldebug1.zip (the non-FreeDOS release zipfile)

2. Make directories SOURCE/LDEBUG

3. Move all other directories and files into SOURCE/LDEBUG

4. Make directory BIN

5. Copy SOURCE/LDEBUG/bin/ldebug*.com to BIN

6. Make directories DOC/LDEBUG

7. Copy SOURCE/LDEBUG/doc/ldebug.(txt|pdf|htm) to DOC/LDEBUG

8. Copy SOURCE/LDEBUG/license.txt to DOC/LDEBUG

9. Make directory APPINFO

10. Create LSM file

11. Insure the copied license.txt, ldebug.txt, and LSM have DOS format 
linebreaks; ldebug.txt required using dos2unix to achieve this


12. Create zipfile using the command:

> 7za a -mm=deflate -mx=9 -tzip LDEBUG1.ZIP APPINFO BIN DOC SOURCE

Please tell me if there is anything to improve about the packaging. 
Particular points of interest:


1. Is this the right amount of sources? The macro collection, ldosboot, 
instsect, and scanptab repos' contents are not included, but they are 
required to rebuild everything. The tellsize tool is another component 
not included. (As listed in the LSM, I crosscompile from a (Debian) 
Linux host system.)


2. Would you rather I include fewer of the temporary files, listing 
files, and map files? Surely at least the LZ4 and Exomizer 3 compressed 
executables are useful to include, however, considering the faster 
decompression (both) and the uniform usage conditions (the LZ4 stub's 
copyright lies only with me as I fully implemented it based on their 
specs, not their sources).


3. Should instsect.com go into the BIN directory too? Generally the 
lDebug release is th

Re: [Freedos-devel] Kernel.asm question

[C. Masloch]

Hello list,

I just recently answered a question about this, it is at
https://stackoverflow.com/questions/22409680/interrupt-21-h-function-31-h-dx-value/57762787#57762787

Quoting the relevant part not mentioned in this thread yet:

> Another issue is that the calculation can be done at build
> time instead of at run time. That is too arcane for most
> programs, indicated by the fact that the mov \ shr
> combination is fairly common in 86-DOS programs. It may
> need some tricky handling, depending on the assembler.
> Here's an answer to a different question, with an example
> of build-time calculation written for NASM:
>
> https://stackoverflow.com/a/57762635/738287

> To calculate the size of your resident process, use NASM
> labels. To allow shift (or divide) operations needed to
> figure out a length in paragraphs, only use deltas of
> labels. A delta (difference) is a scalar value to NASM,
> so can be used in calculations. A (non-struc) label alone
> is not a scalar.

> The size calculation computes the delta of two labels, [...]
> adds 15 to make the shift-division round up, then shifts down
> into an amount of paragraphs.


Regards,
ecm


On at 2019-09-21 16:53 +0800, TK Chia wrote:
> Hello Quinton,
> 
> In case you are not already aware: the 16-bit x86 uses segment:offset
> pairs for memory addresses, where a 16-bit segment and 16-bit offset is
> combined to allow about 1 MiB of memory to be addressed:
> 
>   PhysicalAddress = Segment * 16 + Offset
> 
> (see https://wiki.osdev.org/Real_Mode).  This is why counting 16-byte
> paragraphs is something that figures quite a lot in 16-bit code.
> 
> Thank you!
> 
> On 9/21/19 16:38, TK Chia wrote:
>> Hello Quinton, hello Mark,
>>
>> I am looking at (I believe) a slightly more recent version of the
>> FreeDOS kernel source code (https://github.com/FDOS/kernel), but I think
>> the same reasoning applies.
>>
>> Basically the kernel is trying at this point to move its IGROUP
>> (initialization code), I_GROUP (initialization data), and (I think)
>> HMA_TEXT, to the top of conventional memory.  Before doing that, it
>> needs to calculate a memory address where it can move IGROUP, I_GROUP,
>> and HMA_TEXT to.
>>
>>  int 12h ; move init text+data to higher memory
>>  mov cl,6
>>  shl ax,cl   ; convert kb to para
>>
>> The BIOS's int 0x12 returns the amount of conventional memory in ax, as
>> a Kbyte count (e.g. 640).  By multiplying by 1,024 / 16 = 64, we can
>> converts this to a count of 16-byte paragraphs.  For 640 KiB of
>> conventional memory, this will be 0xa000.
>>
>> Conventional memory starts at real mode address 0:0, so the paragraph
>> count also gives the real mode segment base of the _top_ of conventional
>> memory --- 0xa000:0.
>>
>>  mov dx,15 + INITSIZE
>>  mov cl,4
>>  shr dx,cl
>>
>> This tries to calculate the number of paragraphs needed by the I_GROUP
>> (initialization data) segment.
>>
>> The init_end symbol marks the end of the whole I_GROUP segment.
>> However, it may not be placed at a 16-byte-aligned address --- it is
>> defined in the IB_E segment, and the linker will place IB_E's contents
>> into I_GROUP output after other input segments that contribute to
>> I_GROUP (ID_B, ID, ID_E, IC, etc.).
>>
>> So to get the correct number of paragraphs, the kernel needs to round
>> _up_ the address of init_end when dividing it by 16, which is why it
>> adds 15 first.  Without adding 15, a `shr' by 4 will instead round down
>> the address of init_end, which will not be correct.
>>
>>  sub ax,dx
>>
>> ax from the earlier `int 12h' holds the address of the top of
>> conventional memory.  By subtracting the number of paragraphs needed by
>> the I_GROUP segment, the kernel can get the address of a memory area
>> near the conventional memory top where it can move I_GROUP to.
>>
>> I hope this helps a bit.  Thank you!
>>
>> On 9/21/19 10:52, Mark Olesen wrote:
>>> Howdy,
>>>
>>> Your aligning by 16 byte paragraph
>>>
>>> On Fri, Sep 20, 2019 at 7:45 PM Quinton Cook 
>>> wrote:
>>>
 Hello all,

 I have recently taken an academic interest in the freedos project. My
 current goal is to understand how the kernel was implemented.

 While reading the kernel.asm file located
 in freedos-svn/kernel/branches/jhall/kernel I have inferred that the
 routine "kernel_start" is calculating the overall memory available to
 the
 system. but I came across a snippet of code that confused me.
 Starting on
 line 128
 it goes

 mov dx,init_end+15
 mov cl,4
 shr dx,cl
 sub ax,dx

 why is 15 added to the end of the address of the symbol init_end if you
 just shift the value right by 4, doesn't that just undo the addition?
 Is it
 related to memory addresses having to be divisible by 16?
 Segmentation or
 something like that?

 Also is that last sub calculating the 

Re: [Freedos-devel] FreeDOS 1.3 list of packages

[C. Masloch]

On at 2018-11-05 18:01 +, Bret Johnson wrote:
> Being the author of two of the items mentioned (USBDOS & SLOWDOWN), I can say 
> that there is no problem in including them with FreeDOS.  SLOWDOWN is a much 
> older program than USBDOS, and the licensing and even my opinions of what the 
> licensing should be have changed over the years.
> 
> What I want is for all of my programs and their derivatives to be free, in 
> every sense of the word, for people and businesses to USE.  I don't want them 
> making non-free stuff, in any sense of the word, from the programs themselves 
> or their source code.
> 
> I realize this is kind of a hard and foreign concept to relate to other 
> people, but I want my programs to be forever free in every sense of the word. 
>  I don't differentiate between "free beer" and "free speech" as some others 
> tend to do.  My programs are free, just like salvation is free.  I will also 
> give the source code for any of my programs to anybody who wants it (although 
> some of it is quite messy) as long as they "keep it free".

Your USBINTRO.DOC says:

> You also cannot distribute the programs, documentation, or
> source code and charge (even indirectly) for their distribution.
> You can charge someone enough to cover your actual, direct costs
> for distribution (disks, shipping materials, postage, etc.), but
> cannot charge for "handling".  This also means that you cannot
> distribute the programs, documentation, or source code directly
> from a web site that charges a "registration fee" in an attempt
> to make a profit or to recover direct or indirect costs for
> maintaining the web site.

This I believe is incompatible with FLOSS as defined by the FSF and OSI.

Anyway, in the interest of avoiding license proliferation, it'd be very
convenient if you switched to a well-known license like the GNU GPL
(v2-only, v2+ or v3+). That makes it easier on any user who wants to
understand (and honour) your usage conditions, because they'll already
be familiar with the GPL from other occurrences of it.

Regards,
ecm


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease

[C. Masloch]

On 2018-08-21 22:23 +0800, TK Chia wrote:
> However, both the intr ( ) implementation in Open Watcom, and the intr (
> ) implementation in suppl/src/intr.asm used when compiling with
> gcc-ia16, will _not_ try to load any flags --- including CF --- from
> reg.x.flags, so int 0x21 basically gets called with CF in an undefined
> state (and it happens to be set in commandg's case).  And DOSBox's
> implementation of the "get allocation strategy" call does not change CF.

It should set or clear CF, as to indicate the error status. If it leaves
CF unchanged, that's a DOSBox error. I just verified that both FreeDOS
(kernel 2042) and MS-DOS 7.10 clear CF on return from 21.5800.

Regards,
ecm

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] [Freedos-cvs] SF.net SVN: freedos:[1781] freecom/trunk

[C. Masloch]

Hello,

there seems to be an error in this commit, see below.

On at 2018-01-25 16:16 +, bartoldeman--- via Freedos-cvs wrote:
> Revision: 1781
>   http://sourceforge.net/p/freedos/svn/1781
> Author:   bartoldeman
> Date: 2018-01-25 16:16:21 + (Thu, 25 Jan 2018)
> Log Message:
> ---
> Port xms-swap support to ia16-elf-gcc.


> Modified: freecom/trunk/include/cswap.h
> ===
> --- freecom/trunk/include/cswap.h 2018-01-23 11:59:03 UTC (rev 1780)
> +++ freecom/trunk/include/cswap.h 2018-01-25 16:16:21 UTC (rev 1781)
> @@ -20,6 +20,19 @@
>   };
>  #include "algndflt.h"
>  
> +#ifdef __GNUC__
> +extern char dosFCB1[128] asm("_dosFCB1");
> +extern char dosFCB2[128] asm("_dosFCB2");
> +
> +extern struct ParamDosExec dosParamDosExec asm("_dosParamDosExec");
> +
> +#define dosFCB1 RESIDENT(dosFCB1)
> +#define dosFCB2 RESIDENT(dosFCB1)

--^  should be (dosFCB2)

> +#define dosParamDosExec RESIDENT(dosParamDosExec)
> +
> +extern unsigned char dosCMDNAME[128] asm("_dosCMDNAME");
> +#define dosCMDNAME RESIDENT(dosCMDNAME)
> +#else
>  extern char far dosFCB1[128];/* must be setup 
> correctly */
>  extern char far dosFCB2[128];
> 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] BtrFS filesystem in FreeDOS

[C. Masloch]

 That depends on whether you'd consider MSW 3.x or 4.x respectively to
 constitute a complete new and different OS on top of MS-DOS =P

 What is MSW?

Does this help?:

http://www.google.com/search?q=MSW+4.x+%22MS-DOS%22+DOS+kernel

Basically an abbreviation that doesn't suggest some sort of Win.

 Well, at least as far as I understood it, FreeDOS-32 did aim for  
 something
 similar - specifically, running the new (FreeDOS-32) kernel in protected
 mode, and ultimately allowing to run virtual(ised) machines for (V)86M  
 DOS
 compatibility similar to regular tasks in that system (as well as DPMI  
 or
 native applications, or potentially others).

 Sounds easy, but people seem to forget the problems with all DOS
 internal structures and calls/interrupts being 16bit real mode, this
 would be a far from trivial task. Even DOS extenders have already
 quite a hell of a time to stay compatible with that...

DOS extenders are something entirely different (API translation from one  
mode to another).

Virtualisation and even full emulation are relatively 'easy' to implement  
on current machines (because of their performance), though some work is  
still necessary.

To allow multiple tasks to access the same physical resources, some  
abstraction is needed of course, such as using a redirector-like interface  
for file system access within the task and handling the calls from this  
interface by passing them to the actual file system drivers (which  
necessarily must implement workable file locking semantics, unlike the  
typical expectation for DOS systems that do not explicitly multi-task). Or  
accessing a file system image instead of an actual file system, where each  
image is typically associated with no more than one running task. Both of  
these methods are provided by DOSBox and dosemu, the former is employed by  
NTVDM, the latter is generally provided by emulators.

(If memory serves, DOSBox unfortunately provides high-level file system  
redirection only within its integrated DOS, which itself is a bad choice  
for other reasons.)

 DOS, however, allows external file system drivers to (relatively  
 speaking)
 easily integrate into the kernel as redirectors. (As mentioned, a
 consistent LFN extension has not yet been defined for the redirector
 interface.) The roots of this go back to MS-DOS 3.x and the redirector
 interface has been used (provided) ever since by various networking
 clients as well as *CDEX programs, as well as more 'exotic' file system
 drivers.

 But you can't use the redirector interface really for any file system
 running on DOS itself,

Depends on your definitions.

If you mean local (on that same machine, and running on that DOS): The  
file systems of a *CDEX driver are local, and eg iHPFS also accesses  
local file systems from hard disk partitions.

 not to mention that on the receiving end
 (DOS), you still have all the inherited limitation of DOS. Different
 character representations are just a start here (256/512 bytes code
 pages compared to UTF8/16/etc)...

Yes, no one doubted that these restrictions are still carried along  
(specifically those concerning naming).

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] BtrFS filesystem in FreeDOS

[C. Masloch]

 what are the chances of seeing a FreeDOS driver for the BtrFS
 filesystem anytime soon?

I don't think it will happen.

 As many of you may already know, BtrFS is poised to become the next
 Linux standard filesystem very soon, replacing the ext family of
 filesystems.

I don't even know of any recent FreeDOS development on any extFS drivers.  
The following lists two projects allowing some ext2/3 access via command  
line tools (not actual file system integration!):  
http://tldp.org/HOWTO/Filesystems-HOWTO-6.html

 BtrFS is really good, and is getting better and better.

 It would be really, really nice to have a FreeDOS driver for it, so at
 the very least we would be able to access BtrFS volumes (for instance,
 for maintenance and repair).

(Free)DOS isn't particularly well-suited for this, because its (current)  
high-level file system API doesn't even have concepts such as unix-like  
permissions or owners or hard links or soft links or ACLs or extended  
attributes etc.

Additionally, it wants all files to have short names (which naturally  
aren't available on ext or BtrFS) and expects these short names to be  
stored in all-caps and there is hardly any international character set  
support. These name/path restrictions are partially lifted by the LFN API  
(which the FreeDOS kernel doesn't support natively) but intercepting and  
handling LFN API calls in a DOS redirector file system driver is rather  
complicated (because the regular redirector interface only supports the  
SFN API).

If a driver shows some or all files and directories only on the LFN API,  
LFN-unaware programs won't be able to access these files and directories.  
Hence, typically DOS redirector file system drivers for file systems  
without short names dynamically invent short names on their own, hopefully  
without conflicts. (SHSUCDEX apparently does this, but this might be more  
difficult to achieve well in a read-write driver.)

And then, of course, regular 86 DOS software is restricted to just under  
1088 KiB of directly addressable memory. This could probably be lifted by  
developing the driver as resident DPMI client, or DPMS client, or JLM, or  
(maybe) employing VCPI.

 Is anyone planning to work on it?

Very unlikely.

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] BtrFS filesystem in FreeDOS

[C. Masloch]

 I think the big limitation will be addressable filesystem space. Btrfs
 can support 2^64 files, and 16EB volumes. That's a wee bit too much
 for DOS to handle.

 Even if you have a Btrfs that's fairly small, say small enough to be
 addressable by DOS,

Assuming the driver has enough space for its internal tables, the  
redirector file system interface has no direct restrictions on the number  
of files, or on low-level details of a file system such as how many  
'sectors' or 'clusters' or 'blocks' of whatever size it has.

However, the regular SFT implementation allows only up to 255  
simultaneously opened file handles (including the three handles typically  
referring to CON, AUX, and PRN for the first five 'std' handles).  
Additionally, file sizes are limited to 4 GiB (or only 2 GiB even, in some  
implementations) unless SFTs and APIs are extended to eg 64-bit seek  
offsets (as implemented by EDR-DOS). Like LFNs, the 64-bit seek offsets  
are not supported on the regular redirector interface, so a file system  
driver would have to work around that additionally (similar to providing  
LFNs manually), or extensions to that interface are necessary as well. (I  
don't think EDR-DOS defines such an extension as of yet?)

 you have the long filename problem.

Yes, as mentioned.

 DOSEmu presents a local Linux folder as a drive to FreeDOS, using
 long-to-short filename conversion. So I can see these files in
 FreeDOS, but they have different names:

 DEARG~10.-ME
 DEARG~LC.-ME

Oh, doesn't its redirector driver provide long names on the LFN API?

 So you can do it, but the challenge is making these files addressable
 by DOS in short namespace, in a user-accessible way.

Yes, as I hinted at, it is particularly difficult because it doesn't  
suffice to just dynamically shorten each name _individually_ as then the  
same short name alias might be invented twice in the same directory. Such  
conflicts must be avoided; otherwise (at best) the duplicate name will  
actually access only one of the files.

Regards,
Chris

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] [Freedos-user] writing a loadable block driver for 4k-sector drive (Questions)

[C. Masloch]

 it would be one of the best ways, to get panasonic USBASPI.SYS 2.27  
 (only!)
   and matsushita  
 DI1000DD.SYS (motto hairu)
 going on a usb drive, say a 1/2 terabyte one, like i've got,
 then adapt everything over to the 4k-sector standard with
 the equivalent of a usb protocol analyzer,
 like adaptec would...
[...]
have you tried to read/write with these files, with no adapter?
  DEVLOAD /H FULL-PATH-ONLY(!)\USBASPI.SYS /W /V
 DEVLOAD /H FULL-PATH-ONLY(!)\DI1000DD.SYS

 this works well on what i've got,
 and it shouldn't be difficult to find someone all to kick the design  
 over to 4k.
  all it needs is a usb 4k file system driver with fallback to the  
 lesser-length blocks.

You either lack understanding of the involved request and issues, or your  
writing lacks in showing your understanding.

 if you need these two files, earlier versions that work fine but  
 recognize hardware slower
 are on wengier's super ms-dos 7.10 boot diskette, available here and  
 there on the internet.

Do not advertise unauthorised distribution of copyrighted material here. I  
am quite certain that downloads containing MS-DOS 7.10 cannot legally be  
used unless one owns one of the associated MSW versions anyhow.

Additionally, please do not include full copies of mails you are answering  
below your reply's actual text.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] [Freedos-user] writing a loadable block driver for 4k-sector drive (Questions)

[C. Masloch]

 You and Eric are discussing it in general technical terms, i.e., not  
 talking about what the downward side is (ASPI, INT 13h, a shim  
 between a non-compliant kernel and a device driver, etc.).  Bertho is  
 talking about a specific (USB)ASPI implementation.

Oh? I wasn't aware. I was assuming everyone thought of the lower interface  
as to a block device driver that presents 4 KiB sectors.

regards,
C. Masloch

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] [Freedos-user] writing a loadable block driver for 4k-sector drive (Questions)

[C. Masloch]

 Another additional note, as I went thinking about this a bit. Only  
 cluster values are stored in the FS (think FAT contents, FSINFO, and  
 start cluster fields of directory entries) apart from what is in the  
 *BPB, so a runtime upwards sector size transformation (say, from 512 B  
 to 4 KiB, or  from 128 B to 512 B, or whatever) is still possible, just  
 more complicated. I'm not certain, but my intuition is that it'd still  
 be rather trivial to do.

missed mentioning one condition: cluster size must be large enough

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Source Code Released: 386SWAT, QLINK, and DPMIONE

[C. Masloch]

thanks

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Calling interrupts when iddle

[C. Masloch]

Refer to a forum posting I made regarding this:

http://www.bttr-software.de/forum/forum_entry.php?id=10397

It discusses idling via Int28, Int2F.1680, and by issuing hlt  
instructions. As explained I only use the latter two.

Regards,

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Calling interrupts when iddle

[C. Masloch]

 (1) I'm talking about pure realmode, so 2Fh 1680h is what I need.

Yes, as I mentioned, if you're in real or V86 mode (not protected mode)  
then attempting 2F.1680 via 31.0300 is of course impossible and not  
necessary.

 (2) HLT could be another option, but it is not what I am looking for,
 as I would like to let others (TSRs in the same machine, i.e. 28H) or
 the VM that exists outside me (2Fh 1680h) to spend a bit of time doing
 their things, but I don't want to halt.

What if no waiting TSRs and no other VMs exist? Halting is then best.

 (3) Int 2Ah , AH=84h  is never mentioned. Curiously enough, it is in
 EDIT sources, and I think introduced by Eric, who also wrote APMDOS,
 so I'm sure he can extend a bit more on this too.

Yes, as I said, it isn't mentioned. I haven't looked into it much yet. It  
seems to miss an installation check but you could probably call it  
alongside other idling.

 (4) I am not convinced that I should NOT call int 28h. If I am not
 doing DOS calls where DOS iddles, and if I don't call 28h, then the
 TSRs that rely on this call won't work.

That's possible.

Regards,

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] How does the boot sector know the partition start

[C. Masloch]

Hi,

This doesn't seem to have received any answers yet.

 I see the MBR code essentially loads the boot sector of the active
 partition and puts it at address :7c00. Then the boot code is
 executed by jumping to that address.

This is correct.

 1. INT 0x13 with AH=0x42 does extended read operation. But what if the  
 BIOS is old? Will it do nothing and set an error flag in CF?

Yes, BIOSes not supporting (LBA) extended functions should flag an error.
However, the boot sector or MBR can/should test whether the BIOS supports
(LBA) extended functions via the detection function first. That's 13.40 or
something, look it up in your reference. As opposed to only checking CF,
you should check for both NC and the signature value (in bx I believe) to
verify that the detection function is supported.

MBRs and boot sectors depending on LBA support are easier to write;
specifically as you do not have to write handling for two interfaces and
as calculating CHS addresses from linear sector numbers is then
unnecessary. (LBA addresses are the same as linear sector numbers.)
(Getting rid of the LBA support and always using the CHS interface is a
bad idea though, because CHS is limited to the first 8 GiB or so of the
disk.)

 2. Compared to the MBR, does the boot sector also contain partition  
 location
 information? I searched the Web and looked at some pages about it, but
 didn't find any. Then, how does it call INT 13 and boot the kernel? Maybe
 I'm not understanding this correctly, so please correct me if I'm wrong.

This is how it's usually done for FAT partitions, yes. In the FAT BIOS
Parameter Block (BPB, it contains informations about the file system)
there is one field often called hidden sectors. This is simply the
number of sectors on the disk that are in front of the boot sector; in
other words, the (LBA) address of this partition.

This information is virtually useless: if you know where you read the
sector from, you shouldn't need that information in the sector itself.
However, as you must have noticed, there is no interface for how to pass
the sector address from the MBR code to the boot sector code, so this
field is necessary as it isn't communicated to the boot sector code.

Knowledge of the file system can be read and calculated from the BPB,
including the position of the FATs, the root directory (FAT12/16 special
area or FAT32 cluster) and the data area. The boot sector code parses as
much of that as necessary, then scans through the root directory. (Some
loaders expect the first root directory entry to be the one for their
kernel.) The loader then reads either the first few sectors of the
first/only kernel file or that entire file. (In the former case, the first
few sectors contain a more advanced file system driver.) On FAT32, some
systems use secondary boot code sectors behind the first one to store more
code. (This is similar to the loading scheme which stores a more advanced
driver at the beginning of the kernel file.)

Regards,

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel