JWASM: ERROR A2030: Instruction or register not accepted in current CPU mode

[_japheth]

It 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.

[bugthis]

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.

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.

[bugthis]

No, 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

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:
You cannot view this attachment.
You cannot view this attachment.
You cannot view this attachment.
You cannot view this attachment.

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.

Code Select Expand

$ 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.

[_japheth]

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.

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.

LFN 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.

[bugthis]

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).

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.

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.

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


From the readme.txt of OpenWatcom 1.9:

Code Select Expand

...
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
You cannot view this attachment.
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/


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.

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.

Thanks

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.

That's what i did and tried, but i said:

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.

So I can't get any further here.

[_japheth]

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.
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  ). 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.

[bugthis]

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.
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  ). 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.

[_japheth]

And 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).

[bugthis]

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).

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.

Code Select Expand

#ifdef __WATCOMC__
#include "wc_def.h"
#endif

So which variant would you prefer? Which would you incorporate into JWASM?

[_japheth]

So 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? 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.

[bugthis]

I'm afraid none. Aren't you aware of inline files in a makefile? 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.