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]

I will hold compatibility with OW 1.9 because it is last oficial release and most of user could use it for build. It is user decision if will use OW1.9 or OW2.0.

[joncampbell123]

@jmalak Ok. I develop against OW 2.0, but if OW 1.9 is wanted, I'll try to support it, or #ifdef code out that cannot compile with it.

[jmalak]

on tools level it is not problem OW 2.0 is backward compatible with OW1.9 that if it is working with OW 1.9 then it must works with OW2.0. But if you use some OW2.0 new features then it doesn't work with OW1.9 But I don't thing that you use something specific for OW2.0

[joncampbell123]

Did it compile OK?

[jmalak]

I have a question about *.mak files It is used by OW only or by GCC too?

It compiles with some issues but it is related to missing tools which I need to install on my test box.

[joncampbell123]

*.mak files are for wmake and Makefile files are for GNU make.

[joncampbell123]

Which part is failing to compile?

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