freedos-devel Mailing List for The FreeDOS Project

Hi again,

On Wed, Jun 10, 2026 at 1:57 PM Rugxulo <ru...@gm...> wrote:
>
> On Mon, Jun 8, 2026 at 7:01 PM Jim Hall via Freedos-devel
> <fre...@li...> wrote:
> >
> > Marco Pistella <mpi...@li...> wrote:
> > >
> > > I'd like to share a new DOS tool I recently published on GitHub: X-VESA
>
> I haven't tried it yet, but it uses "ASMC", which apparently is
> nidud's "improved" fork of JWasm 2.21, and TLINK.

Oops, I think I meant to say JWasm 2.12pre.

Hi,

On Mon, Jun 8, 2026 at 7:01 PM Jim Hall via Freedos-devel
<fre...@li...> wrote:
>
> Marco Pistella <mpi...@li...> wrote:
> >
> > I'd like to share a new DOS tool I recently published on GitHub: X-VESA
> > V2.0.0, a diagnostic program for in-depth analysis and verification of
> > VESA interfaces on real hardware.
> >
> > GitHub repository: https://github.com/Marco-Pistella/X-VESA

I haven't tried it yet, but it uses "ASMC", which apparently is
nidud's "improved" fork of JWasm 2.21, and TLINK.

Here's another bat file so you can test a bunch of values. It's just
two lines long, and passes its command line option to the ERRLEV
program, then prints the value of %ERRORLEVEL%

errlev %1
echo %ERRORLEVEL%

(I called this program ERRLEVL.BAT)

And you can use a FOR loop on the command line to test different values:


for %n in (1 10 100 200 250 255) do call errlevl.bat %n

D:\SRC>call errlevl.bat 1
D:\SRC>errlev 1
D:\SRC>echo 1
1
D:\SRC>call errlevl.bat 10
D:\SRC>errlev 10
D:\SRC>echo 10
10
D:\SRC>call errlevl.bat 100
D:\SRC>errlev 100
D:\SRC>echo 100
100
D:\SRC>call errlevl.bat 200
D:\SRC>errlev 200
D:\SRC>echo 200
200
D:\SRC>call errlevl.bat 250
D:\SRC>errlev 250
D:\SRC>echo 250
250
D:\SRC>call errlevl.bat 255
D:\SRC>errlev 255
D:\SRC>echo 255
255


If you try it for values above 255 (not valid on DOS, you can only
have error levels up to 255) you'll see the returned int is truncated:

for %n in (255 256 257 510 511 512) do call errlevl.bat %n

D:\SRC>call errlevl.bat 255
D:\SRC>errlev 255
D:\SRC>echo 255
255
D:\SRC>call errlevl.bat 256
D:\SRC>errlev 256
D:\SRC>echo 0
0
D:\SRC>call errlevl.bat 257
D:\SRC>errlev 257
D:\SRC>echo 1
1
D:\SRC>call errlevl.bat 510
D:\SRC>errlev 510
D:\SRC>echo 254
254
D:\SRC>call errlevl.bat 511
D:\SRC>errlev 511
D:\SRC>echo 255
255
D:\SRC>call errlevl.bat 512
D:\SRC>errlev 512
D:\SRC>echo 0
0


*Remember, 255 is binary 1111 1111
256 is binary 1 0000 0000
257 is binary 1 0000 0001
..and so on

(That is, the error level can only be one byte long.)


On Tue, Jun 9, 2026 at 6:42 PM Jim Hall <jh...@fr...> wrote:
>
> On Tue, Jun 9, 2026 at 3:48 PM victoria crenshaw wrote:
> >
> [..]
> >
> > a note for Jerome:
> > The error levels is what i am going to focus next but i need to be in a
> > voice chat with you or someone and discuss the error levels for the program
> >
> > because i never actually implemented error levels in any program before.
> > so this is exciting
> >
> > i know where to implement them is in src/fdnpkg16.c
> > with the QUIT(0) code lines
> >
>
> Error levels are really easy: it's just whatever int the main()
> program returns, and that gets returned to the operating system. For
> DOS, use an error level that's greater than or equal to zero. (Zero
> usually indicates success, some other value indicates an error or
> warning.)
>
> Here's a sample program that just reads a single value from the
> command line, and returns that int. (It returns zero otherwise.)
>
>
> #include <stdio.h>
> #include <stdlib.h> /* atoi */
>
> int main(int argc, char **argv)
> {
>   int errlevel;
>
>   if (argc == 1) { return 0; }
>
>   /* at least one command line argument. assume the first arg is an
>      integer, and use that for the error level. Should be greater than
>      or equal to zero. */
>
>   errlevel = atoi(argv[1]);
>
>   if (errlevel<0) { return 0; }
>
>   return errlevel;
> }
>
>
>
> Save that as errlev.c then compile that and run it, you can generate
> whatever error level you like. FreeDOS (actually FreeCOM) lets you
> print the value using the %ERRORLEVEL% built-in environment variable,
> so you can just echo %ERRORLEVEL% to see the value.
>
> Here's a simple bat that prints the values 1 to 5: (I called it errlevel.bat)
>
> errlev 1
> echo %errorlevel%
> errlev 2
> echo %errorlevel%
> errlev 3
> echo %errorlevel%
> errlev 4
> echo %errorlevel%
> errlev 5
> echo %errorlevel%
>
>
>
> This doesn't use @ECHO OFF so you can see everything that it's doing.
> Here's a sample run: (I'm running this in my D:\SRC directory)
>
> D:\SRC>errlevel.bat
> D:\SRC>errlev 1
> D:\SRC>echo 1
> 1
> D:\SRC>errlev 2
> D:\SRC>echo 2
> 2
> D:\SRC>errlev 3
> D:\SRC>echo 3
> 3
> D:\SRC>errlev 4
> D:\SRC>echo 4
> 4
> D:\SRC>errlev 5
> D:\SRC>echo 5
> 5

On Tue, Jun 9, 2026 at 3:48 PM victoria crenshaw wrote:
>
[..]
>
> a note for Jerome:
> The error levels is what i am going to focus next but i need to be in a
> voice chat with you or someone and discuss the error levels for the program
>
> because i never actually implemented error levels in any program before.
> so this is exciting
>
> i know where to implement them is in src/fdnpkg16.c
> with the QUIT(0) code lines
>

Error levels are really easy: it's just whatever int the main()
program returns, and that gets returned to the operating system. For
DOS, use an error level that's greater than or equal to zero. (Zero
usually indicates success, some other value indicates an error or
warning.)

Here's a sample program that just reads a single value from the
command line, and returns that int. (It returns zero otherwise.)


#include <stdio.h>
#include <stdlib.h> /* atoi */

int main(int argc, char **argv)
{
  int errlevel;

  if (argc == 1) { return 0; }

  /* at least one command line argument. assume the first arg is an
     integer, and use that for the error level. Should be greater than
     or equal to zero. */

  errlevel = atoi(argv[1]);

  if (errlevel<0) { return 0; }

  return errlevel;
}



Save that as errlev.c then compile that and run it, you can generate
whatever error level you like. FreeDOS (actually FreeCOM) lets you
print the value using the %ERRORLEVEL% built-in environment variable,
so you can just echo %ERRORLEVEL% to see the value.

Here's a simple bat that prints the values 1 to 5: (I called it errlevel.bat)

errlev 1
echo %errorlevel%
errlev 2
echo %errorlevel%
errlev 3
echo %errorlevel%
errlev 4
echo %errorlevel%
errlev 5
echo %errorlevel%



This doesn't use @ECHO OFF so you can see everything that it's doing.
Here's a sample run: (I'm running this in my D:\SRC directory)

D:\SRC>errlevel.bat
D:\SRC>errlev 1
D:\SRC>echo 1
1
D:\SRC>errlev 2
D:\SRC>echo 2
2
D:\SRC>errlev 3
D:\SRC>echo 3
3
D:\SRC>errlev 4
D:\SRC>echo 4
4
D:\SRC>errlev 5
D:\SRC>echo 5
5

  - [fix] case-less file name comparisons when checking packages for 
conflicting files on hard disk
  - [new] you can now press a or 3 to abort the installation of a 
package with files on disk
  - [fix] updated translations


get it here

https://git.gay/sparky4/fdnpkg16/releases/download/0.99.8254c/fdnpkg16.zip

or any of the release places


a note for Jerome:
The error levels is what i am going to focus next but i need to be in a 
voice chat with you or someone and discuss the error levels for the program

because i never actually implemented error levels in any program before. 
so this is exciting

i know where to implement them is in src/fdnpkg16.c
with the QUIT(0) code lines

I am re-posting this announcement for a developer who wanted to share
his program, but isn't subscribed to the email list.

>From the GitHub page:
:: X-VESA enumerates all available VESA video modes, decodes the information
:: returned by the VESA interface for each mode, and performs functional
:: tests and measurements on the hardware resources actually accessible. It
:: supports VBE specifications from version 1.0 to version 3.0, including
:: non-standard versions and partial or defective implementations.
::
:: X-VESA is designed for use on real hardware. Operation on emulators
:: or virtual machines is technically possible but discouraged: timing,
:: jitter and VRAM access speed measurements produce meaningless results
:: in an emulated environment.

X-VESA is distributed under the GNU GPL.

Here's the announcement:

Marco Pistella <mpi...@li...> wrote:
>
> I'd like to share a new DOS tool I recently published on GitHub: X-VESA
> V2.0.0, a diagnostic program for in-depth analysis and verification of
> VESA interfaces on real hardware.
>
> X-VESA enumerates all available VESA video modes, decodes the information
> returned by the VESA interface for each mode, and performs functional
> tests and measurements on the hardware resources actually accessible. It
> supports VBE specifications from version 1.0 to 3.0.
>
> Key features include VRAM benchmarks (8 to 512-bit, with SSE/AVX/AVX-512F
> support), VRAM reliability tests, video scan timing analysis, EDID decode,
> virtual resolution tests, and Video BIOS ROM dump.
>
> X-VESA is a complete rewrite from scratch in x86 assembly language
> (22,000+ lines), released under GPL-3.0.
>
> GitHub repository: https://github.com/Marco-Pistella/X-VESA
>
> Official thread: https://www.vogons.org/viewtopic.php?t=111021
>

Steve Nickolas:

> I'll sometimes have conversations or make posts in
> Spanish.  I'd rather use my limited and broken but
> human Spanish, than machine-translated Spanish.

Same here.  I would rather read and write in poor
grammar, than let AI intrude into my congnitive
processes thinking and self-expression.  If FreeDOS bans
AI tools for source-code and prose generation, as well
as for devops assistance, it can be removed from the
open-slopware blacklist, as a bonus:

   <https://codeberg.org/small-hack/open-slopware>

> On Jun 3, 2026, at 5:24 PM, Curtis Matz via Freedos-devel <fre...@li...> wrote:
> 
> Thanks Victoria.  Where is that application?
> 
> C:\>dir fd*.exe /s
>  Volume in drive C is FREEDOS
>  Volume Serial Number is 2F2F-1B01
> 
> 
> Directory of C:\FREEDOS\BIN
> 
> FDIMPLES EXE        26,110  12-26-2024  4:36p
> FDINST   EXE        39,644  01-04-2021  8:10a
> FDISK    EXE        39,862  04-26-2025  6:12p
> FDNPKG   EXE       469,496  02-06-2019  4:28a
>          4 file(s)        575,112 bytes
> 
> Total files listed:
>          4 file(s)        575,112 bytes
>          0 dir(s)   2,100,101,120 bytes free

By default it is not installed. However, if you have networking working, you can run:

C:\fdnpkg install fdnpkg16

Or you can download the most recent version and save it to a floppy and run:

A:\fdinst install fdnpkg16.zip

While my repository [1] and the official repository [2] are kept fairly up to date, you can be assured to get the absolute latest version from Victoria’s repository [3].

Just be aware, this is not exactly the same as installing the monthly interim test builds. Some things (like FDAUTO.BAT and FDCONFIG.SYS), are created and installed by the installer. If they have been modified with the newer build, these will not be updated to the latest version. This also applies to FreeCOM and the Kernel. While their packages would be updated, they will not be made active by simply updating their packages. But, changes to all those items are rare and simply doing a package update is usually sufficient. 

:-)

[1] http://dos.lod.bz/repository/latest/html/en/net/fdnpkg16/20260528.7/index.html
[2] https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/html/en/net/fdnpkg16/20260523.4/index.html
[3] https://4ch.mooo.com/freedos/repos/latest/html/en/net/fdnpkg16/20260528.0/index.html

Thanks Victoria.  Where is that application?

C:\>dir fd*.exe /s
 Volume in drive C is FREEDOS
 Volume Serial Number is 2F2F-1B01


Directory of C:\FREEDOS\BIN

FDIMPLES EXE        26,110  12-26-2024  4:36p
FDINST   EXE        39,644  01-04-2021  8:10a
FDISK    EXE        39,862  04-26-2025  6:12p
FDNPKG   EXE       469,496  02-06-2019  4:28a
         4 file(s)        575,112 bytes

Total files listed:
         4 file(s)        575,112 bytes
         0 dir(s)   2,100,101,120 bytes free

> On Jun 3, 2026, at 4:17 PM, victoria crenshaw via Freedos-devel <fre...@li...> wrote:
> 
> fdnpkg16 up
> 
> 
> 
> is all u gotta type for the packages to upgrade
> 
> :D
> 
> On 6/3/26 8:40 AM, Wilhelm Spiegl via Freedos-devel wrote:
>> If your fdos machine has a network connection via your mac, try fdnpkg(16) - i think it is checkupdates, victoria can tell you more.
>> 
>> Willi
>> 
>> --
>> Gesendet mit der mail.com <http://mail.com/> Mail App
>> 
>> 
>> Am 03.06.26, 15:17 schrieb Curtis Matz via Freedos-devel <fre...@li... <http://lists.sourceforge.net/>>:
>>> 
>>> What is everyone’s procedure for upgrading the monthly build each month? I’m not sure what logic is in the installation procedure so what I do is below in UTM on Silicon Mac.
>>> 
>>> 1. I have a backup.bat that backs up config files (c:\fd*.*, _VIMRC, Game saves etc…)
>>> 2. I zip my backup USER dir to A:
>>> 3. I boot to the new live cd and run format c:
>>> 4. Reboot and run the install to the hard drive.
>>> 5. Load the Bonus CD and load my packages.
>>> 6. Unzip my user directory from a:.
>>> 7. Run merge.bat that I wrote to add my call in c:\fdauto.bat to my specific config in my user directory.
>>> 8. Reboot one last time and I’m live.
>>> 
>>> As my DOS build gets bigger I’ll have to maybe copy my backup through the network or something like that but for now it works.
>>> 
>>> I’m sure this probably isn’t the best way and I’m sure the installation procedure can do a few things for me.
>>> 
>>> Let me know.
>>> 
>>> Curtis
>>> 
>>> _______________________________________________
>>> Freedos-devel mailing list
>>> Fre...@li... <http://lists.sourceforge.net/>
>>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>> 
>> 
>> 
>> _______________________________________________
>> Freedos-devel mailing list
>> Fre...@li... <mailto:Fre...@li...>
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> _______________________________________________
> Freedos-devel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

fdnpkg16 up


is all u gotta type for the packages to upgrade

:D

On 6/3/26 8:40 AM, Wilhelm Spiegl via Freedos-devel wrote:
> If your fdos machine has a network connection via your mac, try 
> fdnpkg(16) - i think it is checkupdates, victoria can tell you more.
>
> Willi
>
> --
> Gesendet mit der mail.com <http://mail.com> Mail App
>
>
> Am 03.06.26, 15:17 schrieb Curtis Matz via Freedos-devel 
> <fre...@li... <http://lists.sourceforge.net>>:
>
>     What is everyone’s procedure for upgrading the monthly build each
>     month? I’m not sure what logic is in the installation procedure so
>     what I do is below in UTM on Silicon Mac.
>
>     1. I have a backup.bat that backs up config files (c:\fd*.*,
>     _VIMRC, Game saves etc…)
>     2. I zip my backup USER dir to A:
>     3. I boot to the new live cd and run format c:
>     4. Reboot and run the install to the hard drive.
>     5. Load the Bonus CD and load my packages.
>     6. Unzip my user directory from a:.
>     7. Run merge.bat that I wrote to add my call in c:\fdauto.bat to
>     my specific config in my user directory.
>     8. Reboot one last time and I’m live.
>
>     As my DOS build gets bigger I’ll have to maybe copy my backup
>     through the network or something like that but for now it works.
>
>     I’m sure this probably isn’t the best way and I’m sure the
>     installation procedure can do a few things for me.
>
>     Let me know.
>
>     Curtis
>
>     _______________________________________________
>     Freedos-devel mailing list
>     Fre...@li... <http://lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
>
> _______________________________________________
> Freedos-devel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

I didn't know about UTM on Mac, but it seems to be a QEMU for Mac.
https://mac.getutm.app/

:: UTM uses QEMU, a decades old, free and open source emulation
:: software that is widely used and actively maintained.


I use QEMU on Linux, and I do a fresh install every time. Since disk
space is cheap in a virtual machine, I do it this way:

I make a new virtual disk that I use for the operating system, and
keep a second virtual disk where I keep all my stuff (files, apps,
games, and other things).

Here's how I install:

1. Make a new virtual disk

2. Boot the installer with just FullUSB and the new virtual disk
(recognized as D: during the install)

3. Install the new FreeDOS test release on the new virtual disk

That's it! :-)

When I run FreeDOS normally, I just boot the virtual machine using the
new virtual disk as C: and the "my stuff" virtual disk as the D: drive
(and FullUSB as the E: drive, so I can install other packages later).
And all my files are there right away, without having to
backup/restore anything.

I make a copy of a few things to D: that I want to keep between
installs. For example, I keep a copy of my FED.CFG (editor config
file) on D: that I copy back to C:\apps\fed after every install.


On Wed, Jun 3, 2026 at 8:17 AM Curtis Matz via Freedos-devel
<fre...@li...> wrote:
>
> What is everyone’s procedure for upgrading the monthly build each
> month?  I’m not sure what logic is in the installation procedure so
> what I do is below in UTM on Silicon Mac.
>
> 1. I have a backup.bat that backs up config files (c:\fd*.*, _VIMRC, Game saves etc…)
> 2. I zip my backup USER dir to A:
> 3. I boot to the new live cd and run format c:
> 4. Reboot and run the install to the hard drive.
> 5. Load the Bonus CD and load my packages.
> 6. Unzip my user directory from a:.
> 7. Run merge.bat that I wrote to add my call in c:\fdauto.bat to my specific config in my user directory.
> 8. Reboot one last time and I’m live.
>
> As my DOS build gets bigger I’ll have to maybe copy my backup through
> the network or something like that but for now it works.
>
> I’m sure this probably isn’t the best way and I’m sure the
> installation procedure can do a few things for me.
>

thanks

On 5/29/26 1:10 PM, Jim Hall via Freedos-devel wrote:
>> On Thu, May 28, 2026 at 6:23 PM victoria crenshaw via Freedos-devel
>> <fre...@li...> wrote:
>> [..]
> BTW, I noticed your knownbug.txt file uses really long lines, which
> makes this difficult to read on DOS. If you break lines around column
> 75, and add spacing, it will be more readable. Here's a fixed version
> for you: (I did not correct spelling/grammar)
>
>> known bugs:
>>
>> cant seem to update when there is an update...
>>
>>     fdnpkg16 inherited a version determination bug from fdnpkg32
>>
>>         try the reinstall command
>>
>>     actual solution: we will use modification date to determine this! :D
>>     but this requires collab help! <3
>>
>> cant seem to get fdnpkg16 to work on a system with lower ram
>>
>>     cant run fdnpkg16 on a system with less ram than 480kb avalible
>>
>>         try fdnpkg16 version 0.99.8253d or later and if that dont work try
>>         to maximize your ram for fdnpkg16 to work
>>
>>     actual solution: i need to make the program smaller there is alot of
>>     unused stuff
>>
>>
>> Known issue, regarding case-less file name comparisons when checking
>> packages for conflicting files on hard disk.
>>
>> Known issue, No errorlevels at the moment. reason? complex program i need
>> to talk to freedos people! :D
>
> _______________________________________________
> Freedos-devel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

On at 2026-06-03 07:45:53 -0400, Jerome Shidel via Freedos-devel <fre...@li...> wrote:
>
>
>> On Jun 2, 2026, at 4:57 PM, E. C. Masloch via Freedos-devel <fre...@li...> wrote:
>> [..]
>> That's a "cpu 8086" directive. Indeed, it avoids allowing many 186+, 286+, or 386+ instructions.
>> 
>> More importantly, if a conditional jump needs to be widened to address a near target (if it isn't in range of a short jump) then without any "cpu" directive recent NASM versions will use the 0Fh-prefixed, 386+ single-instruction form of a near conditional jump. With "cpu 8086" it instead encodes a two-instruction workaround in which the first jump is short and conditional on the inverted condition, and the second jump is near and unconditional.
>
>Hmm. I wonder if there is a way to turn off that “double jump” feature. I would much rather prefer NASM to not try and be “helpful” in this case and simply generate an error if it encounters an instruction for a short jump which is too far. I would much prefer it only encode the instructions I tell it to use. After all, this is assembly and not some abstracted HLL.

You can use the preprocessor to do this. Here's a simple test case, also uploaded to our server [1]. It is so simple because it only needs "one" mmacro, but you have to repeat it for every of the dozens of possible jcc choices (for whichever choices you use). This could probably be golfed to need only a single mmacro and use an smacro per jcc instead.

===
test$ cat test.asm

        cpu 8086
label:
        times 256 nop
        je label

%imacro je 1.nolist
        %? short %1
%endmacro

%ifdef ERROR
        je label
%endif


test$ nasm -v
NASM version 3.01rc3 compiled on Mar  6 2026
test$ nasm test.asm -l /dev/stderr
     1
     2                                          cpu 8086
     3                                  label:
     4 00000000 90<rep 100h>                    times 256 nop
     5 00000100 7503E9FBFE                      je label
     6
     7                                  %imacro je 1.nolist
     8                                          %? short %1
     9                                  %endmacro
    10
    11                                  %ifdef ERROR
    12                                          je label
    13                                  %endif
test$ nasm test.asm -l /dev/stderr -DERROR
     1
     2                                          cpu 8086
     3                                  label:
     4 00000000 90<rep 100h>                    times 256 nop
     5 00000100 7503E9FBFE                      je label
     6
     7                                  %imacro je 1.nolist
     8                                          %? short %1
     9                                  %endmacro
    10
    11                                  %ifdef ERROR
test.asm:12: error: short jump is out of range
test.asm:12: warning: signed byte exceeds bounds [-w+number-overflow]
    12 00000105 74F9                            je label
    12          ******************       error: short jump is out of range
    12          ******************       warning: signed byte exceeds bounds [-w+number-overflow]
    13                                  %endif


test$ oldnasm -v
NASM version 2.15rc0 compiled on Dec 28 2018
test$ oldnasm test.asm -l /dev/stderr
     1
     2                                          cpu 8086
     3                                  label:
     4 00000000 90<rept>                        times 256 nop
     5 00000100 7503E9FBFE                      je label
     6
     7                                  %imacro je 1.nolist
     8                                          %? short %1
     9                                  %endmacro
    10
    11                                  %ifdef ERROR
    12                                          je label
    13                                  %endif
test$ oldnasm test.asm -l /dev/stderr -DERROR
     1
     2                                          cpu 8086
     3                                  label:
     4 00000000 90<rept>                        times 256 nop
     5 00000100 7503E9FBFE                      je label
     6
     7                                  %imacro je 1.nolist
     8                                          %? short %1
     9                                  %endmacro
    10
    11                                  %ifdef ERROR
test.asm:12: error: short jump is out of range
test.asm:12: warning: byte data exceeds bounds [-w+number-overflow]
    12 00000105 74F9                            je label
    12          ******************       error: short jump is out of range
    12          ******************       warning: byte data exceeds bounds [-w+number-overflow]
    13                                  %endif
test$
===

I also prepared a NASM macro file, jn_warn.mac [2], at some earlier point (apparently 2018-03-26). (Released into the Public Domain.) It works similarly to the above simple case, except it allows the near code but emits a warning if the generated machine code is longer than 2 bytes. That detects both the 8086 workaround and the 386 single-instruction near jcc.

>Such things tend to be more trouble than they are worth and create extreme  problems when debugging. As someone who has pushed NASM’s macros and advanced features past the breaking point several times in DOS related programming, these types of “features” lead to many headaches and sleepless nights.

I'm also a rather heavy user of the NASM preprocessor. The surprising nature of something like this is why I want to share knowledge about it. In this case, I do prefer to have NASM extend the jcc jumps though.

As a question I'd suggest, can you emulate the other choice using what we have? As I've shown you can emulate both "error on non-short jcc" and "warn on non-short jcc" with things as is. If we didn't have NASM's 8086 near jcc workaround feature, you would have to be able to emulate *that* choice using the preprocessor in tandem with the assembler. I'm not sure that would be even possible as you need to evaluate the distances to the destination, especially tricky if the destination is after the jcc use.
 
>> So even if you seemingly use only 8086-clean code, NASM may generate these 386+ forms of conditional jumps. You need either "cpu 8086" or to override every conditional jump (except loopxx/jcxz) with a "short" keyword to force an error rather than using the non-8086 instruction forms.
>> 
>>> No different than specifying the offset of the code for things like COM files by using “org 0x100”
>>> 
>>> So, that statement about it usually generates 386+ code makes no sense to me. Unless, the statement is in regards to running NASM. Then because NASM is huge, you would be limited to compiling using a 386+.
>> 
>> Yes, I believe that's what Rugxulo means. As the assembler was developed, it got trickier (if not impossible) to compile the assembler itself as an 8086-compatible application. I know I tried that at some point too, and I don't think I succeeded then.
>> 
>> Writing of the 8086 cleanliness of NASM output, though, even "cpu 8086" doesn't always save the day. Some 386 addressing modes and registers are allowed despite the selected machine level. I recently commented about this on a stackoverflow question [1] in which I also cited earlier NASM bug reports that I had submitted, namely an "[edx]" a32 address is assembled despite "cpu 8086" [2] and an "fs" segreg operand (not as a prefix) is also assembled where it shouldn't be. (The links lead to mirrored copies on our server as the old NASM bugzilla is down more often than not lately.)
>> 
>
>True. But, I would consider such things a compiler “bug”.

Yes, hence why I reported them to the "bug" tracker at the time ;P  As the responses indicated, it is a known problem but there is not enough work to fix it yet.

> However, if you use the “cpu 8086” directive and write 8086 code, it generates 8086 code. 

Yes, that's right.

Regards,
ecm


[1]: https://pushbx.org/ecm/test/20260603/test.txt
[2]: https://hg.pushbx.org/ecm/lmacros/file/de53a9686fad/jn_warn.mac

<html><body>If your fdos machine has a network connection via your mac, try fdnpkg(16) - i think it is checkupdates, victoria can tell you more.<br><br>Willi<br><br><div class="signature">--<br>Gesendet mit der <a href="http://mail.com">mail.com</a> Mail App</div><div class="mail_android_quote" style="line-height: 1"><br><meta name="viewport" content="width=device-width"><meta http-equiv="Content-Type" content="text/vnd.ui.insecure+html;charset=utf-8"><div class="mail_android_quote" style="line-height: 1"><br>Am 03.06.26, 15:17 schrieb Curtis Matz via Freedos-devel &lt;freedos-devel@<a href="http://lists.sourceforge.net">lists.sourceforge.net</a>&gt;:<blockquote class="gmail_quote" style="margin: 0.8ex 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
What is everyone’s procedure for upgrading the monthly build each month?  I’m not sure what logic is in the installation procedure so what I do is below in UTM on Silicon Mac.<br>
<br>
1. I have a backup.bat that backs up config files (c:\fd*.*, _VIMRC, Game saves etc…)<br>
2. I zip my backup USER dir to A:<br>
3. I boot to the new live cd and run format c:<br>
4. Reboot and run the install to the hard drive.<br>
5. Load the Bonus CD and load my packages.<br>
6. Unzip my user directory from a:.<br>
7. Run merge.bat that I wrote to add my call in c:\fdauto.bat to my specific config in my user directory.<br>
8. Reboot one last time and I’m live.<br>
<br>
As my DOS build gets bigger I’ll have to maybe copy my backup through the network or something like that but for now it works.<br>
<br>
I’m sure this probably isn’t the best way and I’m sure the installation procedure can do a few things for me.<br>
<br>
Let me know.<br>
<br>
Curtis<br>
<br>
_______________________________________________<br>
Freedos-devel mailing list<br> Freedos-devel@<a href="http://lists.sourceforge.net">lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/freedos-devel">https://lists.sourceforge.net/lists/listinfo/freedos-devel</a><br>
</blockquote></div></div></body></html>

What is everyone’s procedure for upgrading the monthly build each month?  I’m not sure what logic is in the installation procedure so what I do is below in UTM on Silicon Mac.

1. I have a backup.bat that backs up config files (c:\fd*.*, _VIMRC, Game saves etc…)
2. I zip my backup USER dir to A:
3. I boot to the new live cd and run format c:
4. Reboot and run the install to the hard drive.
5. Load the Bonus CD and load my packages.
6. Unzip my user directory from a:.
7. Run merge.bat that I wrote to add my call in c:\fdauto.bat to my specific config in my user directory.
8. Reboot one last time and I’m live.

As my DOS build gets bigger I’ll have to maybe copy my backup through the network or something like that but for now it works.

I’m sure this probably isn’t the best way and I’m sure the installation procedure can do a few things for me.

Let me know.

Curtis

> On Jun 2, 2026, at 4:57 PM, E. C. Masloch via Freedos-devel <fre...@li...> wrote:
> [..]
> That's a "cpu 8086" directive. Indeed, it avoids allowing many 186+, 286+, or 386+ instructions.
> 
> More importantly, if a conditional jump needs to be widened to address a near target (if it isn't in range of a short jump) then without any "cpu" directive recent NASM versions will use the 0Fh-prefixed, 386+ single-instruction form of a near conditional jump. With "cpu 8086" it instead encodes a two-instruction workaround in which the first jump is short and conditional on the inverted condition, and the second jump is near and unconditional.

Hmm. I wonder if there is a way to turn off that “double jump” feature. I would much rather prefer NASM to not try and be “helpful” in this case and simply generate an error if it encounters an instruction for a short jump which is too far. I would much prefer it only encode the instructions I tell it to use. After all, this is assembly and not some abstracted HLL.

Such things tend to be more trouble than they are worth and create extreme  problems when debugging. As someone who has pushed NASM’s macros and advanced features past the breaking point several times in DOS related programming, these types of “features” lead to many headaches and sleepless nights. 

> So even if you seemingly use only 8086-clean code, NASM may generate these 386+ forms of conditional jumps. You need either "cpu 8086" or to override every conditional jump (except loopxx/jcxz) with a "short" keyword to force an error rather than using the non-8086 instruction forms.
> 
>> No different than specifying the offset of the code for things like COM files by using “org 0x100”
>> 
>> So, that statement about it usually generates 386+ code makes no sense to me. Unless, the statement is in regards to running NASM. Then because NASM is huge, you would be limited to compiling using a 386+.
> 
> Yes, I believe that's what Rugxulo means. As the assembler was developed, it got trickier (if not impossible) to compile the assembler itself as an 8086-compatible application. I know I tried that at some point too, and I don't think I succeeded then.
> 
> Writing of the 8086 cleanliness of NASM output, though, even "cpu 8086" doesn't always save the day. Some 386 addressing modes and registers are allowed despite the selected machine level. I recently commented about this on a stackoverflow question [1] in which I also cited earlier NASM bug reports that I had submitted, namely an "[edx]" a32 address is assembled despite "cpu 8086" [2] and an "fs" segreg operand (not as a prefix) is also assembled where it shouldn't be. (The links lead to mirrored copies on our server as the old NASM bugzilla is down more often than not lately.)
> 

True. But, I would consider such things a compiler “bug”. However, if you use the “cpu 8086” directive and write 8086 code, it generates 8086 code. 

:-)

On at 2026-06-02 15:54:52 -0400, Jerome Shidel via Freedos-devel <fre...@li...> wrote:
>
>
>> On Jun 2, 2026, at 1:58 PM, Rugxulo via Freedos-devel <fre...@li...> wrote:
>> 
>> Hi,
>> 
>>> On Mon, Jun 1, 2026 at 10:14 AM Jim Hall via Freedos-devel
>>> <fre...@li...> wrote:
>>> 
>>> Mathias Eberle on the Facebook group shared this announcement, which I
>>> am re-sharing here:
>>> 
>>>> I fulfilled myself a little 90s childhood dream and created a single-pass
>>>> self-compiling BASIC compiler for DOS, targetting 8086/8088 and size
>>>> optimized COM files as output!
>>>> 
>>>> The compiler itself generates NASM-compatible code. But since NASM
>>>> usually generates 386+ code, I have also included a special assembler
>>>> written in BASIC, so that the toolchain is complete.
>> 
>> This sounds very cool, but I haven't tried it yet.
>> 
>> Not sure what he means about NASM. I guess he means the default
>> binaries for modern NASM require 386 (and DPMI) from DJGPP.
>> 
>> If his code doesn't require modern NASM preprocessor tricks, if it can
>> assemble with old 0.98.39 (from 2005), then we have 8086 builds of
>> that version (TurboC or OpenWatcom).
>> 
>
>While I do not recall the default CPU target, NASM does not “usually” generate such code. 
>
>This is because it is always a good practice to tell NASM your target with a keyword in the source file. Then you get a binary compatible which the processor you want to target.

That's a "cpu 8086" directive. Indeed, it avoids allowing many 186+, 286+, or 386+ instructions.

More importantly, if a conditional jump needs to be widened to address a near target (if it isn't in range of a short jump) then without any "cpu" directive recent NASM versions will use the 0Fh-prefixed, 386+ single-instruction form of a near conditional jump. With "cpu 8086" it instead encodes a two-instruction workaround in which the first jump is short and conditional on the inverted condition, and the second jump is near and unconditional.

So even if you seemingly use only 8086-clean code, NASM may generate these 386+ forms of conditional jumps. You need either "cpu 8086" or to override every conditional jump (except loopxx/jcxz) with a "short" keyword to force an error rather than using the non-8086 instruction forms.

>No different than specifying the offset of the code for things like COM files by using “org 0x100”
>
>So, that statement about it usually generates 386+ code makes no sense to me. Unless, the statement is in regards to running NASM. Then because NASM is huge, you would be limited to compiling using a 386+.

Yes, I believe that's what Rugxulo means. As the assembler was developed, it got trickier (if not impossible) to compile the assembler itself as an 8086-compatible application. I know I tried that at some point too, and I don't think I succeeded then.

Writing of the 8086 cleanliness of NASM output, though, even "cpu 8086" doesn't always save the day. Some 386 addressing modes and registers are allowed despite the selected machine level. I recently commented about this on a stackoverflow question [1] in which I also cited earlier NASM bug reports that I had submitted, namely an "[edx]" a32 address is assembled despite "cpu 8086" [2] and an "fs" segreg operand (not as a prefix) is also assembled where it shouldn't be. (The links lead to mirrored copies on our server as the old NASM bugzilla is down more often than not lately.)

Regards,
ecm

[1]: https://stackoverflow.com/questions/79929484/can-nasm-behave-like-an-8086-assembler-it-accepts-32-bit-addressing-modes-even#comment141043553_79929484
[2]: https://pushbx.org/ecm/download/nasm/3392664%20%e2%80%93%20_mov%20al,%20byte%20%5bedx%5d_%20does%20not%20cause%20error%20when%20_cpu%208086_%20is%20in%20effect.html
[3]: https://pushbx.org/ecm/download/nasm/3392656%20%e2%80%93%20_mov%20fs,%20ax_%20does%20not%20cause%20error%20when%20_cpu%208086_%20is%20in%20effect.html

> On Jun 2, 2026, at 1:58 PM, Rugxulo via Freedos-devel <fre...@li...> wrote:
> 
> Hi,
> 
>> On Mon, Jun 1, 2026 at 10:14 AM Jim Hall via Freedos-devel
>> <fre...@li...> wrote:
>> 
>> Mathias Eberle on the Facebook group shared this announcement, which I
>> am re-sharing here:
>> 
>>> I fulfilled myself a little 90s childhood dream and created a single-pass
>>> self-compiling BASIC compiler for DOS, targetting 8086/8088 and size
>>> optimized COM files as output!
>>> 
>>> The compiler itself generates NASM-compatible code. But since NASM
>>> usually generates 386+ code, I have also included a special assembler
>>> written in BASIC, so that the toolchain is complete.
> 
> This sounds very cool, but I haven't tried it yet.
> 
> Not sure what he means about NASM. I guess he means the default
> binaries for modern NASM require 386 (and DPMI) from DJGPP.
> 
> If his code doesn't require modern NASM preprocessor tricks, if it can
> assemble with old 0.98.39 (from 2005), then we have 8086 builds of
> that version (TurboC or OpenWatcom).
> 

While I do not recall the default CPU target, NASM does not “usually” generate such code. 

This is because it is always a good practice to tell NASM your target with a keyword in the source file. Then you get a binary compatible which the processor you want to target. 

No different than specifying the offset of the code for things like COM files by using “org 0x100”

So, that statement about it usually generates 386+ code makes no sense to me. Unless, the statement is in regards to running NASM. Then because NASM is huge, you would be limited to compiling using a 386+. 


> 
> _______________________________________________
> Freedos-devel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

Hi,

On Mon, Jun 1, 2026 at 10:14 AM Jim Hall via Freedos-devel
<fre...@li...> wrote:
>
> Mathias Eberle on the Facebook group shared this announcement, which I
> am re-sharing here:
>
> > I fulfilled myself a little 90s childhood dream and created a single-pass
> > self-compiling BASIC compiler for DOS, targetting 8086/8088 and size
> > optimized COM files as output!
> >
> > The compiler itself generates NASM-compatible code. But since NASM
> > usually generates 386+ code, I have also included a special assembler
> > written in BASIC, so that the toolchain is complete.

This sounds very cool, but I haven't tried it yet.

Not sure what he means about NASM. I guess he means the default
binaries for modern NASM require 386 (and DPMI) from DJGPP.

If his code doesn't require modern NASM preprocessor tricks, if it can
assemble with old 0.98.39 (from 2005), then we have 8086 builds of
that version (TurboC or OpenWatcom).

I did all that you did Jim.  Thank you very much.

Unzip -t works.  The zip is valid.  Zip -FF supposedly repairs it but the new file reports the same issue.

The problem with zip though is I can’t add on to the zip or really do anything at all with the zip.

Do I place a bug report with InfoZip or will someone else do it?

Curtis

> On Jun 2, 2026, at 10:53 AM, Jim Hall via Freedos-devel <fre...@li...> wrote:
> 
> On Tue, Jun 2, 2026 at 8:07 AM Curtis Matz via Freedos-devel
> <fre...@li...> wrote:
>> 
>> I’m having an issue with zip and getting the error below any ideas?
>> 
>> C:\>zip -r user.zip c:\user
> [..]
>> C:\>zip -T user.zip
>>        zip warning: missing end signature--probably not a zip file (did you
>>        zip warning: remember to use binary mode when you transferred it?)
>>        zip warning: (if you are trying to read a damaged archive try -F)
>> 
>> zip error: Zip file structure invalid (user.zip)
> 
> This zip exe is from the Info-Zip folks, so this is a problem with the
> binary they provided. I just tested it and I get the same issue. But
> the zip files are otherwise valid (i.e. the data is there and can be
> extracted) but the zip archive is reported as damaged.
> 
> Even more interesting is that using zip -F or -FF to fix it doesn't
> actually repair the problem. (zip -T still reports an issue.)
> 
> 
> I think this is an issue with "zip -T" for that exe. Here's a second test I did:
> 
> On FreeDOS, zip some files from a directory, and test the zip file:
> 
> D:\SRC> zip -r A:m.zip PROJ
> D:\SRC> zip -T A:m.zip
>        zip warning: missing end signature--probably not a zip file (did you
>        zip warning: remember to use binary mode when you transferred it?)
>        zip warning: (if you are trying to read a damaged archive try -F)
> 
> zip error: Zip file structure invalid (A:m.zip)
> 
> 
> On Linux, mount the floppy and test the zip file again:
> 
> $ zip -T floppy/M.ZIP
> test of floppy/M.ZIP OK
> 
> 
> So while I don't like that zip -T is reporting a problem, the zip file
> itself seems to be fine when examined elsewhere. (The zip exe should
> be fixed.)
> 
> 
> _______________________________________________
> Freedos-devel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-devel

On Tue, Jun 2, 2026 at 8:07 AM Curtis Matz via Freedos-devel
<fre...@li...> wrote:
>
> I’m having an issue with zip and getting the error below any ideas?
>
> C:\>zip -r user.zip c:\user
[..]
> C:\>zip -T user.zip
>         zip warning: missing end signature--probably not a zip file (did you
>         zip warning: remember to use binary mode when you transferred it?)
>         zip warning: (if you are trying to read a damaged archive try -F)
>
> zip error: Zip file structure invalid (user.zip)

This zip exe is from the Info-Zip folks, so this is a problem with the
binary they provided. I just tested it and I get the same issue. But
the zip files are otherwise valid (i.e. the data is there and can be
extracted) but the zip archive is reported as damaged.

Even more interesting is that using zip -F or -FF to fix it doesn't
actually repair the problem. (zip -T still reports an issue.)


I think this is an issue with "zip -T" for that exe. Here's a second test I did:

On FreeDOS, zip some files from a directory, and test the zip file:

D:\SRC> zip -r A:m.zip PROJ
D:\SRC> zip -T A:m.zip
        zip warning: missing end signature--probably not a zip file (did you
        zip warning: remember to use binary mode when you transferred it?)
        zip warning: (if you are trying to read a damaged archive try -F)

zip error: Zip file structure invalid (A:m.zip)


On Linux, mount the floppy and test the zip file again:

$ zip -T floppy/M.ZIP
test of floppy/M.ZIP OK


So while I don't like that zip -T is reporting a problem, the zip file
itself seems to be fine when examined elsewhere. (The zip exe should
be fixed.)

I’m having an issue with zip and getting the error below any ideas?

C:\>zip -r user.zip c:\user
  adding: user/ (stored 0%)
  adding: user/bin/ (stored 0%)
  adding: user/bin/vim.bat (deflated 37%)
  adding: user/bin/backup.bat (deflated 26%)
  adding: user/_vimrc (deflated 44%)
  adding: user/user.bat (deflated 38%)
  adding: user/_viminfo (deflated 79%)
  adding: user/sav/ (stored 0%)
  adding: user/sav/_vimrc (deflated 44%)
  adding: user/sav/fdauto.bat (deflated 59%)
  adding: user/sav/fdconfig.sys (deflated 55%)
C:\>zip -T user.zip
        zip warning: missing end signature--probably not a zip file (did you
        zip warning: remember to use binary mode when you transferred it?)
        zip warning: (if you are trying to read a damaged archive try -F)

zip error: Zip file structure invalid (user.zip)
C:\>

> On Mon, 1 Jun 2026, Jim Hall via Freedos-devel wrote:
>
[..]
> > I should also add that Mathias also mentions in the README that "The
> > development was assisted by a coding AI." So this is not something I
> > would suggest to include in FreeDOS. But it was still interesting to
> > see.


On Mon, Jun 1, 2026 at 10:48 AM Steve Nickolas wrote:
>
> I've got my own BASIC assisted by a coding AI - though it's just an
> interpreter and tied a bit tightly into Unixisms, and though I did do a
> fair bit of the code by hand before chucking it at a clanker.
>
> (I don't really like relying on clankers, but I know the general attitude
> is "nobody cares", and I keep hitting walls trying to do some of this
> stuff myself, so it's sort-of a tool of last resort.  That said, Codex/GPT
> just fixed some bugs in a 65SC02 emulator I wrote in 8088 ASM that none of
> the other LLMs I tried could quite get.)

I love that the term now is "clankers." (Not the first time I've seen
this Star Wars reference.)

:-)

On Mon, 1 Jun 2026, Jim Hall via Freedos-devel wrote:

> On Mon, Jun 1, 2026 at 10:12 AM Jim Hall <jh...@fr...> wrote:
>>
>> Mathias Eberle on the Facebook group shared this announcement, which I
>> am re-sharing here:
>>
> [..]
>> And he added as a comment:
>>
>> > Oh, and of course I did use FreeDOS for developing this.
>
> I should also add that Mathias also mentions in the README that "The
> development was assisted by a coding AI." So this is not something I
> would suggest to include in FreeDOS. But it was still interesting to
> see.

I've got my own BASIC assisted by a coding AI - though it's just an 
interpreter and tied a bit tightly into Unixisms, and though I did do a 
fair bit of the code by hand before chucking it at a clanker.

(I don't really like relying on clankers, but I know the general attitude 
is "nobody cares", and I keep hitting walls trying to do some of this 
stuff myself, so it's sort-of a tool of last resort.  That said, Codex/GPT 
just fixed some bugs in a 65SC02 emulator I wrote in 8088 ASM that none of 
the other LLMs I tried could quite get.)

-uso.

Thanks! I've mirrored this to download.freedos.org and updated the
link on the www website.

On Mon, Jun 1, 2026 at 9:42 AM Jerome Shidel via Freedos-devel
<fre...@li...> wrote:
>
> The FreeDOS Interim Test Build T2606 for June is now available for download at:
>
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/
>
> Changes since T2605:
>
> 2026-05-30 06:41:07 fdnpkg16 [unstable] (sparky4): updated INDEX.md
> 2026-05-28 18:09:41 fdnpkg16 [unstable] (sparky4): updated to 0.99.8254b
> 2026-05-28 10:38:31 nethack [unstable] (Shidel): updated to v5.0.0
> 2026-05-27 12:35:21 sbemu [unstable] (Shidel): updated to v1.0.0-beta.6rc
> 2026-05-23 09:57:28 fdnpkg16 [unstable] (sparky4): updated to 0.99.8254a
> 2026-05-23 00:05:27 fdnpkg16 [unstable] (sparky4): updated to 0.99.8254
>
>
>
> _______________________________________________
> Freedos-devel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-devel