When using int2f/0x4a02 to get an HMA block the requested size is not rounded up with respect to paragraph, as it is on MS-DOS 6.22/7.0/7.1. This was recently fixed in FDPP dosemu2/fdpp@e7fe81d
See https://github.com/dosemu2/dosemu2/blob/7454efb873977214cd8605380954a4cc86a53441/test/func_memory_hma.py#L61 for an example test, where the requested size is 35 bytes, and the expectation is 48 bytes.

I've been struggling to get Win3.x working on latest FreeDOS CI kernel but no avail.

I thought my configurations were wrong, only to realize that the CI artifacts were not actually built with -DWIN31SUPPORT.

I tried building one myself but still not successful, even using a Ubuntu 20.04 VM with just the necessary stuffs for vanilla.

With -DWIN31SUPPORT (XCPU=86 or XCPU=386 doesn't matter), the build process complained about things like undefined reference to _winInstanced", _winStartupInfo and _winPatchTable.

Does building such variants require a Windows machine? As for now they were only present in build.bat...

EDIT: It seems ALLCFLAGS only affects the C compiler and all nasm jobs are still being done without that flag. Will figure out a way to add it to see if it makes any difference...

While creating the PR #92 I noticed that SYS determines the FAT type by calculating the number of data clusters then dispatching on that. This is in

However, the kernel itself correctly uses just the zero/nonzero status of the BPB word giving the amount of sectors in a FAT:

The kernel is correct: FAT32 is determined solely by whether the BPB word is zero. This also means when calculating the cluster amount (only for dispatching FAT12 vs FAT16) it is correct to use the BPB word, not the EBPB dword, to calculate the space occupied by the FATs. SYS already does that correctly by chance, though it could be clearer about it. In

I am trying to use FreeDOS with RLoew's LIMITMEM.SYS to limit the available memory, for applications that have problems with it. For example, RAR for DOS throws an "out of memory" exception with an EMM manager loaded if there is too much system memory.

Using LIMITMEM.SYS with MS-DOS 7.1 works as expected. I see the samller amount of memory in MEM and RAR works fine. But with FreeDOS, the memory size doesn't change and RAR tells me that I'm out of memory.

http://lonecrusader.x10host.com/rloew/limitmem.html

If you start the game and it has demo files in its folder, then it will crash there saying something like File error #%d loading demo file header. with the %d replaced by actual error code.
In the Blood RE project, you can check the source: https://github.com/clipmove/DOSBlood/blob/a2682fe0b8ed122c803d12f9733637033ae3ac04/blood/src/demo.cpp#L349

If you delete the .dem files then the main menu will appear without text, you can start a new game by pressing enter multiple times.
Then the game will crash with: rc\asound.cpp(203): Missing sound #35 used in ambient sound generator 4.

The original DOS exe and the REd exe is showing the same error messages under FreeDOS. Both work fine on MS-DOS 6.22.

I created a FreeDOS bootable pendrive with Rufus 3.22 and tried from there.

I've just been testing FreeDOS current git with the Dosemu2 test suite and I can see that there's a problem with FCB rename when using wildcards. The test test_fat_fcb_rename_wild_1 and three others are failing due to a bug still present in FreeDOS, as I reported a similar one in FDPP here dosemu2/fdpp#44 which was subsequently fixed. That bug report contains a test binary that should help you to recreate.

I am able to use HIMEM.SYS with MS-DOS 7.1 without any problems. But when I try to use it with FreeDOS I get an error at startup:

ERROR: VDISK memory allocator already installed.
       XMS Driver not installed.

I am using FreeDOS 1.3, and DEVICE=HIMEM.SYS is the only thing in my CONFIG.SYS, with an empty AUTOEXEC.BAT file.

At some moment build script tries to run

cd ..\country && C:\WATCOM\BINW\WMAKE.EXE all

While double ampersands should work on modern Windows CMD, it won't work under MS-DOS and derivatives. So if you run the build under pure DOS (or DOSEmu2 as in my case), it will break at this point.

You can still enter the directory, run wmake and copy country.sys to ..\bin and rerun build and everything will work. But you can't get a clean build without any manual intervention.

I couldn't identify where is the offending code as it seems to be hidden behind variables.

There's an interesting article about how idle detection was supposed to work in DRDOS.

The relevant parent has expired, and this seems pretty efficient -

https://www.os2museum.com/wp/idle-dr-dos

GCC compiled 8086 kernel boots fine, while Watcom compiled 8086 kernel freezes after showing hard drive information and prior to FreeCom welcome message. Need to determine where in the boot process the memory is being corrupted. 386 builds not yet tested.

I described this problem in some detail in a blog post: https://pushbx.org/ecm/dokuwiki/blog/pushbx/2024/0204_various_freedos_boot_sector_loaders_memory_overlap_cases

Basically, the FAT sector at segment 2000h overlaps with part of the load file data if the file (rounded up to cluster size) exceeds 126.5 KiB. This is defined here in the CHS FAT32 loader:

Either the file data will overwrite the saved FAT sector, or a newly-read FAT sector will overwrite the file data. On drives with 128 KiB/cluster, the latter is more likely as the root scan is unlikely to read a second cluster. And if this happens and the actual file data is less than 126.5 KiB, then this bug is benign, the load will appear to just work. This explains why I didn't notice this bug before when I introduced support for 256 sectors/cluster to the loaders.

My suggestion is to change the FAT buffer to reside at segment 2200h:0 (linear 22000h, 136 KiB) instead, which allows to use /L load segments from 60h to 200h without the overlap occurring. The blog post also discusses how higher /L parameters to the FAT12/FAT16 loader may also cause an overlap; the solution is similarly to move up the cluster list to segmented 1FE0h:2200h (happens to also be linear 22000h, 136 KiB). I will prepare a Pull Request for these changes (and the corresponding updates to the memory layout maps) soon.

Trying to build in Debian. I get:
/bin/sh: 1: wmake: not found

I don't see wmake in utils. What am I missing?

If the kernel is compiled without FAT32 support, CLUSTER is defined as unsigned short.

But there are several printf format specifiers that treat this unconditionally as unsigned long, like here:

I have two problems with that:

1. The actual license is GNU GPL v2-or-later (ie, v2+) it appears. This is a corner case that can matter. (Note that the choice depends on the exact wording in the source files' header comments.)
2. The blurb lists only "GPL" without specifying "GNU". This does not matter much but could help people unaware of what the GPL is.

Now in russian version of FreeDOS incorrect displayed russian symbols due missing needed configuration. Can you please add to Freedos for russian version to autoexec.bat content of command setfont.bat from https://github.com/shidel/FDI/blob/master/LANGUAGE/RU/SETFONT.BAT

I'm seeing an odd effect with current GIT compiled with gcc-ia16-elf. If I use the int2f/1217 function to get a drive's CDS entry (from within a int2f/11 redirector call so I have a valid DOS stack) I get an incorrect value for the CDS returned. I also notice that the value never changes if a different drive is queried. I've pushed a test patch to https://github.com/andrewbird/fdkernel/tree/int2f-12-issue which makes it work for me. It seems normal that a (struct *) should be used for exchanging registers with the called function, but I can find no problem with the Watcom compiled FreeDOS 1.20 release which presumably uses the (struct).

These snippets of log from Dosemu2's redirector show the values returned by two differing
methods of obtaining CDS:
    The drive_cds() function returns the CDS by means of the int21/52 SYSVARS/LOL function.
    The GetCDSInDOS() function uses int2f/1217 (with DOS stack).
    
Previously with gcc-ia16-elf compiled git the return value would always be the same fixed
address:
    MFS: GetCDSInDOS for C:
    MFS: GetCDSInDOS ret 1:
    MFS: GetCDSInDOS CDS ptr is 0x0xb01e4000
    MFS: drive_cds ptr is       0x0xb017b640
    
    MFS: GetCDSInDOS for D:
    MFS: GetCDSInDOS ret 1:
    MFS: GetCDSInDOS CDS ptr is 0x0xb01e4000
    MFS: drive_cds ptr is       0x0xb017b698
    
With this patch the return values are identical:
    MFS: GetCDSInDOS for C:
    MFS: GetCDSInDOS ret 1:
    MFS: GetCDSInDOS CDS ptr is 0x0xb017b2f0
    MFS: drive_cds ptr is       0x0xb017b2f0
    
    MFS: GetCDSInDOS for D:
    MFS: GetCDSInDOS ret 1:
    MFS: GetCDSInDOS CDS ptr is 0x0xb017b348
    MFS: drive_cds ptr is       0x0xb017b348

How do i compile FreeDOS kernel?
There is lack of documetation. Could you help?

And it is unnecessary to create drivers, as Bret Johnson has them at bretjohnson.us.

This is the tail of the task.c DosExec call:

  rc = (int)DosRWSft(fd, sizeof(exe_header), (BYTE FAR *)&ExeHeader, XFR_READ);

  if (rc == sizeof(exe_header) &&
      (ExeHeader.exSignature == MAGIC || ExeHeader.exSignature == OLD_MAGIC))
  {
    rc = DosExeLoader(lp, &TempExeBlock, mode, fd);
  }
  else if (rc != 0)
  {
    rc = DosComLoader(lp, &TempExeBlock, mode, fd);
  }

  DosCloseSft(fd, FALSE);

  if (mode == LOAD && rc == SUCCESS)
    fmemcpy(ep, &TempExeBlock, sizeof(exec_blk));

  return rc;
}

This particular line is in error:

rc here holds the size of the attempted read of 1Ch bytes to determine whether the executable is in MZ .EXE format. So for 0-byte files rc is 0. That means in this case both DosExeLoader and DosComLoader are skipped. Then rc equal to zero is interpreted as SUCCESS.

The result is that the syscall returns success (NC, ax unchanged) to the int 21h caller. However, no new process is created and in the case of function 4B01h the cs:ip and ss:sp fields in the exec block are unchanged.

Expected behaviour, as tested on MS-DOS version 5: int 21h should returm CY, error code in ax equal to 000Bh. This is the corresponding internal error code in the kernel:

#define DE_INVLDFMT     -11     /* Invalid format               */

Debugging log: https://pushbx.org/ecm/test/20220505/fdbug.txt

This is the part that applies the patches to the standard boot sector loader:

For the OEM compatibility boot sector loader, no patches are applied. And that is true even though the LBA detection is very similar for the OEM loader, and could be patched similarly:

Having worked some on the kernel's exeflat I took on the challenge of undoing the compression that it orchestrates along with UPX. Here's the resulting program: https://hg.pushbx.org/ecm/fddepack/file/85a255f5048a/depack.c

As you can see it is a very basic program. It calls upx -d using a system call in C, the error handling is rudimentary, and it needs the output filename to end in .exe. Further, it only supports the MZ .EXE compression format for now. The resulting output file can be re-used as input to exeflat to recreate a bootable kernel (with or without UPX compression).

I checked with a kernel 2042 that I had around, the kernel 2036 from dosemu-freedos-1.0-bin.tgz, and the current git (with my exeflat update).

I think that the depacker might come in handy to appease the UPX usage conditions. If not under the GPL (which would require redistributing the corresponding source of UPX with any compressed kernel) they want us to not modify their depacker stub (what we technically do not do, just prepend our stub stub) and to allow anyone to depack compressed files. Even with this depacker we don't follow these requirements to the letter, but in spirit perhaps.

The check is in

A user reported in https://www.bttr-software.de/forum/forum_entry.php?id=21210 that it doesn't work on a NEC V20.

My implementation of a CPU check is either in https://hg.pushbx.org/ecm/ldebug/file/7f3440d5824d/source/init.asm#l3071 or in https://hg.pushbx.org/ecm/cpulevel/file/43b74982baeb/cpulevel.asm#l53

Hi,
How do i delete network and printer capabilities ?

Seeing how @frehwagen recently added watcom v2 build support to pcgeos, would something similar be suitable for FreeDOS kernel?

Reported by developer creating SSD utilities for DOS...

OS reports incorrect CHS size.

https://gitlab.com/FreeDOS/base/kernel/-/issues/2

Dosemu2's redirector makes use of int2f/1203 to find DOS's data segment. Unfortunately on GCC builds from git (and maybe Borland 3) this doesn't return a valid result, however the released kernels on FreeDOS 1.00/1.10/1.20 work fine in this regard. This leads to a failure to boot on Dosemu2 as it corrupts DOS memory whilst trying to initialise the redirector.

I've attached a simple binary that could be used to call the function, it should be run in a debugger to see the result as it doesn't print anything itself.

.text                                                                           
.code16                                                                         
                                                                                
    .globl  _start16                                                            
_start16:                                                                       
                                                                                
    push    %cs                                                                 
    pop     %ds                                                                 
                                                                                
    movw    $0x1203, %ax                                                        
    int     $0x2f                                                               
    nop                                                                         
                                                                                
exit:                                                                           
    movb    $0x4c, %ah                                                          
    int     $0x21                                                               

int2f12p.zip

This may be related to #3 which was never resolved.

Since you seem to be chasing down a few FreeDOS kernel bugs, you might be interested in this? I have a test in Dosemu2 that creates a new PSP. Historically the test has always passed on MS-DOS 6.22 and DR-DOS 7.01, FDPP was subsequently fixed, and FreeDOS is currently still broken. Here is a test run

ajb@polly:/clients/common/dosemu2.git$ test/test_dos.py test_create_new_psp
Test DR-DOS-7.01 Create New PSP                                                  ... ok (  2.53s)
Test FR-DOS-1.20 Create New PSP                                                  ... skipped 'known failure'
Test FR-DOS-GIT  Create New PSP                                                  ... FAIL
Test MS-DOS-6.22 Create New PSP                                                  ... ok (  2.20s)
Test PP-DOS-GIT  Create New PSP                                                  ... ok (  1.93s)

The test does this

"""
.text                                                                           
.code16                                                                         
                                                                                
    .globl  _start16                                                            
_start16:                                                                       
                                                                                
# designate target segment                                                      
    push    %%cs                                                                
    pop     %%ax                                                                
    addw    $0x0200, %%ax                                                       
    movw    %%ax, %%es                                                          
                                                                                
# create PSP in memory                                                          
    movw    %%es, %%dx                                                          
    movw    $0x2600, %%ax                                                       
    int     $0x21                                                               
                                                                                
# see if the exit field is set                                                  
    cmpw    $0x20cd, %%es:(0x0000)                                              
    jne     extfail                                                             
                                                                                
# see if the parent PSP is zero                                                 
    cmpw    $0x0000, %%es:(0x0016)                                              
    je      pntzero                                                             
                                                                                
# see if the parent PSP points to a PSP                                         
    push    %%es                                                                
    pushw   %%es:(0x0016)                                                       
    pop     %%es                                                                
    cmpw    $0x20cd, %%es:(0x0000)                                              
    pop     %%es                                                                
    jne     pntnpsp                                                             
                                                                                
# see if the 'INT 21,RETF' is there                                             
    cmpw    $0x21cd, %%es:(0x0050)                                              
    jne     int21ms                                                             
    cmpb    $0xcb, %%es:(0x0052)                                                
    jne     int21ms                                                             
                                                                                
# see if the cmdtail is there                                                   
    movzx   %%es:(0x0080), %%cx                                                 
    cmpw    $%d, %%cx                                                           
    jne     cmdlngth                                                            
                                                                                
    inc     %%cx                                                                
    mov     $cmdline, %%si                                                      
    mov     $0x0081, %%di                                                       
    cld                                                                         
    repe    cmpsb                                                               
    jne     cmdtail                                                             
                                                                                
success:                                                                        
    movw    $successmsg, %%dx                                                   
    jmp     exit                                                                
                                                                                
extfail:                                                                        
    movw    $extfailmsg, %%dx                                                   
    jmp     exit                                                                
                                                                                
pntzero:                                                                        
    movw    $pntzeromsg, %%dx                                                   
    jmp     exit                                                                
                                                                                
pntnpsp:                                                                        
    movw    $pntnpspmsg, %%dx                                                   
    jmp     exit                                                                
                                                                                
int21ms:                                                                        
    movw    $int21msmsg, %%dx                                                   
    jmp     exit                                                                
                                                                                
cmdlngth:                                                                       
    movw    $cmdlngthmsg, %%dx                                                  
    jmp     exit                                                                
                                                                                
cmdtail:                                                                        
    movw    $cmdtailmsg, %%dx                                                   
    jmp     exit                                                                
                                                                                
exit:                                                                           
    movb    $0x9, %%ah                                                          
    int     $0x21                                                               
                                                                                
    movb    $0x4c, %%ah                                                         
    int     $0x21                                                               

extfailmsg:                                                                     
    .ascii  "PSP exit field not set to CD20\r\n$"                               
                                                                                
pntzeromsg:                                                                     
    .ascii  "PSP parent is zero\r\n$"                                           
                                                                                
pntnpspmsg:                                                                     
    .ascii  "PSP parent doesn't point to a PSP\r\n$"                            
                                                                                
int21msmsg:                                                                     
    .ascii  "PSP is missing INT21, RETF\r\n$"                                   
                                                                                
cmdlngthmsg:                                                                    
    .ascii  "PSP has incorrect command length\r\n$"                             
                                                                                
cmdtailmsg:                                                                     
    .ascii  "PSP has incorrect command tail\r\n$"                               
                                                                                
successmsg:                                                                     
    .ascii  "PSP structure okay\r\n$"                                           
                                                                                
# 05 20 54 45 53 54 0d                                                          
cmdline:                                                                        
    .ascii " %s\r"                                                              
                                                                                
""" % (1 + len(cmdline), cmdline))

I've added the prebuilt binary and its gnu assembler source here create_new_psp.zip. You can run it with the testit.bat file

As you will see the error is PSP parent is zero

C:\>testit.bat
testit.bat

C:\>c:\getnwpsp COMMAND TAIL TEST
PSP parent is zero

Note: FreeDOS is tested here built using the gcc-elf-ia16 compiler, though I'm not sure if that is significant,

See dosemu2/fdpp#107 and apply similar fix. Realloc to 0 doesn't match ms/pc dos, psp corruption issue

The exeflat utility wrote a wrong kernel CONFIG block length of 19 when UPX compression was introduced. In this git repo the problem was corrected on 2012-10-15 in a260927#diff-2477748a9e5dedc77cffa1fc943860aa18c9fe23567aa2550c1f5c7e60bb8053L266

The same commit introduced a wrong fix to the problem:

  /* check if config settings old UPX header and adjust */
  if (cfg->ConfigSize == 19)
    cfg->ConfigSize = 14;  /* ignore 'nused87654321' */

The wrong header was introduced in https://hg.pushbx.org/ecm/fdkernel.svn/rev/af1dfee339ef#l65.109 on 2002-01-23, original SVN revision at https://sourceforge.net/p/freedos/svn/343/

In the SVN repo the header was fixed in https://hg.pushbx.org/ecm/fdkernel.svn/rev/977d55fa398a on 2016-02-06, original SVN revision at https://sourceforge.net/p/freedos/svn/1735/

I don't know the reasoning behind the initial error. However, all the wrong errors want to say 6, not 19 nor 14. 14 would be correct if you counted the CONFIG signature (6) + length field (2) + actual length of fields (6). The CONFIG block included in kernel.asm always got it right, and consistently does not count the signature nor the length field itself:

Hi,

How do I know which version of FreeDOS 1.3 to download : 8086+ or 386+ ?
I need the 8086+ version.

The Dosemu2 test suite is showing a problem regarding wildcards and FCB based file functions. The following code is used to print out the files found, but only returns one result when it should return multiple items.

        self.mkcom_with_gas(ename, r"""                                         
.text                                                                           
.code16                                                                         
                                                                                
    .globl  _start16                                                            
_start16:                                                                       
                                                                                
    push    %%cs                                                                
    pop     %%ds                                                                
                                                                                
    # Get DTA -> ES:BX                                                          
    movw    $0x2f00, %%ax                                                       
    int     $0x21                                                               
    pushw   %%es                                                                
    pushw   %%bx                                                                
    popl    pdta                                                                
                                                                                
    # FindFirst                                                                 
findfirst:                                                                      
    movw    $0x1100, %%ax                                                       
    movw    $fcb, %%dx                                                          
    int     $0x21                                                               
                                                                                
    cmpb    $0, %%al                                                            
    je      prsucc                                                              
                                                                                
prfail:                                                                         
    movw    $failmsg, %%dx                                                      
    movb    $0x9, %%ah                                                          
    int     $0x21                                                               
    jmp     exit                                                                
                                                                                
prsucc:                                                                         
    movw    $succmsg, %%dx                                                      
    movb    $0x9, %%ah                                                          
    int     $0x21                                                               
                                                                                
prfilename:                                                                     
    push    %%ds                                                                
    lds     pdta, %%si                                                          
    inc     %%si                                                                
                                                                                
    push    %%cs                                                                
    pop     %%es                                                                
    movw    $prires, %%di                                                       
    inc     %%di                                                                
                                                                                
    movw    $11, %%cx                                                           
    cld                                                                         
    repne   movsb                                                               
                                                                                
    pop     %%ds                                                                
    movw    $prires, %%dx                                                       
    movb    $0x9, %%ah                                                          
    int     $0x21                                                               
                                                                                
    # FindNext                                                                  
findnext:                                                                       
    movw    $0x1200, %%ax                                                       
    movw    $fcb, %%dx                                                          
    int     $0x21                                                               
                                                                                
    cmpb    $0, %%al                                                            
    je      prfilename                                                          
                                                                                
exit:                                                                           
    movb    $0x4c, %%ah                                                         
    int     $0x21                                                               
                                                                                
fcb:                                                                            
    .byte   0       # 0 default drive                                           
fn1:                                                                            
    .ascii  "% -8s"    # 8 bytes                                                
fe1:                                                                            
    .ascii  "% -3s"    # 3 bytes                                                
wk1:                                                                            
    .space  25                                                                  
                                                                                
pdta:                                                                           
    .long   0                                                                   
                                                                                
prires:                                                                         
    .ascii  "("                                                                 
fname:                                                                          
    .space  8, 20                                                               
fext:                                                                           
    .space  3, 20                                                               
    .ascii  ")\r\n$"                                                            
                                                                                
succmsg:                                                                        
    .ascii  "Find Operation Success\r\n$"                                       
failmsg:                                                                        
    .ascii  "Find Operation Failed\r\n$"                                        
                                                                                
""" % (fn1, fe1))                                                               

FreeDOS git master

C:\>testit.bat^M                                                                
testit.bat^M                                                                    
C:\>d:^M                                                                        
D:\>c:\fcbfind3^M                                                               
Find Operation Success^M                                                        
(THREE   IN )^M                                                                 
D:\>DIR^M                                                                       
 Volume in drive D has no label^M                                               
 Volume Serial Number is 1234-5678^M                                            
 Directory of D:\^M                                                             
^M                                                                              
THREE    IN              7  07-28-21  6:56p^M                                   
TWO      IN              7  07-28-21  6:56p^M                                   
FIVE     IN              7  07-28-21  6:56p^M                                   
NONE     CTL             7  07-28-21  6:56p^M                                   
ONE      IN              7  07-28-21  6:56p^M                                   
FOUR     IN              7  07-28-21  6:56p^M                                   
         6 file(s)             42 bytes^M                                       
         0 dir(s)      10,592,256 bytes free^M                                  
D:\>rem end^M                                                                   

MS-DOS 6.22

C:\>testit.bat^M                                                                
testit.bat^M^M                                                                  
^M                                                                              
C:\>d:^M                                                                        
^M                                                                              
D:\>c:\fcbfind3^M                                                               
Find Operation Success^M                                                        
(THREE   IN )^M                                                                 
(TWO     IN )^M                                                                 
(FIVE    IN )^M                                                                 
(ONE     IN )^M                                                                 
(FOUR    IN )^M                                                                 
^M                                                                              
D:\>DIR^M                                                                       
^M                                                                              
 Volume in drive D has no label^M                                               
 Volume Serial Number is 1234-5678^M                                            
 Directory of D:\^M                                                             
^M                                                                              
THREE    IN              7 07-28-21   7:09p^M                                   
TWO      IN              7 07-28-21   7:09p^M                                   
FIVE     IN              7 07-28-21   7:09p^M                                   
NONE     CTL             7 07-28-21   7:09p^M                                   
ONE      IN              7 07-28-21   7:09p^M                                   
FOUR     IN              7 07-28-21   7:09p^M                                   
        6 file(s)             42 bytes^M                                        
                      10,592,256 bytes free^M                                   
^M                                                                              

I've attached a minimal test case here fat_fcb_find_wild_1.zip

I seem to remember a similar bug being fixed on FDPP, but I can't find the issue in the tracker, although I think the code has diverged in that area quite a lot so I doubt there's any commit that can directly apply.

Look, difficult, I don't know how they managed to compile this, someone changed the code to be able to compile with OpenWatcom, I'm getting compilation errors in sys.c and dsk.c for now, it doesn't come out of it. They are actually alerts that are not letting it compile. If anyone can test or compare the previous files to see what was removed I would appreciate it. One of the most famous compilers of the DOS Watcom era, if not the best, being left for last, it is easy to configure to be able to compile with nasm and watcom.

:-

:-****************************************************************
:- NOTICE! You must edit and rename this file to CONFIG.BAT! *
:-****************************************************************

:-*********************************************************************

:-**********************************************************************
:-- define NASM executable - remember - it should not be protected
:- mode DJGPP version if you're using Windows NT/2k/XP to compile
:- because DJGPP-nasm crashes when using protected mode Borland's
:- make under Windows NT/2k/XP
:-**********************************************************************

set XNASM=nasm

:**********************************************************************
:- define your COMPILER type here, pick one of them
:**********************************************************************

:- Turbo C 2.01
:- set COMPILER=TC2
:- Turbo C++ 1.01
:- set COMPILER=TURBOCPP
:- Turbo C 3.0
:- set COMPILER=TC3
:- Borland C 3.1
:- set COMPILER=BC3
:- Borland C
:- set COMPILER=BC5
:- Microsoft C
:- set COMPILER=MSCL8
:- Watcom C
set COMPILER=WATCOM

:-**********************************************************************
:-- where is the BASE dir of your compiler(s) ??
:-**********************************************************************

:- set TC2_BASE=c:\tc201
:- set TP1_BASE=c:\tcpp
:- set TC3_BASE=c:\tc3
:- set BC3_BASE=c:\bc
:- set BC5_BASE=c:\bc5
:- set MS_BASE=c:\msvc

:- if WATCOM maybe you need to set your WATCOM environment variables
:- and path
:- if not %WATCOM% == \ goto watcom_defined
:- set WATCOM=c:\watcom
set PATH=%PATH%;%WATCOM%\binw
:watcom_defined

:-**********************************************************************
:- where is UPX and which options to use?
:-**********************************************************************
SET XUPX=

:- set XUPX=upx --8086 --best
:- or use set XUPX=
:- if you don't want to use it

:-**********************************************************************
:- (optionally) which linker to use:

:- Turbo Link
:- set XLINK=tlink /m/c/s/l
:- Microsoft Link
:- set XLINK=d:\qb\link /ma
:- set XLINK=%MS_BASE%\bin\link /ONERROR:NOEXE /ma /nologo
:- WATCOM Link (wlinker is a batch file calling ms2wlink and wlink)
set XLINK=..\utils\wlinker /ma /nologo

:- set path for Turbo Link - use OLDPATH to restore normal path
:- set OLDPATH=%PATH%
:- set PATH=%PATH%;%TC2_BASE%

:**********************************************************************
:* optionally define your MAKE type here, if not then
:* it will be automatically determined, pick one of them
:* use MS nmake if you want to compile with MSCL
:**********************************************************************

:- Borland MAKE
:- set MAKE=%TC2_BASE%\make
:- Watcom MAKE in MS mode
set MAKE=%WATCOM%\binw\wmake /ms
:- Microsoft MAKE
:- set MAKE=%MS_BASE%\bin\nmake /nologo

:**********************************************************************
:* select your default target: required CPU and what FAT system to support
:**********************************************************************

SET XCPU=86
:- set XCPU=86
:- set XCPU=186
:- set XCPU=386

SET XFAT=32
:- set XFAT=16
:- set XFAT=32

:- Give extra compiler DEFINE flags here
:- such as -DDEBUG : extra DEBUG output
:- -DDOSEMU : printf output goes to dosemu log
:- set ALLCFLAGS=-DDEBUG

:-

Watcom and Nasm must be in the default drive C:\ try to reproduce and you will see the error, this does not occur in 2042...

Oh, don't forget to declare the path of nasm in autoexec.bat or fdauto.bat:

SET PATH=C:\WATCOM\BINW;%dosdir%\BIN;\DJGPP\BIN;\NASM;

and for watcom add this

SET DJGPP=C:\DJGPP\DJGPP.ENV
SET INCLUDE=C:\WATCOM\H
SET WATCOM=C:\WATCOM
SET EDPATH=C:\WATCOM\EDDAT
SET WWINHELP=C:\WATCOM\BINW
SET WIPFC=C:\WATCOM\WIPFC

To compile on a real machine you must be using the base install of freedos that comes with all the base components.
Please help, for one person it is difficult.

I am able to use EMM386 with MS-DOS 7.1 without any problems, with HIMEM.SYS or HIMEMX.EXE. But when I try to use it with FreeDOS I get an error at startup:

EMM386 not installed - incorrect machine type

Press any key when ready...

When I press a key, I get a list of invalid opcodes.

I am using FreeDOS 1.3, and DEVICE=HIMEMX.EXE and DEVICE=EMM386.EXE are the only things in my CONFIG.SYS, with an empty AUTOEXEC.BAT file.

Whether Freedos support exfat in the future ?

During my work on Enhanced DR-DOS's early boot stages I noticed that the EDR-DOS-specific load protocol expects the ROM-BIOS (int 13h) load unit in DL whereas FreeDOS load expects it in BL.

Studying the sources of the patched FreeDOS SYS delivered as EDR-DOS SYS v3.5 (source archive mirrored here), including their boot sector loaders, I found that the two different FAT32 loaders both were patched to set DL, instead of setting BL.

(The common part of the FreeDOS and EDR-DOS boot sector loader for FAT12/FAT16 sets both registers, exempting it from this bug.)

The upshot is that when installing a FAT32 boot sector loader using the FreeDOS SYS build and using the /OEM:EDR switch the loader will still set BL and generally not set DL correctly, breaking the load protocol expected by the older EDR-DOS kernels (corresponding to my 2023 August revision and earlier).

The same is true inversely: Installing a FAT32 loader using the EDR-DOS SYS build and using the /OEM:FD switch will lead to the loader not correctly setting BL.

This problem does not affect the lDOS iniload or lDOS drload stages as these never use the load unit passed in a register, opting to read it from the boot sector's BPB New field for the load unit instead. The 2023 December build of my EDR-DOS repo uses one of these lDOS stages as the first stage after the sector loader so they aren't affected by being loaded with the wrong load unit register.

SYS doesn't track which load unit register to use (for the FAT32 FreeDOS-native loaders):

The FreeDOS-native FAT12/FAT16 loaders set both registers:

The FAT32 CHS 8086 loader sets BL only, patched for EDR SYS to DL only:

Same for the FAT32 LBA 386 loader:

have the project considered port to other architecture?

Motorola 68K 010, 020, 030, 040, 060, 080
big.endian,
Amiga500-2000,3k,4k, AtariST, Apple McIntosh
https://youtu.be/oyR-2HlAkv4?t=448 "pc-speed"
https://www.youtube.com/results?search_query=amiga+ms-dos
https://www.youtube.com/hashtag/doscember
https://www.youtube.com/hashtag/doscember2021

FPGA
https://www.minimig.ca/
https://lotharek.pl/productdetail.php?id=45
https://www.shop.apollo-computer.com/products/apollo-firebird-v4
https://www.shop.apollo-computer.com/products/real-time-clock-module-ds3231
PiStorm32 "Pi4 M68K emulation"

Armv8 ?
Pi4
Odroid N2+

PowerPC 970? "5+" Altivec
PowerMac G5 2003-2005
G4
G3

PowerPC 9 ?
https://www.raptorcs.com/content/base/products.html

PPC 5
SAM460 https://shop.acube-systems.biz/sam-motherboards/124-sam460.html
Amiga X5000 A-EON

Hi,
I was browsing through the source code and noticed that an error kept popping up that the error code SUCCESS was not defined

Hi @PerditionC I hope you don't think this is impertinent, but I'm thinking that it's probably time to ask https://support.github.com/contact?tags=rr-forks about making this project a stand-alone (in Github view) project rather than a child fork of https://github.com/PerditionC/fdkernel. I'm sure then it will become obvious to potential contributors which one is the primary fork to submit patches and issues to. I'm not sure if they can make the perditionc one a child of fdos, which I suppose would be ideal. I don't expect they will have any problem with your request as you own both the personal account and the FDOS team.

I assume this crash was introduced by ee255d2

I tested that the kernel still did build with gcc, but I failed to test whether it also still runs. Turns out that apparently changing the pointers to static made it so gcc put the structure into the init data segment and implicitly called memcpy to put it on the stack. That's wrong, however. We depend on #define to convert all calls in init to the init text copies of memcpy etc. The implicit call by gcc however attempts to call the HMA text copy of memcpy which happens to be at another offset.

Sorry for this headache! I will test a fix soon.

With a file named 4debug.com on the boot drive and shell=4debug.com in the fdconfig.sys file, the following interaction happens at boot time:

Bad or missing Command Interpreter: debug.com
Enter the full shell command line: 4debug.com
-

As seen, entering the full filename including the leading digit does allow to load the shell. But the kernel first tries to load the shell with the digit stripped. Using a name like ldebug.com without the leading digit works as expected.

If I recall, this was first reported on one of the mailing lists by a user trying to load 4DOS. I can't look that up right now however.

I suspect that the digit is read or discarded like a menu selector digit. I have not studied this in detail however. It doesn't explain why the shell= line does take effect even though it processes the 4 however.

I had a problem creating a FAT32 DPB from a BPB (int 0x21 ah=0x53). The issue is in reading the FS Information Sector, which requires a valid DPB. But there is no DPB, that's what I want to create. I ended up creating the DPB without the info sector, then restoring it and creating the DPB again.

With the changes in 9b6a857 the gcc/Linux host build no longer succeeds in building country.sys. One problem is that make expects a tab but this commit used 8 blanks:

cp sys.com ../bin
make[1]: Leaving directory '[...]/kmak/sys'
cd kernel && make production
make[1]: Entering directory '[...]/kmak/kernel'
GNUmakefile:47: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.
make[1]: Leaving directory '[...]/kmak/kernel'
make: *** [makefile:117: all] Error 2
$

Even fixing that we get another error during make:

cp kernel.map ../bin/KGC8632.map
cd ../country
make all
make[2]: Entering directory '[...]/kmak/kernel'
make[2]: *** No rule to make target 'all'.  Stop.
make[2]: Leaving directory '[...]/kmak/kernel'
make[1]: *** [GNUmakefile:47: ../bin/country.sys] Error 2
make[1]: Leaving directory '[...]/kmak/kernel'
make: *** [makefile:117: all] Error 2

http://kernel.fdos.org/ lists two links at the top, "Download .zip" and "Download .tar.gz". These lead to
https://github.com/FDOS/kernel/zipball/master respectively https://github.com/FDOS/kernel/tarball/master

Later on the page it lists:

Contents of zip files: ke20xx_16.zip : binaries for 8086, FAT16 ke20xx_32.zip : binaries for 8086, FAT16, FAT32 ke20xxsrc.zip : sources for the kernel

However, the zipball/tarball archives do not seem to contain the compiled binaries, only the source image as of the most recent commit. So there is no release archive available any more. (I went to http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/2042/ instead.)

I set up two tests of the FCB FindFirst/FindNext functions on a FAT32 FS hard disk image. All tests are run with qemu, version QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-11+deb11u2). The first two test runs were on a current revision of Enhanced DR-DOS, while the latter two test runs were on the FreeDOS kernel.

All files can be found in https://pushbx.org/ecm/test/20230821/

These are the commands used to create the disk images: https://pushbx.org/ecm/test/20230821/commands.txt Reproduced here:

nasm -I ~/proj/lmacros/ ~/proj/bootimg/bootimg.asm \
  -D_BPE=32 -D_SPI=65536+2048 -D_MBR -D_ALIGNDATA \
  -D_PAYLOADFILE="::fill,512*65536,0,'zeroes.bin',::chdir,'test',::fill,1,0,'a',::fill,1,0,'b',::fill,1,0,'c',::chdir,..,'testnorm.com','testexte.com'" \
  -D_SPF=640 -o testfcb.img -D_CHS_HEADS=16 -D_CHS_SECTORS=32 -D_MEDIAID=0F8h


DOSEMU=~/local.new/bin/dosemu

nasm ../bootimg/bootimg.asm -I ../lmacros/ -I ~/.dosemu/drive_c/ \
  -I ../ldebug/bin/ -o diskfd.img \
  -D_PAYLOADFILE=kernel.sys,command.com,fdconfig.sys,fdautoex.bat,ldebug.sld,himemx.exe,ldebug.com,::rename,ldebug.sld,lcdebug.sld,lcdebug.com,sys.com,quit.com,int3.com,int19.com,callver.com,ldebugx.com \
  && "$DOSEMU" -I "floppy { device diskfd.img }" \
  -E "a:sys A: /bootonly /oem:fd" -dumb -td -kt \
  && qemu-system-i386 -fda diskfd.img -boot order=a -display curses \
  -chardev serial,id=serial2,path=/tmp/vptty-dos -serial null \
  -serial chardev:serial2 -hda testfcb.img; stty sane

nasm ../bootimg/bootimg.asm -I ../lmacros/ -I ../edrdos/edrsys/ \
  -I ../edrdos/repo/drbio/bin/ -I ../edrdos/repo/drdos/bin/ \
  -I ../edrdos/repo/command/bin/ -I ../ldebug/bin/ -o diskedr.img \
  -D_PAYLOADFILE=drbio.sys,drdos.sys,command.com,dconfig.sys,drautoex.bat,ldebug.sld,himemx.exe,ldebug.com,::rename,ldebug.sld,lcdebug.sld,lcdebug.com,SYS.COM,quit.com,int3.com,int19.com,callver.com,ldebugx.com \
  && "$DOSEMU" -I "floppy { device diskedr.img }" \
  -E "a:sys A: /bootonly /oem:edr" -dumb -td -kt \
  && qemu-system-i386 -fda diskedr.img -boot order=a -display curses \
  -chardev serial,id=serial2,path=/tmp/vptty-dos -serial null \
  -serial chardev:serial2 -hda testfcb.img; stty sane


ldebug \testnorm.com

ldebug \testexte.com

install serial

re.append @if (word [cs:cip - 2] == 21CD) then d psp:80 l 28

These scriptlets use NASM, my macro collection, my FAT FS format script written in NASM, dosemu2 (only for running FreeDOS/EDR-DOS sys on the diskette image), qemu, lDebug, the EDR-DOS system build, and the FreeDOS kernel and FreeCOM build. Also included are HimemX and a number of smaller utilities, not needed for this test but used for prior tests. The test programs testnorm.com and testexte.com were created in the debugger so there's no source files corresponding to them.

The qemu serial ports are connected to a socat instance created using this command:

socat -r /tmp/trace.log pty,link=/tmp/vptty-dos,rawer pty,link=/tmp/vptty-linux,rawer & disown

Which in turn is connected to a picocom running like so:

picocom /tmp/vptty-linux

Each test was performed by running the DOS command ldebug \testXXXX.com then a debugger command install serial. On the serial terminal, a "KEEP" confirmation is entered and finally three commands to the debugger (visible in the serial port logs) that go like re.append @if (word [cs:cip - 2] == 21CD) then d psp:80 l 28 then tp FFFF then q. The RE buffer append command sets it up so that after tracing an interrupt 21h call (CD 21 opcode), the debugger will dump the DTA area at address PSP:80h. This allows it to automatically display what result a file search call yielded.

All tests are done by calling FCB FindFirst (function 11h) and FindNext (function 12h) with various states (\TEST directory or root directory, prior search call) as well as a search mask of eleven question marks. This is intended to match any directory entry. The testnorm.com test uses normal FCBs as the search/result structure, while testexte.com uses extended FCBs with the attribute 17h (directory, system, hidden, read-only).

I will not reproduce the full log here, but it is available on the server at https://pushbx.org/ecm/test/20230821/logs.txt

There are several differences:

This is the first result from EDR-DOS running testnorm.com, searching using a normal FCB in the \TEST subdirectory:

AX=0000 BX=0000 CX=0200 DX=0240 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2FB1 ES=2FB1 SS=2FB1 CS=2FB1 IP=0109 NV UP EI PL ZR NA PE NC
2FB1:0109 B82611            mov     ax, 1126
AX=1126 BX=0000 CX=0200 DX=0240 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2FB1 ES=2FB1 SS=2FB1 CS=2FB1 IP=010C NV UP EI PL ZR NA PE NC
2FB1:010C BA0002            mov     dx, 0200
AX=1126 BX=0000 CX=0200 DX=0200 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2FB1 ES=2FB1 SS=2FB1 CS=2FB1 IP=010F NV UP EI PL ZR NA PE NC
2FB1:010F CD21              int     21
AX=1100 BX=0000 CX=0200 DX=0200 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2FB1 ES=2FB1 SS=2FB1 CS=2FB1 IP=0111 NV UP EI PL ZR NA PE NC
2FB1:0111 84C0              test    al, al
2FB1:0080  03 41 20 20 20 20 20 20-20 20 20 20 00 00 00 00 .A          ....
2FB1:0090  00 00 00 00 00 01 00 00-00 00 00 04 00 01 00 00 ................
2FB1:00A0  00 00 00 00 00 00 00 00-                        ........

As you can see, the first returned result is one of the (1-byte) test files.

This is the corresponding FreeDOS test run:

AX=3B00 BX=0000 CX=0200 DX=0240 SP=FFFE BP=0000 SI=0000 DI=0000
DS=3168 ES=3168 SS=3168 CS=3168 IP=0109 NV UP EI PL ZR NA PE NC
3168:0109 B82611            mov     ax, 1126
AX=1126 BX=0000 CX=0200 DX=0240 SP=FFFE BP=0000 SI=0000 DI=0000
DS=3168 ES=3168 SS=3168 CS=3168 IP=010C NV UP EI PL ZR NA PE NC
3168:010C BA0002            mov     dx, 0200
AX=1126 BX=0000 CX=0200 DX=0200 SP=FFFE BP=0000 SI=0000 DI=0000
DS=3168 ES=3168 SS=3168 CS=3168 IP=010F NV UP EI PL ZR NA PE NC
3168:010F CD21              int     21
AX=1100 BX=0000 CX=0200 DX=0200 SP=FFFE BP=0000 SI=0000 DI=0000
DS=3168 ES=3168 SS=3168 CS=3168 IP=0111 NV UP EI PL ZR NA PE NC
3168:0111 84C0              test    al, al
3168:0080  03 2E 20 20 20 20 20 20-20 20 20 20 10 00 00 00 ..          ....
3168:0090  00 00 00 00 00 01 00 00-00 00 00 03 00 00 00 00 ................
3168:00A0  00 00 00 00 00 00 00 00-                        ........

This one returns the dot directory entry of the subdirectory. (Look for the 2Eh text byte at address 0081h in the dump.) Evidently, FreeDOS includes subdirectories in its normal FCB search while EDR-DOS does not. (I checked this assumption by doing some more test runs, not depicted in the log. Repeatedly having EDR-DOS search the root directory without an extended FCB does return ZEROES.BIN, TESTNORM.COM, and TESTEXTE.COM but not the TEST directory.)

The testexte.com test reveals that EDR-DOS is able to reconstruct the search DTA from the FCB passed to it, whereas FreeDOS is unable to do that. This is from the EDR-DOS run:

AX=0000 BX=0000 CX=0200 DX=0250 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2FB1 ES=2FB1 SS=2FB1 CS=2FB1 IP=0130 NV UP EI PL ZR NA PE NC
2FB1:0130 B82611            mov     ax, 1126
AX=1126 BX=0000 CX=0200 DX=0250 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2FB1 ES=2FB1 SS=2FB1 CS=2FB1 IP=0133 NV UP EI PL ZR NA PE NC
2FB1:0133 BA8002            mov     dx, 0280
AX=1126 BX=0000 CX=0200 DX=0280 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2FB1 ES=2FB1 SS=2FB1 CS=2FB1 IP=0136 NV UP EI PL ZR NA PE NC
2FB1:0136 CD21              int     21
AX=1100 BX=0000 CX=0200 DX=0280 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2FB1 ES=2FB1 SS=2FB1 CS=2FB1 IP=0138 NV UP EI PL ZR NA PE NC
2FB1:0138 84C0              test    al, al
2FB1:0080  FF 00 00 00 00 00 17 03-5A 45 52 4F 45 53 20 20 ........ZEROES
2FB1:0090  42 49 4E 00 00 00 00 00-00 00 00 00 00 00 00 00 BIN.............
2FB1:00A0  00 00 03 00 00 00 00 02-                        ........
AX=1100 BX=0000 CX=0200 DX=0280 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2FB1 ES=2FB1 SS=2FB1 CS=2FB1 IP=013A NV UP EI PL ZR NA PE NC
2FB1:013A 7544              jnz     0180                            not jumping
AX=1100 BX=0000 CX=0200 DX=0280 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2FB1 ES=2FB1 SS=2FB1 CS=2FB1 IP=013C NV UP EI PL ZR NA PE NC
2FB1:013C B82612            mov     ax, 1226
AX=1226 BX=0000 CX=0200 DX=0280 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2FB1 ES=2FB1 SS=2FB1 CS=2FB1 IP=013F NV UP EI PL ZR NA PE NC
2FB1:013F BA0002            mov     dx, 0200
AX=1226 BX=0000 CX=0200 DX=0200 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2FB1 ES=2FB1 SS=2FB1 CS=2FB1 IP=0142 NV UP EI PL ZR NA PE NC
2FB1:0142 CD21              int     21
AX=1200 BX=0000 CX=0200 DX=0200 SP=FFFE BP=0000 SI=0000 DI=0000
DS=2FB1 ES=2FB1 SS=2FB1 CS=2FB1 IP=0144 NV UP EI PL ZR NA PE NC
2FB1:0144 84C0              test    al, al
2FB1:0080  FF 00 00 00 00 00 17 03-42 20 20 20 20 20 20 20 ........B
2FB1:0090  20 20 20 00 00 00 00 00-00 00 00 00 01 00 00 00    .............
2FB1:00A0  00 00 05 00 01 00 00 00-                        ........

The second, interleaved search starts in the root directory and finds ZEROES.BIN. Then, the prior search (in the subdirectory) is resumed and finds B, the second non-dots directory entry. Thus, EDR-DOS succeeds in our test.

Next, consider the FreeDOS result of the same test:

AX=3B00 BX=0000 CX=0200 DX=0250 SP=FFFE BP=0000 SI=0000 DI=0000
DS=3168 ES=3168 SS=3168 CS=3168 IP=0130 NV UP EI PL ZR NA PE NC
3168:0130 B82611            mov     ax, 1126
AX=1126 BX=0000 CX=0200 DX=0250 SP=FFFE BP=0000 SI=0000 DI=0000
DS=3168 ES=3168 SS=3168 CS=3168 IP=0133 NV UP EI PL ZR NA PE NC
3168:0133 BA8002            mov     dx, 0280
AX=1126 BX=0000 CX=0200 DX=0280 SP=FFFE BP=0000 SI=0000 DI=0000
DS=3168 ES=3168 SS=3168 CS=3168 IP=0136 NV UP EI PL ZR NA PE NC
3168:0136 CD21              int     21
AX=1100 BX=0000 CX=0200 DX=0280 SP=FFFE BP=0000 SI=0000 DI=0000
DS=3168 ES=3168 SS=3168 CS=3168 IP=0138 NV UP EI PL ZR NA PE NC
3168:0138 84C0              test    al, al
3168:0080  FF 00 00 00 00 00 17 03-5A 45 52 4F 45 53 20 20 ........ZEROES
3168:0090  42 49 4E 00 00 00 00 00-00 00 00 00 00 00 00 00 BIN.............
3168:00A0  00 00 03 00 00 00 00 02-                        ........
AX=1100 BX=0000 CX=0200 DX=0280 SP=FFFE BP=0000 SI=0000 DI=0000
DS=3168 ES=3168 SS=3168 CS=3168 IP=013A NV UP EI PL ZR NA PE NC
3168:013A 7544              jnz     0180                            not jumping
AX=1100 BX=0000 CX=0200 DX=0280 SP=FFFE BP=0000 SI=0000 DI=0000
DS=3168 ES=3168 SS=3168 CS=3168 IP=013C NV UP EI PL ZR NA PE NC
3168:013C B82612            mov     ax, 1226
AX=1226 BX=0000 CX=0200 DX=0280 SP=FFFE BP=0000 SI=0000 DI=0000
DS=3168 ES=3168 SS=3168 CS=3168 IP=013F NV UP EI PL ZR NA PE NC
3168:013F BA0002            mov     dx, 0200
AX=1226 BX=0000 CX=0200 DX=0200 SP=FFFE BP=0000 SI=0000 DI=0000
DS=3168 ES=3168 SS=3168 CS=3168 IP=0142 NV UP EI PL ZR NA PE NC
3168:0142 CD21              int     21
AX=1200 BX=0000 CX=0200 DX=0200 SP=FFFE BP=0000 SI=0000 DI=0000
DS=3168 ES=3168 SS=3168 CS=3168 IP=0144 NV UP EI PL ZR NA PE NC
3168:0144 84C0              test    al, al
3168:0080  FF 00 00 00 00 00 17 03-54 45 53 54 20 20 20 20 ........TEST
3168:0090  20 20 20 10 00 00 00 00-00 00 00 00 01 00 00 00    .............
3168:00A0  00 00 03 00 00 00 00 00-                        ........
AX=1200 BX=0000 CX=0200 DX=0200 SP=FFFE BP=0000 SI=0000 DI=0000
DS=3168 ES=3168 SS=3168 CS=3168 IP=0146 NV UP EI PL ZR NA PE NC
3168:0146 7538              jnz     0180                            not jumping
AX=1200 BX=0000 CX=0200 DX=0200 SP=FFFE BP=0000 SI=0000 DI=0000
DS=3168 ES=3168 SS=3168 CS=3168 IP=0148 NV UP EI PL ZR NA PE NC
3168:0148 813E88004220      cmp     word [0088], 2042              DS:0088=4554
AX=1200 BX=0000 CX=0200 DX=0200 SP=FFFE BP=0000 SI=0000 DI=0000
DS=3168 ES=3168 SS=3168 CS=3168 IP=014E NV UP EI PL NZ NA PE NC
3168:014E 7530              jnz     0180                                jumping

Trying to resume the subdirectory's search, we instead get the second directory entry of the root directory. The kernel uses its static buffer and is unable to resume a concurrent search, where EDR-DOS (and presumably other 8086 DOS compatibles) is able to do just that.

Also note that this is on a FAT32 file system, so perhaps EDR-DOS is uniquely capable. The interrupt list notes that FCB open only works on FAT32 volume labels rather than files. (Probably they were thinking of FCB create rather than open, actually.) In the Find First FCB description there is no corresponding note, but it is possible that it does not work on a FAT32 FS on MS-DOS 7.10+ either. (I quickly tested it, and it appears that FCB Open succeeds on the FAT32 FS image on EDR-DOS. Did not test actually reading or writing the file.)

Other than the attribute bug (which I assume indicates a bug in the FreeDOS kernel with the EDR-DOS kernel's choice being correct), there appear to be two bugs in the FreeDOS kernel:

There are two UWORD fields in the FCB structure's reserved parts that are called fcb_strtclst and fcb_dirclst:

Searching for "clst" in the file fcbfn.s reveals that these two fields are only used by the FCB Find functions, not any usual FCB file operations it appears. (The normal FCB file accesses depend entirely on the stored SFT handle number to point to the same, still valid FCB SFT entry.) Both fields are written once and read once: https://github.com/FDOS/kernel/blob/29ccb6e45414a8a18346a97fdb0f35ebd6fb4025/kernel/fcbfns.c

Here, in the early part of FcbFindFirstNext:

    Dmatch.dm_entry = lpFcb->fcb_strtclst;
    Dmatch.dm_dircluster = lpFcb->fcb_dirclst;

And here, a bit further down:

  lpFcb->fcb_dirclst = (UWORD) Dmatch.dm_dircluster;
  lpFcb->fcb_strtclst = Dmatch.dm_entry;

There is one problem immediately apparent here, though the third bug actually completely masks this (second) bug: The dm_dircluster field of the DTA (dmatch) structure is a 32-bit dword for a FAT32-enabled kernel build. But it is truncated to, respectively zero-extended from, a 16-bit word in these accesses. I will study EDR-DOS's approach at a later point but cursory tests seem to indicate it stores the complete 32-bit directory cluster number in the search FCB's structure.

The third bug is in this line:

It reads if (First). This condition is reversed from what it should be. The (static) dmatch buffer used by the kernel should be updated from the search FCB if this call is a Find Next. The way this condition is written, it will "update" the dmatch fields from the (uninitialised) search FCB only before the DosFindFirst call, which I believe has no effect whatsoever. Before a DosFindNext call, the dmatch structure is never re-initialised from the search FCB.

This did not cause readily apparent bugs because the kernel's static dmatch structure used by the FCB find functions will still hold the prior call's data when an FCB Find Next call happens. However, as in my test with the interleaved concurrent searches, this is not what was intended and actually does constitute a bug whenever more than one search is in progress in an application.

I will prepare patches to these three bugs at a later time. The third bug probably also requires to re-order the wAttr uses a bit.

In the makefile the recipe line $(NASM) -dISFAT12 boot.asm -l$*.lst -ofat12com.bin creates the file .lst (just dot L S T, no name portion) on our server and the desktop box (both running Debian). This seems to have been added in https://sourceforge.net/p/freedos/svn/1492/

Older FreeDOS versions used to have a KERNELS.ZIP file with source\ukernel\boot\fat32lba.bin and friends, as mentioned here:

http://wiki.freedos.org/wiki/index.php/How_to_Create_a_USB_Boot_Disk_Using_FreeDOS

Could these get packaged somewhere again?

Thanks.

I wasn't sure what to do with this, so I thought I would post it here and ask if anyone might need/want them, and give FreeDOS devs the opportunity to ask for them to be removed if they are in any way a problem.

While compiling a multiboot USB that included an image for FreeDOS, I went looking for a logo to include in the boot menu, and found that I could not find anything for FreeDOS except for a small raster file that may/may not be anything official. At any rate, I opted to take that raster file and trace it out in Illustrator, and these are simply the result of that:

https://github.com/nativeit/freedos-logo

It seems that the version of NASM that comes with Ubuntu Focal 20.04 now cares that there is a duplicate output file specified. I would have tried to fix it, but the first -o iasmsupt.obj appears to come from the NASMFLAGS variable and I couldn't see where that got set?

nasm -Dgcc -D_INIT -f obj -DWITHFAT32 -i../hdr/ -DXCPU=86 -felf -o iasmsupt.obj -o iasmsupt.obj asmsupt.asm
iasmsupt.obj: fatal: more than one output file specified: iasmsupt.obj

make[1]: *** [GNUmakefile:161: iasmsupt.obj] Error 1
make[1]: Leaving directory '/clients/common/fdkernel.git/kernel'

On Gitlab there was a lengthy discussion on an issue that eventually was identified as layer 8 error. But the person had one point in that he/she mentioned that the check at

should probably be extended to check for an invalid head value of zero, which could otherwise lead to a division by zero. I think this is true and should probably be changed. The question is if a "default" head value of 254 should be assumed or if the drive should be rejected at all.

The discussion took place at https://gitlab.com/FreeDOS/base/kernel/-/issues/4

Hi. Ch357 is a USB to ISA controller that is somewhat popular in retro community. It's also built-in into Book8088, a hobbyist retro computer from China.

I tried the CH357 drivers on a last nights build of 2043 dev kernel (both 8086 and 80186 with FAT32) and it got stuck after displaying the driver info and if the USB stick is inserted or not (it gets stuck in both cases).

I than tried one of the drivers on 2042 kernel (8086 with FAT32) from Sourceforge and it actually worked without problems. The version released as 2.43 on GitHub also works. By further testing I isolated the problem to the changes from the last 2 days (4th and 5th of february 2024). By building and trying the commits from the past two days, I identified that the problem first appear with the commit 1c2f541.