open-watcom / open-watcom-v2

Open Watcom V2.0 - Source code repository, Wiki, Latest Binary build, Archived builds including all installers for download.

Open Watcom v2 Fork

Project Build Status		Download
	CI Build	Github Release , GitHub Actions Build
	Current Release Build	Github Release , GitHub Actions Build
	Coverity Scan	Analysis Results , GitHub Actions Build
	Releases Archive	All Github Releases
	Wiki Documentation

Welcome to the Open Watcom v2 Project!

For more information about the project and build instructions see the GitHub wiki.

Discuss the Project on GitHub, Reddit or Discord.

GitHub, join the discussion Open Watcom on GitHub

Reddit Server, join the discussion Open Watcom on Reddit

Discord Server for Open Watcom 2.0, use following invite link to setup access to Open Watcom 2.0 Discord server. This Discord Server is moderated by the Open Watcom 2.0 Github group to remove spam, unrelated discussions about personal opinions, etc. It is intended for user and developer assistance with Open Watcom 2.0. It is possible to ask about an older versions of Open Watcom, but it is primarily for Open Watcom V2.

Other general Discord server for "Open Watcom" exists invite link. It is mainly for older versions of Open Watcom.

Official OpenWatcom site only WEB site is up, all other services (bugzilla, Wiki, News server, Perforce) is down for long time, it looks like it is dead.

Source Tree Layout

Open Watcom allows you to place the source tree almost anywhere (although we recommend avoiding paths containing spaces). The root of the source tree should be specified by the OWROOT environment variable in setvars (as described in Build document). All relative paths in this document are taken relative to OWROOT location. Also this document uses the backslash character as a path separator as is normal for DOS, Windows, and OS/2. Of course on Linux systems a slash character should be used instead.

The directory layout is as follows:

bld
  - The root of the build tree. Each project has a subdirectory under
    bld. For example:
      bld\cg       -> code generator
      bld\cc       -> C compiler
      bld\plusplus -> C++ compiler
      (see projects.txt for details)

build
  - Various files used by building tools. Of most interest are the
    *.ctl files which are scripts for the builder tool (see below)
    and make files (makeint et al.).

build\binbuild
  - This is where all build tools created during phase one are placed.

docs
  - Here is everything related to documentation, sources and tools.

distrib
  - Contains manifests and scripts for building binary distribution
    packages.

contrib
  - Third party source code which is not integral part of Open Watcom.
    This directory contains especially several DOS extenders.

rel
  - This is default location where the software we actually ship gets
    copied after it is built - it matches the directory structure of
    our shipping Open Watcom C/C++/FORTRAN tools. You can install the
    system by copying the rel directory to your host and then setting
    several environment variables.

    Note: the rel directory structure is created on the fly. The
    location of rel tree can be changed by OWRELROOT environment
    variable.

OpenWatcom Installation

Installer installation instruction in Documentation (OW Wiki).

OpenWatcom Building

Building instruction in OW Wiki.

Open Watcom Licence

open-watcom-v2's Issues

missing a few headers in wipfc for msvc2012

Im able to do a full build of the 64 bit version but i had to include a few more headers with msvc 2012.

before #include < algorithm > add

include < vector >

include < functional >

and after #include < algorithm > add

include < iostream >

Affects only two files which i dont remember atm. So ill post them later.

Besides that the compiler itself seems to Work though Wiv.exe crashes at exit and bwhc.exe (watcom help compiler) crashes with a heap error so documentation build has to be turned off when compiling the 64 bit version.

missing file ?

yacc -d -db -dd -df -dt -du ....\y\plusplus.y ....\c\yydriver.c >y.out
diff y.out ../../y/plusplus.chk
No such file or directory
Can't open input file "../../y/plusplus.chk": Error(E42): Last command making (y
tab.h) returned a bad status
Error(E02): Make execution terminated
<pmake -d build -h> => non-zero return: 2
Build failed

not sure might have been the chk file being removed by system mechanic when cleaning.

__asm{} segfault

Just try compile this file - wcc.exe segfaulting on it:

unsigned long long dfg16()
{
    unsigned long  long qwe = 7;

    __asm {
        cli;
        jmp er__1;
        data__1 dd 1000 dup(0);
     er__1:
        sti;
        jmp er__2;
        data__2 dd 1000 dup(0);
     er__2:
        cli;
        jmp er__3;
        data__3 dd 1000 dup(0);
     er__3:
        sti;
    }
    return qwe + 8;
}

OWv2.0 build cw32.obj failed

Win7 spk1 64bit machine, perforce release OW19 installed last year so I could build the OW19 nightly build to develop some debugger and trap stuff.
Today took snapshot of the github v2.0 repository and edited setvars.bat to point to my OW19 (win32) release. Also edited doco defines and pointed to my dosbox install, ran this new copy of setvars.bat and generated devguide.pdf :)
Then ran build.bat with no parameters, it ran for 40min and then Kaspersky antivirus decided that bwrc.exe accessing int7r20.dll was infected with packed.win32.krap.ai virus :(
Reconfigured Kaspersky to exclude the OW20 source tree and ran build.bat again.
Nearly an hour later build fails to build cw32.obj
.........
================ 19:49:25 D:\abr_apps\OW20SRC\bld\wstuba\ntx64 ================
=============== 19:49:25 D:\abr_apps\OW20SRC\bld\wstuba\os2386 ================
cp ../dosi86/wstub.exe wstub.exe
reading file ../dosi86/wstub.exe (512 bytes)writing file wstub.exe 512 bytes, 1 files written in 0.00 seconds (dump 1)
cp ../dosi86/wstubq.exe wstubq.exe
reading file ../dosi86/wstubq.exe (640 bytes)writing file wstubq.exe 640 bytes, 1 files written in 0.00 seconds (dump 1)
=================== 19:49:26 D:\abr_apps\OW20SRC\bld\wstuba ===================
**** BUILD rule
================== 19:49:26 D:\abr_apps\OW20SRC\bld\causeway ==================
============ 19:49:26 D:\abr_apps\OW20SRC\bld\causeway\cw32\dosi86 ============
as cw32.obj
....\asm\raw_vcpi.asm(363): Note! N604: Far call is converted to near call.
....\asm\raw_vcpi.asm(368): Note! N604: Far call is converted to near call.
....\asm\raw_vcpi.asm(373): Note! N604: Far call is converted to near call.
....\asm\raw_vcpi.asm(378): Note! N604: Far call is converted to near call.
....\asm\cw32.asm(941): Note! N594: Extending jump
....\asm\cw32.asm(956): Note! N594: Extending jump
....\asm\cw32.asm(975): Note! N594: Extending jump
....\asm\cw32.asm(4511): Note! N594: Extending jump
....\asm\cw32.asm(4520): Note! N594: Extending jump
....\asm\cw32.asm(4522): Note! N594: Extending jump
....\asm\cw32.asm(4524): Note! N594: Extending jump
....\asm\cw32.asm(941): Note! N594: Extending jump
....\asm\cw32.asm(956): Note! N594: Extending jump
....\asm\cw32.asm(975): Note! N594: Extending jump
....\asm\cw32.asm(4511): Note! N594: Extending jump
....\asm\cw32.asm(4520): Note! N594: Extending jump
....\asm\cw32.asm(4522): Note! N594: Extending jump
....\asm\cw32.asm(4524): Note! N594: Extending jump
....\asm\cw32.asm(941): Note! N594: Extending jump
....\asm\cw32.asm(956): Note! N594: Extending jump
....\asm\cw32.asm(975): Note! N594: Extending jump
....\asm\cw32.asm(4511): Note! N594: Extending jump
....\asm\cw32.asm(4520): Note! N594: Extending jump
....\asm\cw32.asm(4522): Note! N594: Extending jump
....\asm\cw32.asm(4524): Note! N594: Extending jump
....\asm\cw32.asm(941): Note! N594: Extending jump
....\asm\cw32.asm(956): Note! N594: Extending jump
....\asm\cw32.asm(975): Note! N594: Extending jump
....\asm\cw32.asm(4511): Note! N594: Extending jump
....\asm\cw32.asm(4520): Note! N594: Extending jump
....\asm\cw32.asm(4522): Note! N594: Extending jump
....\asm\cw32.asm(4524): Note! N594: Extending jump
....\asm\cw32.asm(941): Note! N594: Extending jump
....\asm\cw32.asm(956): Note! N594: Extending jump
....\asm\cw32.asm(975): Note! N594: Extending jump
....\asm\cw32.asm(4511): Note! N594: Extending jump
....\asm\cw32.asm(4520): Note! N594: Extending jump
....\asm\cw32.asm(4522): Note! N594: Extending jump
....\asm\cw32.asm(4524): Note! N594: Extending jump
....\asm\cw32.asm(941): Note! N594: Extending jump
....\asm\cw32.asm(956): Note! N594: Extending jump
....\asm\cw32.asm(975): Note! N594: Extending jump
....\asm\cw32.asm(4511): Note! N594: Extending jump
....\asm\cw32.asm(4520): Note! N594: Extending jump
....\asm\cw32.asm(4522): Note! N594: Extending jump
....\asm\cw32.asm(4524): Note! N594: Extending jump
....\asm\cw32.asm(941): Note! N594: Extending jump
....\asm\cw32.asm(956): Note! N594: Extending jump
....\asm\cw32.asm(975): Note! N594: Extending jump
....\asm\cw32.asm(4511): Note! N594: Extending jump
....\asm\cw32.asm(4520): Note! N594: Extending jump
....\asm\cw32.asm(4522): Note! N594: Extending jump
....\asm\cw32.asm(4524): Note! N594: Extending jump
....\asm\cw32.asm(941): Note! N594: Extending jump
....\asm\cw32.asm(956): Note! N594: Extending jump
....\asm\cw32.asm(975): Note! N594: Extending jump
....\asm\cw32.asm(4511): Note! N594: Extending jump
....\asm\cw32.asm(4520): Note! N594: Extending jump
....\asm\cw32.asm(4522): Note! N594: Extending jump
....\asm\cw32.asm(4524): Note! N594: Extending jump
....\asm\cw32.asm(941): Note! N594: Extending jump
....\asm\cw32.asm(956): Note! N594: Extending jump
....\asm\cw32.asm(975): Note! N594: Extending jump
....\asm\cw32.asm(4511): Note! N594: Extending jump
....\asm\cw32.asm(4520): Note! N594: Extending jump
....\asm\cw32.asm(4522): Note! N594: Extending jump
....\asm\cw32.asm(4524): Note! N594: Extending jump
....\asm\cw32.asm(941): Note! N594: Extending jump
....\asm\cw32.asm(956): Note! N594: Extending jump
....\asm\cw32.asm(975): Note! N594: Extending jump
....\asm\cw32.asm(4511): Note! N594: Extending jump
....\asm\cw32.asm(4520): Note! N594: Extending jump
....\asm\cw32.asm(4522): Note! N594: Extending jump
....\asm\cw32.asm(4524): Note! N594: Extending jump
Error: Cannot Open File - cw32.obj
Error(E42): Last command making (cw32.obj) returned a bad status
Error(E02): Make execution terminated
<pmake -d build -h> => non-zero return: 2
Build failed

Any suggestions?
Should I be doing boot build with v2.0 or native MSVC?

My desire is to first build the 32bit OWv2.0, install it instead of the OW19 and test some changes to allow parport debugging on win7 64 bit using 32bit wdw.exe.
Then write 64 bit dbgport.sys :)

regards
Alex

Regression Test: Full Build Without Doc on Windows 7 32-bit

I am opening this issue as a single conversation thread to report all problems that I experience as a newbie contributor while becoming familiar with building OW on my 32 bit Windows 7 ASUS netbook. I will post here on the assumption that any problems that I encounter are due to my lack of familiarity, and that I will solve these problems on my own in due course. If it appears that I have encountered a true defect in the download, I will open a separate issue.

I have closed the two issues that I opened because I have gotten beyond both of them. At this moment, I am working on a problem building

\open-watcom-v2-master\bld\cpplib\contain

All subdirectories (mc ml mh mm ms) exhibit exactly the same failure. Running wmake fails when trying to build:

Error(E42): Last command making (wcskip.obj) returned a bad status

I have set verbose=1. I then copy the exact command to the comand prompt, which executes aok. I execute wmake again, which now works and chugs along until:

Error(E42): Last command making (xobjs\wcskip.obj) returned a bad status

I do the same workaround again, which executes aok. I execute wmake again, which now succeeds all of the way to the end.

This problem is not just for "contain". It also occurs for the next project in the build sequence. My next step will be to try to figure out how to see the environment information that is being passed into the compiler by wmake and try to identify how that environment differs from what is passed into the compiler when the same command line is executed by cmd.exe.

I don't expect anyone to help me with this unless you think that I am encountering a real defect in the download.

Bootstrapping watcom with intels compiler

Managed to bootstrap open Watcom with intels compiler.

If someone wants to toy with it heres a howto.

go into the build\mif directory and open the local.mif file with notepad++, scroll down to the bottom untill you reach this

!if !defined( "WATCOM" ) || "$(bld_cpu)" == "x64"

common settings

now change

common release/debug flags

common_flags_rel = -Ox -Zi
common_flags_dbg = -Zi
!ifeq release 1
common_flags = $(common_flags_rel)
!else
common_flags = $(common_flags_dbg)
!endif

to

common release/debug flags

common_flags_rel = -Ox -Zi -Qtbb
common_flags_dbg = -Zi -Qtbb
!ifeq release 1
common_flags = $(common_flags_rel)
!else
common_flags = $(common_flags_dbg)
!endif

the -Qtbb flag is for linking with intels threaded buliding blocks (just an example).

a bit further down change

bld settings

bcc = cl -nologo -c
bcxx = cl -nologo -c
bcl = cl -nologo

blib = lib -nologo

to

bld settings

bcc = icl -nologo -c
bcxx = icl -nologo -c
bcl = icl -nologo

blib = xilib -nologo

and further down change

standard settings

cc = cl -nologo -c
cxx = cl -nologo -c
cl = cl -nologo

librarian = lib -nologo

to

standard settings

cc = icl -nologo -c
cxx = icl -nologo -c
cl = icl -nologo

librarian = xilib -nologo

save and now open intels command shell instead of msvc's cd to the build root and do as you used to with msvc but it now uses intels compiler instead.

Intels compiler is pretty strict compared to msvc so its nice for finding bugs, besides that it also has way better optmization so toy a bit with its switches.

Implement copysign

The math library seems to be missing the copysign(x, y) function. The fuction is described here:

http://pubs.opengroup.org/onlinepubs/007904975/functions/copysign.html

An implementation would be rather simple:

double copysign(double x, double y)
{
    return y == 0.0 ? fabs(x) : fabs(x)*y/fabs(y);
}

Consider removing "_self" as a keyword in non-DOS targets

I've run into some code that is failing to build because Open Watcom defines _self as a keyword (actually a predefined macro for __self) in bld/plusplus/c/cmdln.c:204. From the docs, it appears that this keyword exists to maintain compatibility with Microsoft C, which is fine. It might be better, however, to only define the macro in cases where the compiler target is 16-bit, though, to avoid issues.

typo in sqlext.mh

define SQL_MAX_SDN_LENGTH 32

should be

define SQL_MAX_DSN_LENGTH 32

small typo but easy to fix :)

gcc47 invoked explicitly on FreeBSD ?

Is gcc47 hard coded somewhere in the make files as a C compiler now ? After wmake is built , the compilations stops complaining I don't have gcc47. (I use clang as a system compiler. Anyway, FreeBSD phases out GCC and land the GNU C++ lib starting with 10.0 which will be released in a couple of months.

bwpp386 bug

encountering this with msvc 2012 64 bit build.

Unhandled exception at 0x000000013FBFCA30 in bwpp386.exe: 0xC0000005: Access violation writing location 0x0000000002B47584.

crash happens here.

tatic void newBlk( cv_t *cv )
{
unsigned elm_size;
char *top_elm;
char *bottom_elm;
char *free_elm;
blk_t *newblk;
free_t *free_list;

DbgStmt( if( restoreFromZapped( cv ) ) return; );
elm_size = cv->elm_size;
free_list = cv->free_list;
newblk = _MemoryAllocate( sizeof( blk_t ) - 1 + cv->blk_top );
newblk->next = cv->blk_list;
cv->blk_list = newblk;
cv->blk_count++;
bottom_elm = newblk->data;
top_elm = bottom_elm + cv->blk_top;
free_elm = bottom_elm;
do {
    /* free_list must be maintained as the reverse of CarveWalkAll ordering */
    DbgZapFreed( free_elm, elm_size );
    _ADD_TO_FREE( free_list, free_elm ); // crashes here
    free_elm += elm_size;
} while( free_elm != top_elm );
cv->free_list = free_list;

}

Build fails on cexpr.c

Did a recent commit break the build? I'm seeing the following

cc cexpr.obj
../../c/cexpr.c(1932): Error! E1011: Symbol 'j' has not been declared
../../c/cexpr.c(1933): Warning! W131: No prototype found for function 'tolower'
../../c/cexpr.c(2050): Error! E1077: Missing '}'
../../c/cexpr.c(1926): Warning! W202: Symbol 'func_name' has been defined, but not referenced
../../c/cexpr.c(2050): Warning! W107: Missing return value for function 'IntrinsicMathFunc'
Error(E42): Last command making (cexpr.obj) returned a bad status
Error(E02): Make execution terminated
<wmake -h -f ../binmake bootstrap=1> => non-zero return: 512

I think commit 8cda4e5 may have messed something up. See here for the full log.

Periodic Regression Test Reports

Time last updated: 20140125@0749
Master: 20140119@1139
Tools: 20140114@1219 (OW 2.0)
Host: Windows 7 32-bit
Hardware: ASUS Netbook EeePC 1001PXD; Intel Atom CPU N455 @ 166GHz 1.67 GHz; 2GB RAM
Config: documentation build suppressed
Notes: Previous test, which PASSED, used tools 20131217@0400 (OW 2.0)
Result: PASS
Criteria: Normal termination for OW build.
Elapsed time: 4 hrs 35 min.

Build fails in 'bld/hdr' directory

It looks like the build is currently failing attempting to make directories in bld/hdr. I don't believe anything is creating the 'arch' directory first. I'm getting the following error:

====== 08:17:01 /home/jeff/workspace/watcom/open-watcom-v2/bld/hdr/linux ======
mkdir arch/mips/sys
mkdir: cannot create directory `arch/mips/sys': No such file or directory
Error(E42): Last command making (arch/mips/sys) returned a bad status
Error(E02): Make execution terminated
 => non-zero return: 512
Build failed

Fixing that missing directory simply leads to a similar error regarding the i386 architecture.

I'm guessing this error is related to commit a234f9f.

wasm produces two different opcodes for two similar instructions.

There are two simalar assembler instructions:
 cmp   ax, word ptr 12h
 cmp   ax, word ptr 1212h

Generated code expects to be as follow:
 3D 12 00 - CMP Immediate (word) with accumulator
 3D 12 12 - CMP Immediate (word) with accumulator

But for some reason wasm produces two different opcodes:
 83 F8 12 - CMP Immediate (byte) with register
 3D 12 12 - CMP Immediate (word) with accumulator

_P_DETACH mode not suported with spawnxxx functions

I noticed that OpenWatcom does not provide a _P_DETACH constant in its process.h header. I'm not really sure what would be involved in bringing support. Microsoft defines it as:

_P_DETACH: Continues to execute the calling process; the new process is run in the background with no access to the console or keyboard. Calls to _cwait against the new process fail (asynchronous _spawn).

posix path problem with mkdir

windows mkdir does not understand / paths.

heres a diff that fixes that.

diff --git "a/distrib\ow\master.mif" "b/distrib\ow\master.mif"
index 5b15d96..f526bf0 100644
--- "a/distrib\ow\master.mif"
+++ "b/distrib\ow\master.mif"
@@ -66,7 +66,7 @@ skip_build: .symbolic
all : ../bin/$(installer_c) ../bin/$(installer_f77) .SYMBOLIC

../bin/$(installer_c) : ../files.dat $(setup_c) .ALWAYS

• @if not exist ../bin mkdir ../bin
• @if not exist ..\bin mkdir ..\bin
  langdat -l filelist $(langdat_keys_$(bld_os)$(bld_cpu)) -c $[@ c
  @cp $]@ setup.exe &gt;$(nulldevice)
  mkinf -i.. -i../../include -dDstDir=$(dstdir) c filelist $(%OWRELROOT)
  @@ -81,7 +81,7 @@ all : ../bin/$(installer_c) ../bin/$(installer_f77) .SYMBOLIC
  @rm setup.zip

../bin/$(installer_f77) : ../files.dat $(setup_f77) .ALWAYS

• @if not exist ../bin mkdir ../bin
• @if not exist ..\bin mkdir ..\bin
  langdat -l filelist $(langdat_keys_$(bld_os)$(bld_cpu)) -c $[@ f77
  @cp $]@ setup.exe &gt;$(nulldevice)
  mkinf -i.. -i../../include -dDstDir=$(dstdir) f77 filelist $(%OWRELROOT)

\ translates to / on posix systems.

Help menu

Noticed the Help menu in the ide is not working, not sure when it broke but seems to be before the 1.8 release. Any plans on fixing it ?.

Definition of "in6addr_any" missing

It appears Open Watcom is missing the definition of "in6addr_any" in its Windows API headers. This constant is the IPv6 equivalent of INADDR_ANY, which Open Watcom does define on all supported platforms.

On Windows, the constant is defined in ws2_32.lib.

I'm not sure if this missing constant, however, is a symptom of more IPv6 stuff missing from the headers. Any ideas?

Newbie contributor: "Phar Lap err 10118: Can't load EXP file" during documentation build on Windows 7 32-bit.

Has anyone done a full build including doc on Windows 7 32-bit?

Coverity static analysis

Coverity Scan provides a free still very useful tool for the opensource projects to help to find obvious bugs.

bwasm

When trying to build on FreeBSD, bwasm builds, but cannot be executed, it complains it cant find it;s resource file. Do you have any idea where this comes from or should I dig deeper today ?

weditdll.h and weditdll.cpp problem

c++ weditdll.obj
File: ..\h\weditdll.h
included from ..\cpp\weditdll.cpp(33)
(55,44): Error! E498: syntax error before 'WString'; probable cause: incorrectly
spelled type name
(62,5): Error! E121: syntax error
(72,2): Error! E121: syntax error
File: ..\cpp\weditdll.cpp
(52,10): Error! E029: symbol '_hdl' has not been declared
(60,38): Error! E254: 'WEditDLL::resetPointers' has not been declared as a membe
r
definition: 'void WEditDLL::resetPointers( void )'
(67,9): Error! E029: symbol '_hdl' has not been declared
(68,5): Error! E029: symbol '_hdl' has not been declared
(71,46): Error! E498: syntax error before 'WString'; probable cause: incorrectly
spelled type name
Error(E42): Last command making (weditdll.obj) returned a bad status
Error(E02): Make execution terminated
<pmake -d build -h> => non-zero return: 2
Build failed

Hmm missing import ?

cmp al,0 / mov al,0

In recent changes I noticed some ASM constructions to set registers to zero, or compare them, in the form:

cmp reg, 0
mov reg, 0

It is compact, and usually faster using:
test reg, reg
xor reg, reg

OW 2.0 beta 20140114@1251 debugger watch window displays x20 rather than correct value

Windows installer mishandles file associations and start menu items

The installer for 32 bit Windows, version 2014-01-14 seems to have a couple of issues. First I notice that in my start menu under the "Open Watcom C - C++" group there is no menu item for the IDE or graphical editor. There may be other missing items as well (not sure).

During installation I told the installer to not make any changes to my environment. My environment was already configured from a previous installation of an earlier version that I manually removed. However I did tell the installer to refresh my file associations. This appeared to cause the file associations to break. C/C++ source files were left unassociated with anything, and IDE project files were also left unassociated.

owcc.exe crashes on simple command line : owcc -O2 hello.c

thanks to stray code at the end of ParseArgs() function.
Attached patch removes offending lines and as a bonus (re)enables conversion of slashes to backslashes in file names passed to compiler/linker.

diff --git a/bld/wcl/c/owcc.c b/bld/wcl/c/owcc.c
index c5073dd..df4a3c7 100644
--- a/bld/wcl/c/owcc.c
+++ b/bld/wcl/c/owcc.c
@@ -549,11 +549,6 @@ static unsigned ParseEnvVar( const char *env, char **argv, char *buf )
     return( argc );
 }

-typedef struct stack {
-    struct stack    *next;
-    char            *cmdbuf;
-    char            **argv;
-} stack;

 static  int  ParseArgs( int argc, char **argv )
 /*********************************************/
@@ -563,8 +558,6 @@ static  int  ParseArgs( int argc, char **argv )
     int         c;
     int         i;
     list        *new_item;
-    stack       *stk;
-    stack       *s;

     initialize_Flags();
     DebugFlag          = 1;
@@ -1011,7 +1004,7 @@ static  int  ParseArgs( int argc, char **argv )
             continue;
         new_item = MemAlloc( sizeof( list ) );
         new_item->next = NULL;
-        new_item->item = MemStrDup( Word );
+        new_item->item = strfdup( Word );
         if( FileExtension( Word, ".lib" ) || FileExtension( Word, ".a" ) ) {
             ListAppend( &Libs_List, new_item );
         } else {
@@ -1019,13 +1012,6 @@ static  int  ParseArgs( int argc, char **argv )
         }
     }
     MemFree( cpp_linewrap );
-    while( stk != NULL ) {
-        s = stk->next;
-        MemFree( stk->argv );
-        MemFree( stk->cmdbuf );
-        MemFree( stk );
-        stk = s;
-    }
     return( 0 );
 }

internal compiler error during build (of rfmtutil)

flib_cc rfmtutil.obj
../../c/rfmtutil.c(986): Error! E1119: Internal compiler error 32
Error(E42): Last command making (rfmtutil.obj) returned a bad status
Error(E02): Make execution terminated
<pmake -d build -h> => non-zero return: 512
Build failed

Strange heap errors when building wxwidgets

Earlier version 1.9 can build wxwidgets 2.12 but with this later version the linker crashes with a huge heap error. Ill try a build with your latest patches if it happens Again ill post the error.

BEX64 in 64 bit ide

Seems some update recently broke the 64 bit ide on windows 7.

crashes instantly with a BEX64 error.

Debugger not useable: displays 0x20 instead of true variable value

For same variable at same point in same test program, WDW 2.0 displays wrong value and WDW 1.9 displays correct value. When displaying data members of an object, typically multiple members display blanks (0x20) rather than correct value.

dos versions of wcl.exe/wcl386.exe won't build a simple program

I can't build even a simple program using DOS versions (i.e. WATCOM\BINW) of wcl or wcl386:

Error! E3122: no FILE directives found
Error: Linker returned a bad status

It works fine with OW 1.9 on the same machine.
I'm using 32-bit Windows 7.

bwrc during full build: no progress over 10 hours; cpu is all kernel cpu; Windows 7 32-bit

Build hasn't made any progress for at least 10 hours. Almost all CPU is kernel CPU. This has been true all day. Failed this way both of two trials.

Environment: Windows 7 32-bit, Intel Atom N455, ASUS Netbook, 2 GB ram. Documentation build is suppressed. Fresh virgin install of build files. Fresh virgin install of OW, selecting "full".

Linker wlinkd crashes when used with COPY option in ORDER derective.

There is a very simple test project with one asm source "startup.asm" and linker script "RomData.lnk" file: http://akitel.com/test.zip
Linker script contains COPY option in ORDER derective for copying initialized data from 'DATA' segment to 'ROMDATA' for creating ROMable image.

At the link step wlinkd crashes. When I put NOEMIT option to 'DATA' class segment it's no crashes, but I need to not use NOEMIT for correct inspection of produced image.

I found out the issue point in OW source file "bld\wl\c\loadfile.c" in the function:

static bool WriteSegData( void *_sdata, void *_info )
{
...
newpos = info->seg_start + sdata->a.delta;
...
WriteInfoLoad( sdata->u1.vm_ptr, sdata->length );
sdata->u1.vm_offs = newpos; // for incremental linking <- HERE
...
}

When 'DATA' segment (from DGROUP) writing out to the output image on its own location at first time with a WriteInfoLoad( ... ) function, sdata->u1.vm_offs (actually is a pointer to memory vm_ptr) replaced with newpos numerical value which is not a memory pointer.
And the second time when 'DATA' section should be wriiten to the new location at 'ROMDATA' segment WriteInfoLoad( ... ) used that number (not a pointer) as first argument and crashes in WriteBuffer( ... ) function.

After commented out this line of code:
sdata->u1.vm_offs = newpos; // for incremental linking
wlinkd not crashes, but what would be instead of !? Unfortunately, produced image is wrong with a segmentation offsets. I found out another issue point in the same source file in the function:

static bool WriteCopyGroups( void *_seg, void *_info )
{
...
Ring2Lookup( seg->group->leaders, DoDupGroupLeader, info );
info->grp_start += seg->group->totalsize; <- HERE
...
}

When this line is also commented out wlink produce the right (as expected) image with a two copy of 'DATA' in it.

I suppose those two lines of code are for something important of course and commented their out is very wrong. So, I'll be grateful for you professional help.

Build error hits wannabe contributor: bld\cpplib\contain\generic.086\mc

After virgin full install of binaries on a Windows 7 32 bit computer and virgin download of Open Watcom v2, two build attempts failed with the following error message. (A third build attempt got much farther but was terminated by me.)

There is a bug in wdw's configuration autosave that I want to fix as my first contribution after I succeed in building OW.

==== ERROR DURING BUILD: ====
I:\open-watcom-v2-master\bld\cpplib\contain\generic.086\mc>wmake
Open Watcom Make Version 2.0 beta Jan 11 2014 10:33:22 (32-bit)
Copyright (c) 2002-2013 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
c++ wcskip.obj
93 ticks to load pre-compiled header
OVFN nodes unfreed: 003dd5bc
Error(E42): Last command making (wcskip.obj) returned a bad status

Error(E02): Make execution terminated

Is the tree broken at the moment ?

Is the tree in a uncompilable state at this moment ? A clone of master will fail to build very early in the build process as of current.

wgml output from dosemu assumed to be all uppercase

While attempting a bootstrap build on Debian GNU/Linux (Debian squeeze, 32-bit, x86, native OW tools), build.sh failed eventually when dosemu/wgml was executed. The failure was that TMP.PTF was not found. The file tmp.ptf, however, was present. Apparently dosemu 1.4.0 is not using all uppercase to write files, causing build.sh to fail on this step.

intrface.sp enhancement

/* Macros to declare interfaces - these macros can be used for both C and C++. Define
 * CINTERFACE to have these macros expand in C++ code as if they were in C code.
 * Define CONST_VTABLE to have constant vtables in C.
 */
#if defined( __cplusplus ) && !defined( CINTERFACE )
    #define __STRUCT__                              struct
    #undef  interface
    #define interface                               __STRUCT__
    #define STDMETHOD( f )                          virtual HRESULT STDMETHODCALLTYPE f
    #define STDMETHOD_( x, f )                      virtual x STDMETHODCALLTYPE f
    #define STDMETHODV( f )                         virtual HRESULT STDMETHODVCALLTYPE f
    #define STDMETHODV_( x, f )                     virtual x STDMETHODVCALLTYPE f
    #define PURE                                    = 0
    #define THIS_
    #define THIS                                    void
    #define DECLARE_INTERFACE( x )                  interface x
    #define DECLARE_INTERFACE_( x, p )              interface x : public p
#else
    #undef  interface
    #define interface                               struct
    #define STDMETHOD( f )                          HRESULT (STDMETHODCALLTYPE *f)
    #define STDMETHOD_( x, f )                      x (STDMETHODCALLTYPE *f)
    #define STDMETHODV( f )                         HRESULT (STDMETHODVCALLTYPE *f)
    #define STDMETHODV_( x, f )                     x (STDMETHODVCALLTYPE *f)
    #define PURE
    #define THIS_                                   INTERFACE FAR *This,
    #define THIS                                    INTERFACE FAR *This
    #ifdef CONST_VTABLE
        #define DECLARE_INTERFACE( x ) \
            typedef interface x { \
                const struct x##Vtbl *lpVtbl; \
            } x; \
            typedef const struct x##Vtbl x##Vtbl; \
            const struct x##Vtbl
    #else
        #define DECLARE_INTERFACE( x ) \
            typedef interface x { \
                struct x##Vtbl *lpVtbl; \
            } x; \
            typedef struct x##Vtbl x##Vtbl; \
            struct x##Vtbl
    #endif
    #define DECLARE_INTERFACE_( x, p )              DECLARE_INTERFACE( x )
#endif
#define IFACEMETHOD( f )                            STDMETHOD( f )
#define IFACEMETHOD_( x, f )                        STDMETHOD_( x, f )
#define IFACEMETHODV( f )                           STDMETHODV( f )
#define IFACEMETHODV_( x, f )                       STDMETHODV_( x, f )

the new __STRUCT__ declaration fixes one of the problems compiling newer wxwidgets. Is defined like this in both MSVC and MinGW64 so i guess its right.

Building on Linux

Hi I got this issue when I tried to build on Linux:

[..snip]

gcc -pipe -O -o dlgprs.exe -Wl,-Map,dlgprs.map bind.obj dialog.obj main.obj scanner.obj styles.obj prsbnd.obj prsdlg.obj chfile.obj chbffile.obj mempool.obj /home/jens/Arch/packaging/openwatcom-v2-git/src/build/bld/watcom/binbuild/clibext.lib
gcc: error: bind.obj: No such file or directory
gcc: error: dialog.obj: No such file or directory
gcc: error: chfile.obj: No such file or directory
= 15:10:23 /home/jens/Arch/packaging/openwatcom-v2-git/src/build/bld/browser/dlgprs =
Can not open '/home/jens/Arch/packaging/openwatcom-v2-git/src/build/bld/browser/dlgprs/binbuild/dlgprs.exe' for reading: No such file or directory
<acopy binbuild/dlgprs.exe /home/jens/Arch/packaging/openwatcom-v2-git/src/build/build/bin/dlgprs> => non-zero return: 1
Build failed
./build.sh: line 33: return: can only `return' from a function or sourced script

.....

All the other binaries up until that issue built fine. I tried to trace back where those objects should be created and from where they should be included, but could not find anything.

BTW is there support for something similar to DESTDIR in the build? That way, one could give absolute paths during the build but still install the binaries in a fake root directory (for packaging).

malloc.h

When building with native tools on some UNIX-like OSes the header malloc.h does not exist or is stubbed to a #error directive signaling the correct header to be included, stdlib.h. The fact is, there is no such header in C/C++ , if it exists, it's implementation specific extension and should not be relayed upon.

An attempt to build on FreeBSD hits this problem.

Inconsistent types in 'cmdlnprs.gc'

It appears that during build the generated code in cmdlnprs.gc contains an inconsistent return type. My build is failing with:

**** Building the wpp386 bootstrap
= 00:33:05 /home/buildbot/slave-local1/global_build_rel/git/bld/plusplus/386 ==
= 00:33:05 /home/buildbot/slave-local1/global_build_rel/git/bld/plusplus/386/binbuild =
cc cmdlnany.obj
cmdlnprs.gc(2): Error! E1062: Inconsistent return type for function 'OPT_PROCESS'
cmdlnprs.gc(2): Note! I2003: source conversion type is 'int '
cmdlnprs.gc(2): Note! I2004: target conversion type is 'char '
cmdlnprs.gc(2): Note! I2002: 'OPT_PROCESS' defined in: /home/buildbot/slave-local1/global_build_rel/git/bld/fe_misc/h/cmdlnprs.h(48)
Error(E42): Last command making (cmdlnany.obj) returned a bad status
Error(E02): Make execution terminated
<wmake -h -f ../binmake bootstrap=1> => non-zero return: 512
Build failed

The generated header code says the return type should be bool, while the generated C code returns an int.

I know there have been some changes to optencod lately. I've done a builder clean prior to attempting this.

Argument-Dependent Lookup - Wrong

#include < iostream >

namespace X {
    template<typename T> void f(T);
}

namespace N {
    using namespace X;
    enum E { e1 };
    void f(E) {
        std::cout << "N::f(N::E) called\n";
    }
}

void f(int)
{
    std::cout << "::f(int) called\n";
}

int main()
{
    ::f(N::e1);  // qualified function name: no ADL
    f(N::e1);    // ordinary lookup finds ::f() and ADL finds N::f(),
}                   //  the latter is preferred

But there seemed to be no difference in searching when compiling with Open Watcom C++... while GCC works well.

__WATCOMC__ reporting "1300"

My most recent build of Open Watcom (yesterday) appears to be reporting WATCOMC as 1300 rather than the expected 2000. A few weeks ago, I believe it had been reporting 2000. I'm not exactly sure where the version number is assigned in code.

Using WATCOM register calling conventions in the trap file created under MSVC.

I am developing trap file for debugging 16-bit embedded image under OW debugger.
My IDE for creating and debugging trap file by itself is MS Visual Studio C++.
I have examined two documents: the old WATCOM Debugger Trap File Interface ver. 17.0 and new one Trap File Interface VERSION 1.3.

In the old document says that calling convention for three exported routines is a "standard WATCOM register calling conventions". But in the new doc nowhere mentioned about "calling convention" used (most likely it has not changed).

Unfortunately, MSVC++ knows nothing about "standard WATCOM register calling conventions" and I can not create those functions with that calling conventions...

---

In the new document chapter 4.4
4.4 Trap Files Under Windows NT.

A trap file is a normal Windows NT DLL.
The system automatically searches the directories specified by the PATH environment variable.
Once loaded, the Open Watcom debugger uses export ordinal 1 from the DLL for TrapInit, export ordinal 2 for TrapFini and export ordinal 3 for TrapRequest.

---

"... normal Windows NT DLL" usually uses __stdcall or __cdecl calling conventions.
The most of internal OW DLLs (wlinkd.dll for example) uses __stdcall for exported functions, what was the reason to choose WATCOM register calling conventions for trap files ?

P.S. Using ordinals instead of names is not so good idea also.

Error when initializing struct using variables

On a number of occasions, I've run into the following error:

Error! E1054: Expression must be constant

when building code. This error is caused by the not-so-uncommon practice of initializing a struct in its declaration using a variable value. For example:

struct s {
    int a;
    int b;
};

struct s test(const int one, const int two)
{
struct s ret = {one, two};

    ret.a +=1;

    return ret;
}

The above will cause the error to appear because of the initialization of ret.

I haven't found any good references on whether the code above should be an error, as OpenWatcom reports. If OpenWatcom is indeed conforming to the c89 standard by complaining about the above, then this isn't a bug, but, rather, an enhancement.

latest update causes internal compiler error

....\c\rfmtutil.c(986): Error! E1119: Internal compiler error 97
Error(E42): Last command making (rfmtutil.obj) returned a bad status
Error(E02): Make execution terminated
<pmake -d build -h> => non-zero return: 2
Build failed

happens with both open watcom and msvc.

switch...case and 64-bit integer types

I'm running into some code that's failing because the argument to a switch statement is of the type uint64_t (via a typedef). I'm assuming such code is not allowed under c89 (?). However, I'm really not sure.

Not sure this would be a bug, possibly more of an enhancement. It would be nice if OpenWatcom's switch...case supported any integral value.

optencod.exe 64 bit crash

Anyone else getting this ? optencod.exe crashes when open watcom compiled with msvc 2012.

Unhandled exception at 0x000000013F475341 in optencod.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.

Happens in optencod.c in the createChainHeader function.

here if( usage == NULL || *usage == '\0' ) and further Down here
strcat( hdrbuff, usage );

Help Desk for New Contributors (Problems building Open Watcom from OW source).

If you have downloaded the source code for Open Watcom and are having trouble building OW for the first time, please post details here and someone will help you!

Building HTML Help?

Out of curiousity, I'm attempting to build the full documentation for Open Watcom, and I'm running into some issues. I'm currently running on Linux (Debian Squeeze to be specific). I can't seem to get the build system to even attempt to build HTML Help (chm) files at all. Running "builder rel" in the docs directory does not generate them, and attempting to run it using "builder rel os_nt" in docs/, as suggested by docs/howto.txt does not seem to do anything either. The build system output is:

jeff@centurion:~/workspace/watcom/open-watcom-v2/docs$ builder rel os_nt
**** REL rule
========== 21:38:01 /home/jeff/workspace/watcom/open-watcom-v2/docs ===========
====== 21:38:02 /home/jeff/workspace/watcom/open-watcom-v2/docs/htmlhelp ======
========= 21:38:04 /home/jeff/workspace/watcom/open-watcom-v2/docs/nt =========
========== 21:38:07 /home/jeff/workspace/watcom/open-watcom-v2/docs ===========
========== 21:38:07 /home/jeff/workspace/watcom/open-watcom-v2/docs ===========
jeff@centurion:~/workspace/watcom/open-watcom-v2/docs$ 

I do have the necessary nonsense installed (WINE + a working Microsoft HTML Help Workshop install). However, if it is blocking based on OS, missing tools, or missing defintions, then certainly some message mentioning this should be emitted. Otherwise, this is simply more of a question.