Watt-32 icon indicating copy to clipboard operation
Watt-32 copied to clipboard

compiling with Open Watcom 2

Open sparky4 opened this issue 2 months ago • 6 comments

i noticed that compiling https://github.com/gvanem/Watt-32 and https://github.com/sezero/watt32 are the same repo

so compiling for my fdnpkg16 project i found problems compiling for 16 bit large mode on open watcom 2 and there is stack overflow problems with open watcom 2.0

there is an error compiling neterr.c with the sys error list being already defined not to mention the stack over flow issues i do not get in 1.9 but i do get in 2.0 with a compiled 2.0 library in large mode https://github.com/sparky4/fdnpkg16 here is the repo of the project so far.

i am going to push what i have so far up soon so gimmie a second

sparky4 avatar Sep 30 '25 21:09 sparky4

2.0 compatibility and functionality is not there yet. i can tell. i can only compile this and get it to work on 1.9 there is a bug in 1.9 that prevents floating point processor emulation from working and freezes the system. hence why i tried 2.0. i wish wattcp did not use the fpu

ok git repo updated

sparky4 avatar Sep 30 '25 22:09 sparky4

Is there a question for me in the above? AFAICS, Watcom is a dead project. Use something else or complain to them.

gvanem avatar Oct 01 '25 11:10 gvanem

yeah it is active. as Open Watcom 2.0 https://github.com/open-watcom/open-watcom-v2 they just committed 16 hours ago

sparky4 avatar Oct 02 '25 03:10 sparky4

but ill ask them

sparky4 avatar Oct 02 '25 03:10 sparky4

I've compiled my own (and other peoples) programs as 16-bit large model DOS applications that include wattcp with Open Watcom 1.9 then run them on machines without a FPU before. I doubt that's the problem.

When I ran the testhttp.exe binary in your repository. It did indeed softlock DOS but not before printing the download size of the file as almost what it should be when completed.

I haven't looked over the source code in detail but I have seen this issue before in other http clients and have a hunch that you should check that the content-length header is being parsed correctly. If it isn't then http clients will sit and wait for additional data that will never come.

Lethja avatar Oct 02 '25 07:10 Lethja

The soft locking is from the buggy 1.9 FPU emulation library of open watcom 1.9. which is why i want this project to be compilable on 2.0. when i compile with the 2.0 version it will stack overflow all programs that use watt32

sparky4 avatar Oct 02 '25 08:10 sparky4