Cleanup Watcom compilation, setup, as recommended by @jmalak, and remove old sarcastic remarks that have outlived their usefulness.

[jmalak]

Please what is purpose of linux-ow.sh and owenv.sh script files?
I don't understand why it has complete messy INCLUDE environment variable.
Why OW tools setup is for 32-bit Windows if you compile for different targets?
It results in following wrong message in shell scripts

"# why is this even necessary? why does dumbshit Watcom insist on including the WINNT headers for Windows 3.1 builds?"

It is caused by previous wrong OW setup.
in other files <os>_INCLUDE variables are used and wrongly combined with INCLUDE variable.

Such OW setup can cause some hiden mistakes etc.

You should handle cross-compilation one way only, don't mix multiple mechanism.

• full handling by <os>_INCLUDE and INCLUDE variables
• full handling by command line -I option

By example OW build system is fully cross-compilation system and it uses "full handling by command line -I options" for flexibility.
It requires to ignore all ..INCLUDE variables, it is ensured by using -x compiler option.
I thing for your project you could use aproach with <os>_INCLUDE and INCLUDE variables

[joncampbell123]

That's a mess from 10+ years ago that probably needs to be cleaned up, yes.

All I cared about when I started DOSLIB in 2008 was making it work, not necessarily cleanly. The makefile system eventually came around through hacks in it's current form by 2012.

[joncampbell123]

At the time I had Open Watcom 1.8, then Open Watcom 1.9.

[joncampbell123]

My primary development environment with Open Watcom is on 64-bit Linux. It was on 32-bit Linux when I started, but I eventually made the jump to 64-bit and stuck with it.

[jmalak]

I understand, but this cross-compilation stuff is-not changed by OW any way.
It is same as for WATCOM 11.x

[jmalak]

generaly you should have configured OW for host system and next switch compilation anvironment for target system appropriate way

[joncampbell123]

linux-ow.sh was made so that DOSLIB can compile without having to first source the Watcom environment script.

owenv.sh was made for @sparky4 so that "Project 16" can use DOSLIB as well.

[jmalak]

I am involving into it due to @sparky4 has repeated problems with building by OW
I can prepare some fix to handle it proper way for your review

[joncampbell123]

@jmalak Sounds good to me. I'll remove the sarcastic remarks on my end.

[jmalak]

no problem with notes, we need to fix source of problem

[jmalak]

I think that linux-ow.sh can be removed at all
Only proper setup of OW for host is necessary before start of doslib build

[joncampbell123]

linux-ow is not just the OW environment, it also contains the build target list handling.

There are also functions in there to locate a 32-bit GCC 7.1.0 for an experimental project to compile Windows 3.1 .386 / .VXD drivers using GCC + wlink.

[joncampbell123]

However if you mean the script code to set WATCOM variables should be removed, I'm fine with that.

[jmalak]

then name is little confusing

[joncampbell123]

There are also stubs in linux-ow.sh from long ago when I allowed the compile steps to ALSO regenerate BAT files that could be used to compile DOSLIB from a pure MS-DOS system directly. Those were hard to maintain so they were removed.

[joncampbell123]

How about removing the WATCOM env setting code and renaming linux-ow.sh to doslib-build-util.sh?

[jmalak]

OK
I will change it that it will work with OW standard setup for Linux

[joncampbell123]

Before you do, I will push a commit to linux-ow.sh that corrects a typo I just noticed regarding targeting Windows 1.x, Windows 2.x, and Windows 3.x

EDIT: OK DONE

[jmalak]

names for file is your business I am not much familiare with purpose of each file

Anyway I will merge on top of main branch and send it as pull request to you to be able review and comment it

[jmalak]

One question about shell definition in the scripts.
Doslib is little inconsistent, somewhere is used !/bin/bash and somewhere !/usr/bin/bash
I think it should be changed to !/bin/bash at all to fix problem which I described in other issue.

[joncampbell123]

@jmalak Agreed.

[jmalak]

I have a problem with testing on my 64-bit system I get error "i386-pc-linux-gnu-ld: not found"
Please what Linux software is required by doslib build system?
Is it better to test it on 32-bit Linux system?

[joncampbell123]

@jmalak You're probably trying to compile the Windows .386/.VXD code in windrv/dosboxpi/win9x. You can skip that directory, the VXD is useless at this development stage.

[joncampbell123]

It's a fun experiment that combines GCC 7.1.0 with the Open Watcom linker to make a Linear Executable that Windows 3.1 will load as a .386 driver in 386 enhanced mode. Hopefully it will be able to make .VXD files for Windows 95 as well someday.

[jmalak]

I am trying to build all to be sure that I didn't break anything.
Is it possible simply exclude this from build?

[joncampbell123]

@jmalak A quick and dirty way is to chmod -x (remove the executable bit from) the make.sh file in the directory you don't want to compile.

buildall.sh will not run it if it's not executable.

[jmalak]

thanks

[joncampbell123]

Thank you for your patience. DOSLIB grew as a bunch of fun experimental hacking and it shows.

[jmalak]

I suppose you want compatibility with OW1.9

[joncampbell123]

Not really. Open Watcom 2.0 has been very good with this code so far.

[jmalak]

Do you use GCC with wmake?

[jmalak]

there is only missing some libraries, but source code is compiled OK

[joncampbell123]

No. I think some *.mak files will invoke GNU make for some libraries in ext/ though.

[joncampbell123]

Do the compiled EXE and COM files for DOS run?

Most of my development is done either within DOSBox-X or on real hardware over the serial port using the REMSRV.EXE DOS TSR in tool/remctl/serial.

When those are not possible, it's either a USB floppy drive to test it from a disk, or copying the file onto the CF card I boot the old hardware with.

[joncampbell123]

There is also code to compile for NEC PC-98 MS-DOS in hw/necpc98, and each library that supports it has d9886[t,s,m,l,c,h] builds. The code has been tested on real hardware as well.

[jmalak]

I am changing parts related to Linux build

[jmalak]

I submit pullrequest with appropriate change for Linux build.
I hope it doesn't break anything what is build on DOS.

[jmalak]

I found up a few problems with some mixed targets as hw/dosboxid.
There is a problem that target is not defined, by example -bt=... is not defined and therefore it uses default (host system) also header files path list is undefined due to appropriate CFLAGS..... macro is not used there.
I need better understand what targets are used there.

[joncampbell123]

DOSBOXID is meant to target MS-DOS and Windows. The makefile will generate an additional versions that are more appropriate for use within Windows 3.1 drivers and VXDs.

So it should be -bt=dos for MS-DOS and -bt=windows for Windows as appropriate.

The Windows builds also target 32-bit, and the DOS builds will also target PC-98.

[joncampbell123]

I see, the _vxd builds do not provide a -bt value.

[jmalak]

It was my mistake, now I have it working but what value are valid for VXD (TARGET_VXD=1)
TARGET_DOS=?
TARGET_WINDOWS=?

[joncampbell123]

That's a good question. VXDs do not run as Windows applications, they run in a 32-bit kernel atop the Windows environment.

I think DOSLIB should treat VXDs as TARGET_WINDOWS=1 and TARGET_VXD=1

[jmalak]

Now it is build only for these defines
-dTARGET_MSDOS=32 -dTARGET_WINDOWS=31 -dTARGET86=386 -DMMODE=f
-dTARGET_MSDOS=32 -dTARGET_WINDOWS=40 -dTARGET86=386 -DMMODE=f

[jmalak]

I think it will require new target make file for VXD to include correct header files path and -bt target
for Windows 3.x it should be as WIN386 -bt=windows and 386 CPU flat memory model.
But I dont know what format for Windows 95.

[joncampbell123]

Windows 95 VXDs use the same linear executable format as Windows 3.1 386 files.

[joncampbell123]

I should really separate the Windows VXD code out so it doesn't fail the compile.

It's very experimental and shouldn't be built by default.

I don't expect everyone to have the same GCC 7.1.0 + OW setup I do.

[joncampbell123]

Is code compiled with Open Watcom supposed to refer to dsound.h as <direct/dsound.h> or should it be accessible as <dsound.h>?

DOSAMP isn't compiling right now.

Open Watcom has nt/directx/dsound.h

[jmalak]

It is fixed now by adding directx SDK to the include path list

[jmalak]

I will fix -bt=... option, it must be always defined for proper value.
It will be:

Win3.1 (16/32 bit) -> -bt=windows  -> __WINDOWS__     $WATCOM/h;$WATCOM/h/win
Win32(s)           -> -bt=nt       -> __NT__          $WATCOM/h;$WATCOM/h/nt
WindowsNT          -> -bt=nt       -> __NT__          $WATCOM/h;$WATCOM/h/nt
16-bit OS/2        -> -bt=os2      -> __OS2__         $WATCOM/h;$WATCOM/h/os21x
32-bit OS/2        -> -bt=os2      -> __OS2__         $WATCOM/h;$WATCOM/h/os2
16-bit DOS         -> -bt=dos      -> __DOS__         $WATCOM/h
32-bit DOS         -> -bt=dos      -> __DOS__         $WATCOM/h

[jmalak]

After fixing targets zlib code diagnose problem with multiple OS_CODE macro definition which are not same.
It looks like some mismatch between AUTOMAKE environment (config.h) and OW definitions.
Zlib code is not aware about OW compiler, that configuration (in config.h) is probably wrong.
Please review it.

[jmalak]

I think now main changes are finished. Following review/correction should be done.

• each compiler command line must have defined -bt=... option valid for build target (it is defined in "co...mak" make files)
• each compiler command line must have defined -I"..." option with OW header path valid for build target (it is defined in "co...mak" make files)
• each linker command line must have defined "system" or "format" directive valid for build target (it is defined in "co...mak" make files)

[joncampbell123]

@jmalak Will check. Thank you for your help. Does this help @sparky4 as well?

[jmalak]

I suppose yes, now build of doslib shoud not depend on OW configured target (environment variables), only required executable on the PATH and defined WATCOM environment variable.
Theoreticaly if your build system will be ported to other host OS then you don't need to change anything in doslib wmake make files and it should work (I mean OW related things).

[jmalak]

One note about -zw option.
If you use it for any target then it defines __WINDOWS__ macro and it completely confuse header files and can confuse conditionaly code if you use it for non-Windows 3.x environment.
I fixed appropriate make files to be used -zw option only with -bt=windows (Windows 3.x 16-bit or OW 32-bit extender). It could break some code which relate to something specific for 16-bit Windows even if it was non-Windows target as OS/2, NT or DOS.

[joncampbell123]

@jmalak That makes sense, -zw means "generate code for Microsoft Windows".

Could the compiler print a warning if -zw is used for anything other than Windows?

[jmalak]

I have a few ideas how you can improve/simplify OW wmake make files (compatible with both versions OW1.9 and OW2.0) and be more cross-platform independent (independent on host where run)

• !include directive is capable to use '/' as path separator, then you should use forward slash instead of back slash, double quotes have sense only for path with spaces

!include test/test/make.mak     # it is correct for all host platforms`

• macros for linker, you use library <name of library>, better is to use only <name of library> because such macros can be used for dependencies, to combine multiple libraries and also for linker by library {list of macros with libraries}. The same note for object file.

LIBS = $(LIB1) $(LIB2) test.lib ...
OBJS = $(OBJ1) $(OBJ2) test.obj ...

test.exe : $(OBJS) $(LIBS)
   *wlink name test.exe library { $(LIBS) } file { $(OBJS) }

• macros for librarian, you have doubled list of object files, one for dependencies and one for library command list. Better is to use macro as template for both and expand it for differend macro values, see example below

OBJS = $(PRFX)obj1.obj $(PRFX)obj2.obj

PRFX = <object path>
LIB_OBJS = $+$(OBJS)$-  # LIB_OBJS is expanded to "<object path>obj1.obj <object path>obj2.obj"
PRFX = -+<object path>
LIB_CMDS = $+$(OBJS)$-  # LIB_CMDS is expanded to "-+<object path>obj1.obj -+<object path>obj2.obj"

test.lib : $(LIB_OBJS)
   *wlib test.lib $(LIB_CMDS)

[jmalak]

OW has many options and it is not possible to restrict user to use some combination because it can be wanted, in your case you can still use -zw with non-Windows platforms but you must be aware of its behaviour
Generaly OW supposes that user know what is doing

[jmalak]

I think -zw option is historical for 16-bit Windows
Be aware that similar option -zW is important for Windows 3.x code

[jmalak]

there is also -zws option (all -z{w|W}* options are related only to 16-bit Windows or OW 32-bit extender) and should not be used with other targets

[jmalak]

Note to VXD target definition file mak/vxd31.mak.
I defined -bt=dos and -I"%WATCOM/h" to be relatively neutral as 32-bit DOS.
Anyway you need VXD Development kit which has all necessary header files for VXD development (all function which can be used from other VXD modules) etc.
I am not sure if use 32-bit extended DOS is possible in VXD module, but DPMI could be available.
It is neutral flat memory model which can not use any 16-bit windows definition.
It can be change, I have no experiencies with it.