This code
.MODEL SMALL, C, OS_DOS
.STACK 20
.DATA
STRING DB "Hello World!", 13, 10, "$"
.CODE
.STARTUP
LEA DX, STRING
MOV AH, 09h
INT 21h
.EXIT
END
produces the following error:
test.asm (10): ERROR A2030: Instruction or register not accepted in current CPU mode
test.asm: 11 lines, 1 passes, .. ms, 0 warnings, 1 errors
The asm code was compiled with:
jwasmr -mz test.asm
If i replace
.MODEL SMALL, C, OS_DOS
with
.MODEL SMALL, C
by removing OS_DOS the code compiles and runs without errors.
Why does this OS_DOS option have such a big impact?
And what is the reason for this?
Why does it fail after the first pass? The working version is made with 2 passes.
Could this be a bug in JWASM v2.14 from Dec 20 2020?
Hello,
Could you try the latest version of JWasm?
https://github.com/Baron-von-Riedesel/JWasm/releases/tag/v2.19 (https://github.com/Baron-von-Riedesel/JWasm/releases/tag/v2.19)
Quote from: bugthis on March 29, 2025, 07:32:16 PMWhy does this OS_DOS option have such a big impact?
And what is the reason for this?
Why does it fail after the first pass? The working version is made with 2 passes.
Could this be a bug in JWASM v2.14 from Dec 20 2020?
Sooo many questions! That's actually a full-time job to answer them...
Could this be a bug in JWASM v2.14 from Dec 20 2020? - No, it's still there in the current version.
Why does it fail after the first pass? The working version is made with 2 passes. I don't know. Is this important?
Why does this OS_DOS option have such a big impact? Well, define "big"!
And what is the reason for this? Instead of an answer, here's the relevant JWasm code ( cpumodel.c ) - or rather the data definitions:
#define INIT_LANG 0x1
#define INIT_STACK 0x2
#define INIT_OS 0x4
struct typeinfo {
uint_8 value; /* value assigned to the token */
uint_8 init; /* kind of token */
};
static const char * const ModelAttr[] = {
"NEARSTACK", "FARSTACK", "OS_OS2", "OS_DOS" };
static const struct typeinfo ModelAttrValue[] = {
{ STACK_NEAR, INIT_STACK },
{ STACK_FAR, INIT_STACK },
{ OPSYS_DOS, INIT_OS },
{ OPSYS_OS2, INIT_OS },
};
A little riddle: can you see the bug just be examining that data?
I guess it's a bug that exists since the very beginning of jwasm - that is 03/2008, so it celebrates its 17th birthday these days.
Quote from: _japheth on March 29, 2025, 09:26:24 PMCould this be a bug in JWASM v2.14 from Dec 20 2020? - No, it's still there in the current version.
Thanks for testing.
QuoteInstead of an answer, here's the relevant JWasm code ( cpumodel.c ) - or rather the data definitions:
#define INIT_LANG 0x1
#define INIT_STACK 0x2
#define INIT_OS 0x4
struct typeinfo {
uint_8 value; /* value assigned to the token */
uint_8 init; /* kind of token */
};
static const char * const ModelAttr[] = {
"NEARSTACK", "FARSTACK", "OS_OS2", "OS_DOS" };
static const struct typeinfo ModelAttrValue[] = {
{ STACK_NEAR, INIT_STACK },
{ STACK_FAR, INIT_STACK },
{ OPSYS_DOS, INIT_OS },
{ OPSYS_OS2, INIT_OS },
};
A little riddle: can you see the bug just be examining that data?
Yes, either the names are wrong in:
static const struct typeinfo ModelAttrValue[] = {
{ STACK_NEAR, INIT_STACK },
{ STACK_FAR, INIT_STACK },
{ OPSYS_DOS, INIT_OS },
{ OPSYS_OS2, INIT_OS },
};
and it must be changed as follows:
static const struct typeinfo ModelAttrValue[] = {
{ NEARSTACK, INIT_STACK },
{ FARSTACK, INIT_STACK },
{ OS_DOS, INIT_OS },
{ OS_OS2, INIT_OS },
};
of the order of OPSYS_DOS and OPSYS_OS2 needs to be swapped.
static const struct typeinfo ModelAttrValue[] = {
{ STACK_NEAR, INIT_STACK },
{ STACK_FAR, INIT_STACK },
{ OPSYS_OS2, INIT_OS },
{ OPSYS_DOS, INIT_OS },
};
If STACK_NEAR, STACK_FAR, OPSYS_OS2, and OPSYS_DOS are defined somewhere outside of your code snippet, then I suspect the latter.
And ultimately, it could be a combination of both, in which case it would need to be changed as follows:
static const struct typeinfo ModelAttrValue[] = {
{ NEARSTACK, INIT_STACK },
{ FARSTACK, INIT_STACK },
{ OS_OS2, INIT_OS },
{ OS_DOS, INIT_OS },
};
It's also possible that the wrong values are being assigned. OPSYS_OS2 and OPSYS_DOS are given exactly the same value. Perhaps one of them should be INIT_LANG? INIT_LANG is not used anywhere and it may well be that the value in the struct is used later for differentiation and is therefore dependent on the correctly assigned value. On the other hand, OS/2 and DOS are both operating systems, so the value INIT_OS could also be correct. It just depends on what the rest of the code says.
QuoteI guess it's a bug that exists since the very beginning of jwasm - that is 03/2008, so it celebrates its 17th birthday these days.
Great, then I found a bug in JWASM, which can be fixed, and JWASM will have one less bug in future versions.
Unfortunately, I don't have a GitHub account and therefore can't create a bug report. If you could report the bug to the developers, that would be great.
Quote from: bugthis on March 30, 2025, 09:30:04 AMYes, either the names are wrong in:
...
and it must be changed as follows:
...
of the order of OPSYS_DOS and OPSYS_OS2 needs to be swapped.
Yes, that's a cigar! This syntax is hardly used ever. Masm v6 knows "OS_DOS" only, since MS removed everything related to OS/2 from their tools in the early 1990s ( not even the -Zm switch to enable Masm v5 compatibility will change that ).
QuoteGreat, then I found a bug in JWASM, which can be fixed, and JWASM will have one less bug in future versions.
Unfortunately, I don't have a GitHub account and therefore can't create a bug report. If you could report the bug to the developers, that would be great.
Yes, will do that ASAP.
Quote from: _japheth on March 30, 2025, 06:13:32 PMYes, that's a cigar! This syntax is hardly used ever. Masm v6 knows "OS_DOS" only, since MS removed everything related to OS/2 from their tools in the early 1990s ( not even the -Zm switch to enable Masm v5 compatibility will change that ).
That's good to know.
QuoteQuoteGreat, then I found a bug in JWASM, which can be fixed, and JWASM will have one less bug in future versions.
Unfortunately, I don't have a GitHub account and therefore can't create a bug report. If you could report the bug to the developers, that would be great.
Yes, will do that ASAP.
Thank you very much. I just compiled and tested it and it works perfectly with my above hellowld.asm file. However, there were some issues with compiling, see below.
In your commit log you wrote the following:
https://github.com/Baron-von-Riedesel/JWasm/commit/59e0bd32218609f145db17bcfd2eb7c9101f0637
Quote- .model directive: os qualifier (OS_DOS,OS_OS2) never worked; see
startup5.asm.
I couldn't find a file called startup5.asm in the code tree:
https://github.com/Baron-von-Riedesel/JWasm/tree/master
And then I noticed something else while unpacking on a FAT16 file system. The file
Samples/Win32DrvA.asm is too long for the 8.3 file system, so you're asked if you want to overwrite the previously unpacked file
Samples/Win32Drv.asm.
Since this is a file for Windows, hopefully not for Windows 3.x with the 32-bit Win32s extension installed, I'm assuming this is irrelevant for DOS if you overwrite the file and then don't need it in DOS anyway. But I'll mention it for the sake of completeness.
If this could also be important under Windows 3.x, I would suggest renaming the file to a short 8.3 filename.
Renaming
Samples/Win32DrvA.asm to
W32DrvA.asm did work for me.
I haven't compiled Win32DrvA, though. If that were necessary, the Makefiles and some other files in Samples would still need to be adapted, as the following output shows.
grep Win32DrvA.asm *
MAKE.BAT:if exist "\WinInc" JWasm -nologo -coff Win32DrvA.asm
Readme.txt: Win32DrvA.asm Win32 coff console loads Win32Drv.sys
Win32DrvA.asm:;--- assemble: jwasm -coff Win32DrvA.asm
Win32Drv.asm:;--- to run the driver, assemble, link and run the Win32DrvA.asm service control program.
Win32Drv.asm:;--- define control code. this code must match the one in Win32DrvA.asm.Now to the problems with compiling:
The Makefile OWDOS16.MAK for OpenWatcom had to be modified.
The Makefile states:
!else
OUTD=build\OWDOS16R
!endif
...
$(OUTD):
@if not exist $(OUTD) mkdir $(OUTD)
...
When I ran
wmake -f OWDOS16.mak, the
BUILD\OWDOS16R directory couldn't be created, and make freezes. I had to reboot the computer.
MKDIR isn't able to create two-level directories in one step.
However, manually creating the build directory before running wmake worked.
mkdir build
The subdirectory OWDOS16R was then created automatically without errors using the Make script.
To fix the error, I would suggest changing the Makefile to first check if a build directory exists and then create it before continuing with the subdirectory.
Neither MKDIR from MS-DOS 6.22, nor DR-DOS 7.03 or FreeDOS 1.3 can create multilevel directories with subdirectories in one step.
But then I got another error message when running wmake -f OWDOS16.mak.
Error(E14): Cannot execute (\Watcom\binnt\wcc): Argument list too big
Error(E42): Last command making (build/owdos16r\apiemu.obj) returned a bad status
Error(E02): Make execution terminated
The build\owdos16r directory was still empty after that.
I don't know if this is helpful, but my environment variables look like this. The command "set" outputs this:
DOSDRV=C:
LANG=DE
TZ=UTC
PATH=C:\DEVEL\WATCOMC\BINW;C:\DEVEL\JWASM;C:\WORK\BIN;C:\FreeDOS\BIN;C:\FREEDOS\LINKS
WORKDIR=C:\WORK\BIN;
JWASMDIR=C:\DEVEL\JWASM;
NLSPATH=C:\FreeDOS\NLS
HELPPATH=C:\FreeDOS\HELP
TEMP=C:\FreeDOS\TEMP
TMP=C:\FreeDOS\TEMP
BLASTER=A220 I5 D1 H5 P330
DIRCMD=/OGN /Y
COPYCMD=/-Y
OS_NAME=FreeDOS
OS_VERSION=1.3
AUTOFILE=C:\FDAUTO.BAT
CFGFILE=C:\FDCONFIG.SYS
CDROMID=FDCDX001
CDROM=D:
INCLUDE=C:\DEVEL\WATCOMC\H
EDPATH=C:\DEVEL\WATCOMC\EDDAT
WATCOM=C:\DEVEL\WATCOMC
Since I wasn't able to build the 16-bit JWASM binary with OpenWatcom, I decided to use the GccDOS.mak makefile with DJGPP to build a 32-bit PM and DPMI enabled binary with GCC.
That worked, but the build directory had to be created manually too because MKDIR wasn't able to create a directory with subdirectories in one step.
Here the GccDOS.mak Makefile should also be adjusted to check if the build directory exists and if not, it should be created before subdirectories are created.
For setting the environment variables of OpenWatcom and GCC I have two separate batch files, which is why my environment variables for GCC change to the following values without the Watcom entries:
... ; Entries as above without the Watcom stuff
PATH=C:\DEVEL\DJGPP\BIN;C:\DEVEL\JWASM;C:\WORK\BIN;C:\FreeDOS\BIN;C:\FREEDOS\LINKS
... ; Entries as above without the Watcom stuff
DJGPP=C:\DEVEL\DJGPP\DJGPP.ENV
I would also recommend adding at the top of the Watcom Makefile OWDOS16.mak the following line, so that the users can read how to use it with OpenWatcom:
# 'wmake -f OWDOS16.mak'
The same applies to OWDOS32.mak. OWDOS32.mak does btw. have the same problem according creating the build directory and its subdirectory. mkdir just can't create multilevel directories in one go. Other Makefiles suitable for DOS may also be affected.
The Makefile GccDOS.mak for DJGCC contains such a tip, so you don't have to search for long:
# This makefile creates the JWasm 32-bit DOS binary with DJGPP.
# 'make -f GccDos.mak'
To fix some of the above errors in the OWDOS16.mak and possibly also OWDOS32.mak Makefile, the following corrections must be made:
1. Using an editor with Search & Replace function, all strings named "BINNT" must be replaced with "BINW". The reason is that the Open Watcom compiler and linker are located in the BINW directory in DOS, not in the BINNT directory. This applies in particular to the OpenWatcom package from FreeDOS.
2. Next, at the very beginning of the Makefile, the entry
!ifndef WATCOM
must be replaced with
!ifndef %WATCOMOtherwise, the Makefile cannot access the DOS environment variable WATCOM. It's important that there is no % sign at the end of the entry; this would be different in a normal DOS batch file.
3. The same steps will likely need to be performed for the
!ifndef DEBUG entry directly below, replacing it with
!ifndef %DEBUG if you want to reference a DOS environment variable named DEBUG here.
The same applies to the !ifndef TRMEM entry.
If you do that, the E14 error will at least point to the correct directory where WCC.EXE, WLINK.EXE and WLIB.EXE is located.
Error(E14): Cannot execute (\binw\wcc): Argument list too big
Unfortunately, the argument list is still too long. I don't know how to fix this error. I'm not familiar enough with Watcom Makefiles and it could also be related to DOS and its maximum line length.
Quote from: bugthis on March 31, 2025, 12:14:24 PMTo fix some of the above errors in the OWDOS16.mak and possibly also OWDOS32.mak Makefile, the following corrections must be made:
No, those makefiles all run fine in DOS, but need the HX DOS extender ( and the extender's HXLDR32 TSR loaded ). Additionally, I guess the DOSLFN TSR must be loaded to activate LFN support.
Quote from: _japheth on March 31, 2025, 01:31:48 PMNo, those makefiles all run fine in DOS, but need the HX DOS extender ( and the extender's HXLDR32 TSR loaded ). Additionally, I guess the DOSLFN TSR must be loaded to activate LFN support.
Couldn't you adapt the Makefile so that it can also be compiled on an 8086 or 286 on a FAT16 file system without LFN support? LFN support is also only available starting with MS-DOS 7.0, which is included with Windows 95b.
It would be a pity if you couldn't "bootstrap" the 16-bit Real Mode JWASM binary on a 16-bit x86 machine.
Hi,zedd151
QuoteThis is the 21st century. DOS is still stuck in 1980ish, imo. I just don't get it... at all.
Nowadays, most industrial automation control systems still use 16bit CPU.
Quote from: six_L on March 31, 2025, 02:22:38 PMHi,zedd151
QuoteThis is the 21st century. DOS is still stuck in 1980ish, imo. I just don't get it... at all.
Nowadays, most industrial automation control systems still use 16bit CPU.
I did not (obviously) know that. Thank you six_L. :smiley:
I wouldn't think though, that they are conceivably running MS-DOS or a derivative. More likely a different
proprietary OS, designed specifically for the task.
Quote from: zedd151 on March 31, 2025, 02:13:30 PMI still don't understand though.
I like DOS. Not for nostalgic reasons, but since it allows hardware and PL0 access. So I can easily experiment with CPU "alignment checks" or MSR registers or mode switches between 16-bit and 64-bit, all things that are strictly forbidden for you "Windoze guys" :biggrin: .
Quote from: bugthis on March 31, 2025, 02:06:28 PMCouldn't you adapt the Makefile so that it can also be compiled on an 8086 or 286 on a FAT16 file system without LFN support? LFN support is also only available starting with MS-DOS 7.0, which is included with Windows 95b.
Yes, OWDOS16.MAK may be changed so it runs on a 8086. I'm prettty sure it will run without LFN even now.
A mechanic I know still uses a 386 with MS-DOS 5 because his emissions program is from 1993 and he's not willing to spend $5000 per year for the latest version (which is no different in capabilities). Mind you, he is 88 years old and a bit set in his ways :biggrin: He is the guy that young revheads go to when their cars get defected and need a police inspection to be re-registered. The cops have given up giving him a hard time, as he has never failed an inspection.
Like _japheth said, there's something satisfying about booting from your floppy image and seeing "Hello 64-bit world" on the monitor :cool:
I was going to write, contrary to what Zedd did, how gratifying it is to see such loving care tendered towards such "obsolete" software, which is obviously still much used, despite what all the future-fanbois tell us.
Quote from: bugthis on March 31, 2025, 02:06:28 PMIt would be a pity if you couldn't "bootstrap" the 16-bit Real Mode JWASM binary on a 16-bit x86 machine.
Hmm, but there's no wccr.exe on Open Watcom - that is, the 16-bit compiler must at least run on a 80386 machine, in protected-mode, with more than 1 MB RAM ( same is true for the linker ). So there's probably no chance for realization of your idea.
Quote from: _japheth on April 01, 2025, 12:09:10 PMHmm, but there's no wccr.exe on Open Watcom - that is, the 16-bit compiler must at least run on a 80386 machine, in protected-mode, with more than 1 MB RAM ( same is true for the linker ). So there's probably no chance for realization of your idea.
True. However, it should be possible to adapt the Makefile so that it also works on a filesystem without LFN support. This would at least allow JWASM to be compiled on 32 bit x86 computers running MS-DOS <= 6.22 without LFN support. Many people have MS-DOS installed on old retro computers because they already have a license and compatibility with DOS programs, especially Windows 3.1 in enhanced mode, is usually still better than FreeDOS. So it would be great if JWASM could be compiled on these computers.
Quote from: _japheth on March 31, 2025, 01:31:48 PMNo, those makefiles all run fine in DOS, but need the HX DOS extender ( and the extender's HXLDR32 TSR loaded ).
I strongly doubt that. The Open Watcom Makefile looks in the BINNT directory for its compiler file WCC.EXE, but in DOS WCC.EXE is not in BINNT. The same applies for WLINK.EXE and WLIB.EXE.
See my point 1 in my previous comment.
https://masm32.com/board/index.php?topic=12667.msg137721#msg137721 (https://masm32.com/board/index.php?topic=12667.msg137721#msg137721)
These Open Watcom Makefiles may work in CMD from Windows 10 because in Windows 10, which belongs to WinNT series, you can find the compiler in the BINNT64 directory there, but definitely not in DOS.
See the attached files:
tree_win10.txt
exe_files_win10.txt
tree_utf8_dos.txt
exe_files_dos.txt
They show the output of tree or the output of searching for all EXE files in the Open Watcom compiler directory under Windows 10 and FreeDOS for comparison. The makefiles cannot work at all in DOS because the compiler is searched in the wrong location.
These are the lines with the error that point to binnt and what should be binw in ODDOS16.mak Makefile for DOS.
$ grep binnt OWDOS16.mak
LINK = $(WATCOM)\binnt\wlink.exe
CC=$(WATCOM)\binnt\wcc -q -0 -w3 -zc -ml -bc -bt=dos $(inc_dirs) $(extra_c_flags) -fo$@ -DFASTMEM=0 -DFASTPASS=0 -DCOFF_SUPPORT=0 -DELF_SUPPORT=0 -DAMD64_SUPPORT=0 -DSSSE3SUPP=0 -DSSE4SUPP=0 -DOWFC_SUPPORT=0 -DDLLIMPORT=0 -DAVXSUPP=0 -DPE_SUPPORT=0 -DVMXSUPP=0 -DSVMSUPP=0 -DCVOSUPP=0 -DCOMDATSUPP=0 -DSTACKBASESUPP=0 -zt=12000
$(WATCOM)\binnt\wlib -q -n $(name).lib $(proj_obj:$(OUTD)/=+)
LFN might be an additional problem that prevents it from compiling, at least under MS-DOS <= 6.22 without LFN support.
And as for the HT DOS extender, OpenWatcom ships with DOS4G/W in FreeDOS as a DOS extender. It's located in the binw directory.
The error E14 has something to do with the path length.
Here's the output of wmake with my corrections made in comment #6. Without them, the compiler wouldn't even look in the correct directory.
(https://i.postimg.cc/kBWJ3CDb/output-of-wmake-with-my-added-corrections.png) (https://postimg.cc/kBWJ3CDb)
Quote from: bugthis on April 02, 2025, 05:15:56 PMI strongly doubt that. The Open Watcom Makefile looks in the BINNT directory for its compiler file WCC.EXE, but in DOS WCC.EXE is not in BINNT.
Well, you can install the BINNT tools in DOS - that's not forbidden and that's what's needed to create the Jwasm binaries (Windows and DOS). The tools in OW's BINW directory are to be avoided, simply because I don't want to test them and hence don't want to use them.
But you got a point with the MKDIR limitation in DOS - originally for JWasm there were just 2 output directories (Release and Debug), but this has been changed later and the Makefiles for DOS haven't been adjusted yet. Will be done.
QuoteLFN might be an additional problem that prevents it from compiling, at least under MS-DOS <= 6.22 without LFN support.
Perhaps. However, anyone who's indeed interested in that matter will be knowledgeable enough to fix those problems, if they exist - you're the best example. So nothing to be done on my part.
Quote from: _japheth on April 03, 2025, 12:31:39 AMWell, you can install the BINNT tools in DOS - that's not forbidden and that's what's needed to create the Jwasm binaries (Windows and DOS).
This is not how the fdimples package is configured in FreeDOS for OpenWatcom, it is also not the location in the official Open Watcom package, see the Readme.txt below. It would bypass the package system and would therefore require additional work all the time when installing or uninstalling OpenWatcom in FreeDOS. And not just for me, but for all other users who want to build JWASM from source code with OpenWatcom under DOS.
QuoteThe tools in OW's BINW directory are to be avoided, simply because I don't want to test them and hence don't want to use them.
You could install FreeDOS in a Virtual Machine (Virtualbox/Qemu etc.). From there you can install OpenWatcom via the FreeDOS fdimples package system to have a test environment.
fdimples is FreeDOS package system and an easy to use GUI:
https://opensource.com/article/21/6/freedos-package-manager
(https://opensource.com/article/21/6/freedos-package-manager)
From the readme.txt of OpenWatcom 1.9:
...
For proper operation the Open Watcom compilers require few environment
variables to be set up correctly. These variables differ slightly depending
on the host platform (DOS, OS/2, Win32). The common variables are:
- PATH - points to directories containing Open Watcom executables
...
DOS specifics
- PATH - only needs to point to the binw directory
- WWINHELP - points to the directory on the CDROM drive where help files
are located. This minimizes hard disk space. Note this is not
needed if the help files are installed on the hard disk
Win16 specifics
- PATH - only needs to point to the binw directory
- WWINHELP - points to the directory on the CDROM drive where help files
are located. This minimizes hard disk space. Note this is not
needed if the help files are installed on the hard disk
Win32 specifics
- PATH - must point to binnt and binw directories, in that order
- WWINHELP - points to the directory on the CDROM drive where help files
are located. This minimizes hard disk space. Note this is not
needed if the help files are installed on the hard disk
binnt directory is for Win32 only. It is not for DOS.
For DOS and Win16 binw is used.
See the attachment for the whole readme.txt
readme.txt
It can be also found in the official OpenWatcom 1.9 package:
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/c/openwatcom/1.9/ (https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/c/openwatcom/1.9/)
You could also simply set a DOS target in the Makefile or use the Makefile to run an IF statement to check whether the system is running DOS and then execute a different branch.
The Makefile is also called OWDOS16.mak, so it should also be suitable for DOS. For Windows, there is OWWin32.mak available.
Especially since a Makefile for DOS is unlikely to change much, because MS-DOS is no longer a moving target.
QuoteBut you got a point with the MKDIR limitation in DOS - originally for JWasm there were just 2 output directories (Release and Debug), but this has been changed later and the Makefiles for DOS haven't been adjusted yet. Will be done.
Thanks
QuotePerhaps. However, anyone who's indeed interested in that matter will be knowledgeable enough to fix those problems, if they exist - you're the best example.
That's what i did and tried, but i said:
Quote from: bugthis on March 31, 2025, 12:14:24 PMUnfortunately, the argument list is still too long. I don't know how to fix this error. I'm not familiar enough with Watcom Makefiles and it could also be related to DOS and its maximum line length.
So I can't get any further here.
Quote from: bugthis on April 03, 2025, 01:35:25 AMUnfortunately, the argument list is still too long. I don't know how to fix this error. I'm not familiar enough with Watcom Makefiles and it could also be related to DOS and its maximum line length.
So I can't get any further here.
That's one of the reasone why I avoid the various Watcom DOS extenders - they have limitations that HX does NOT ( after all, it's my child, even more than JWasm :biggrin: ). And I don't care much what FreeDOS or OW suggest - the quality of those advices and the quality of their documentations are "mixed".
Actually, the "DOS versions" of JWasm are just an add-on - originally, I just supplied a Win32 version - and used HX to run this binary in DOS.
Quote from: _japheth on April 03, 2025, 03:40:04 AMQuote from: bugthis on April 03, 2025, 01:35:25 AMUnfortunately, the argument list is still too long. I don't know how to fix this error. I'm not familiar enough with Watcom Makefiles and it could also be related to DOS and its maximum line length.
So I can't get any further here.
That's one of the reasone why I avoid the various Watcom DOS extenders - they have limitations that HX does NOT ( after all, it's my child, even more than JWasm :biggrin: ). And I don't care much what FreeDOS or OW suggest - the quality of those advices and the quality of their documentations are "mixed".
Actually, the "DOS versions" of JWasm are just an add-on - originally, I just supplied a Win32 version - and used HX to run this binary in DOS.
And what does the DOS Extender have to do with an argument list that is too long?
Wouldn't it be more likely that the command line length has something to do with COMMAND.COM and the memory size? I'll test tomorrow to see if changing the value using the /e:[Bytes] parameter helps.
And if that's the case, then it should also be possible to modify the wmake script so that it can handle the default length of the command line that is normal in DOS.
Quote from: bugthis on April 03, 2025, 05:55:30 AMAnd what does the DOS Extender have to do with an argument list that is too long?
Well, HX supports the CMDLINE environment variable, that overcomes the 126 byte cmdline limit of DOS. IIRC it was introduced with MS-DOS 7 (Win9x).
Quote from: _japheth on April 03, 2025, 07:29:52 AMWell, HX supports the CMDLINE environment variable, that overcomes the 126 byte cmdline limit of DOS. IIRC it was introduced with MS-DOS 7 (Win9x).
MS-DOS 7 is limited to 260 characters, due to the MAX_PATH limitation of the Windows API in Windows 9x.
FreeDOS COMMAND.COM FreeCOM is limited to 255 Bytes. And changing the input buffer with /U:nnn is still not implemented. It wouldn't help anyway, since the maximum is 255 bytes anyway. And that is currently the default in FreeCOM. Playing with /E:nnnn wasn't a solution either.
So this morning I did a bit of research in the Watcom documentation. There are two ways to solve the problem.
1. The use of response files.
All compiler options + source files to be compiled are put into a response file *.rsp and then referenced in the Watcom Makefile when the compiler is called.
or
2. The use of compiler directives in a header file.
All compiler options currently used as parameters in your Makefile related to OpenWatcom will be placed in their own header file, for example "wc_def.h".
This header file can then be included in the source code using an ifdef __WATCOMC__ query for the Watcom compiler.
#ifdef __WATCOMC__
#include "wc_def.h"
#endif
So which variant would you prefer? Which would you incorporate into JWASM?
Quote from: bugthis on April 03, 2025, 11:18:54 PMSo which variant would you prefer? Which would you incorporate into JWASM?
I'm afraid none. Aren't you aware of inline files in a makefile (https://learn.microsoft.com/en-us/cpp/build/reference/inline-files-in-a-makefile?view=msvc-170)? That also works for OW's wmake. If you'd bothered to look at OWWIN32.mak/OWDOS32.mak you'd have noticed its usage. It's trivial. Surely no problem at all for you to adjust OWDOS16.mak accordingly.
Quote from: _japheth on April 04, 2025, 04:26:30 AMI'm afraid none. Aren't you aware of inline files in a makefile (https://learn.microsoft.com/en-us/cpp/build/reference/inline-files-in-a-makefile?view=msvc-170)? That also works for OW's wmake. If you'd bothered to look at OWWIN32.mak/OWDOS32.mak you'd have noticed its usage. It's trivial. Surely no problem at all for you to adjust OWDOS16.mak accordingly.
The files OWWIN32.mak/OWDOS32.mak don't look like they use inlining. In Watcom this would be possible with %write, which is not present in your two files. In that respect, yes, I could also do it with a temporarily created file.
To avoid overwriting user files, I suggest writing this temporary file to the build folder.
Using a TEMP directory would also be possible, but this is rather uncommon in DOS, and there's also a risk of overwriting something else. The build folder, on the other hand, belongs solely to JWASM.
Quote from: _japheth on April 04, 2025, 04:26:30 AMI'm afraid none. Aren't you aware of inline files in a makefile (https://learn.microsoft.com/en-us/cpp/build/reference/inline-files-in-a-makefile?view=msvc-170)? That also works for OW's wmake. If you'd bothered to look at OWWIN32.mak/OWDOS32.mak you'd have noticed its usage. It's trivial. Surely no problem at all for you to adjust OWDOS16.mak accordingly.
I'm still waiting for an answer as to whether you would accept the fix as a patch and implement it. See my previous comment.