Nice to finally see OpenWatcom toolchain running as native 64 bit apps!

[Ricardo E. Gayoso]

Hi Jiri,
It was nice to see a full OpenWatcom toolchain running as native Win64 (amd)
applications!
http://sourceforge.net/projects/openwatcom/
I also did wdis wcl386.exe and the asm source is 64 bit (has all the new
registers).
How did you build the toolchain? What compiler did you use to compile Watcom
C++ source code producing 64 bit exes and dlls?
Great work!
Ricardo

[Marty Stanquist]

This looks to be Jiri's efforts. Congratulations.

Marty

"Ricardo E. Gayoso" wrote in message news:kum9nm$94e$***@www.openwatcom.org...

Hi Jiri,
It was nice to see a full OpenWatcom toolchain running as native Win64 (amd)
applications!
http://sourceforge.net/projects/openwatcom/
I also did wdis wcl386.exe and the asm source is 64 bit (has all the new
registers).
How did you build the toolchain? What compiler did you use to compile Watcom
C++ source code producing 64 bit exes and dlls?
Great work!
Ricardo

[Lynn McGuire]

Post by Ricardo E. Gayoso
Hi Jiri,
It was nice to see a full OpenWatcom toolchain running as native Win64 (amd)
applications!
http://sourceforge.net/projects/openwatcom/
I also did wdis wcl386.exe and the asm source is 64 bit (has all the new
registers).
How did you build the toolchain? What compiler did you use to compile Watcom
C++ source code producing 64 bit exes and dlls?
Great work!
Ricardo

All the installs appear to be there at
http://sourceforge.net/projects/openwatcom/files/current-build/

So is OpenWatcom moving to sourceforge?

Thanks,
Lynn

[Steve Fabian]

Lynn McGuire wrote:
| All the installs appear to be there at
| http://sourceforge.net/projects/openwatcom/files/current-build/
|
| So is OpenWatcom moving to sourceforge?

The OFFICIAL FTP site, ftp://openwatcom.org, is still distributing version
1.9. It has undergone full regression testing.

Jiri Malik created a FORK for version 2.0 on sourceforge. There is no record
I am personally aware of that it had undergone the full regression testing,
nor that it is a RELEASE. This does not mean that it is not a well-tested
release. So: CAVEAT EMPTOR!

[Lynn McGuire]

Post by Steve Fabian
| All the installs appear to be there at
| http://sourceforge.net/projects/openwatcom/files/current-build/
|
| So is OpenWatcom moving to sourceforge?
The OFFICIAL FTP site, ftp://openwatcom.org, is still distributing version
1.9. It has undergone full regression testing.
Jiri Malik created a FORK for version 2.0 on sourceforge. There is no record
I am personally aware of that it had undergone the full regression testing,
nor that it is a RELEASE. This does not mean that it is not a well-tested
release. So: CAVEAT EMPTOR!

Gotcha.

Thanks,
Lynn

[Jiri Malak]

It is tested by standard OW regression tests for C, C++, WASM and Fortran 77
compilers for 32 and 16-bit targets and for 64/32/16-bit hosts.
Not all combinations are posible and I am able to do it.
I am doing following tests
16-bit target is tested on Windows 2003
32-bit hosts tools are tested on Linux/Windows 2003
64-bit hosts tools are tested on Linux/Windows 7

Any real test results from DOS or OS/2 are welcome.

64-bin Linux version is stil not usable, there is some problem with
compilers and code generator. I will fix it latter.

Anyway, I forked OW 1.9 as well tested background and change build system to
be similar as what is in Perforce for version 2. I fixed many various
problems, mainly crashing of C++ compiler, fix code generator to proper
initialization of poiters for DLL code, I added LFN support to DOS version
of OW tools, etc..
I hove not list of all them now.

Jiri

Post by Steve Fabian
| All the installs appear to be there at
| http://sourceforge.net/projects/openwatcom/files/current-build/
|
| So is OpenWatcom moving to sourceforge?
The OFFICIAL FTP site, ftp://openwatcom.org, is still distributing version
1.9. It has undergone full regression testing.
Jiri Malik created a FORK for version 2.0 on sourceforge. There is no
record I am personally aware of that it had undergone the full regression
testing, nor that it is a RELEASE. This does not mean that it is not a
well-tested release. So: CAVEAT EMPTOR!

[Marty Stanquist]

"Jiri Malak" wrote in message news:kuqfqh$hio$***@www.openwatcom.org...

It is tested by standard OW regression tests for C, C++, WASM and Fortran 77
compilers for 32 and 16-bit targets and for 64/32/16-bit hosts.
Not all combinations are posible and I am able to do it.
I am doing following tests
16-bit target is tested on Windows 2003
32-bit hosts tools are tested on Linux/Windows 2003
64-bit hosts tools are tested on Linux/Windows 7

Any real test results from DOS or OS/2 are welcome.

64-bin Linux version is stil not usable, there is some problem with
compilers and code generator. I will fix it latter.

Anyway, I forked OW 1.9 as well tested background and change build system to
be similar as what is in Perforce for version 2. I fixed many various
problems, mainly crashing of C++ compiler, fix code generator to proper
initialization of poiters for DLL code, I added LFN support to DOS version
of OW tools, etc..
I hove not list of all them now.

Jiri

Post by Steve Fabian
| All the installs appear to be there at
| http://sourceforge.net/projects/openwatcom/files/current-build/
|
| So is OpenWatcom moving to sourceforge?
The OFFICIAL FTP site, ftp://openwatcom.org, is still distributing version
1.9. It has undergone full regression testing.
Jiri Malik created a FORK for version 2.0 on sourceforge. There is no
record I am personally aware of that it had undergone the full regression
testing, nor that it is a RELEASE. This does not mean that it is not a
well-tested release. So: CAVEAT EMPTOR!

Jiri, are you still maintaining your fork in Git and do you have a project
home page? I wanted to update the OW website with your links so people can
more easily find your work.

Marty

[Lynn McGuire]

Post by Jiri Malak
It is tested by standard OW regression tests for C, C++, WASM and Fortran 77
compilers for 32 and 16-bit targets and for 64/32/16-bit hosts.
Not all combinations are posible and I am able to do it.
I am doing following tests
16-bit target is tested on Windows 2003
32-bit hosts tools are tested on Linux/Windows 2003
64-bit hosts tools are tested on Linux/Windows 7
Any real test results from DOS or OS/2 are welcome.
64-bin Linux version is stil not usable, there is some problem with
compilers and code generator. I will fix it latter.
Anyway, I forked OW 1.9 as well tested background and change build system to
be similar as what is in Perforce for version 2. I fixed many various
problems, mainly crashing of C++ compiler, fix code generator to proper
initialization of poiters for DLL code, I added LFN support to DOS version
of OW tools, etc..
I hove not list of all them now.
Jiri

Thanks! I see that you brought over the F77
compilers and runtime library also. Nice!

Lynn

[Leif Ekblad]

I also tested it with RDOS, and it works for all applications and
device-drivers. It also has the fix in the code generator for the 32-bit
compact memory model.

Leif

Post by Jiri Malak
It is tested by standard OW regression tests for C, C++, WASM and Fortran 77
compilers for 32 and 16-bit targets and for 64/32/16-bit hosts.
Not all combinations are posible and I am able to do it.
I am doing following tests
16-bit target is tested on Windows 2003
32-bit hosts tools are tested on Linux/Windows 2003
64-bit hosts tools are tested on Linux/Windows 7
Any real test results from DOS or OS/2 are welcome.
64-bin Linux version is stil not usable, there is some problem with
compilers and code generator. I will fix it latter.
Anyway, I forked OW 1.9 as well tested background and change build system to
be similar as what is in Perforce for version 2. I fixed many various
problems, mainly crashing of C++ compiler, fix code generator to proper
initialization of poiters for DLL code, I added LFN support to DOS version
of OW tools, etc..
I hove not list of all them now.
Jiri

Post by Steve Fabian
| All the installs appear to be there at
| http://sourceforge.net/projects/openwatcom/files/current-build/
|
| So is OpenWatcom moving to sourceforge?
The OFFICIAL FTP site, ftp://openwatcom.org, is still distributing version
1.9. It has undergone full regression testing.
Jiri Malik created a FORK for version 2.0 on sourceforge. There is no
record I am personally aware of that it had undergone the full regression
testing, nor that it is a RELEASE. This does not mean that it is not a
well-tested release. So: CAVEAT EMPTOR!

[Jiri Malak]

Hi Leif,

Thanks for your testing with RDOS.

Jiri

Post by Leif Ekblad
I also tested it with RDOS, and it works for all applications and
device-drivers. It also has the fix in the code generator for the 32-bit
compact memory model.
Leif

Post by Jiri Malak
It is tested by standard OW regression tests for C, C++, WASM and Fortran 77
compilers for 32 and 16-bit targets and for 64/32/16-bit hosts.
Not all combinations are posible and I am able to do it.
I am doing following tests
16-bit target is tested on Windows 2003
32-bit hosts tools are tested on Linux/Windows 2003
64-bit hosts tools are tested on Linux/Windows 7
Any real test results from DOS or OS/2 are welcome.
64-bin Linux version is stil not usable, there is some problem with
compilers and code generator. I will fix it latter.
Anyway, I forked OW 1.9 as well tested background and change build system to
be similar as what is in Perforce for version 2. I fixed many various
problems, mainly crashing of C++ compiler, fix code generator to proper
initialization of poiters for DLL code, I added LFN support to DOS
version of OW tools, etc..
I hove not list of all them now.
Jiri

Post by Steve Fabian
| All the installs appear to be there at
| http://sourceforge.net/projects/openwatcom/files/current-build/
|
| So is OpenWatcom moving to sourceforge?
The OFFICIAL FTP site, ftp://openwatcom.org, is still distributing version
1.9. It has undergone full regression testing.
Jiri Malik created a FORK for version 2.0 on sourceforge. There is no
record I am personally aware of that it had undergone the full
regression testing, nor that it is a RELEASE. This does not mean that it
is not a well-tested release. So: CAVEAT EMPTOR!

[Pedro Giffuni]

Hello;

It would be nice to run OW itself through a static checker, in
particular Coverity, which is free for opensource projects:

https://scan.coverity.com/travis_ci

Regards,

Pedro.

Post by Jiri Malak
It is tested by standard OW regression tests for C, C++, WASM and Fortran 77
compilers for 32 and 16-bit targets and for 64/32/16-bit hosts.
Not all combinations are posible and I am able to do it.
I am doing following tests
16-bit target is tested on Windows 2003
32-bit hosts tools are tested on Linux/Windows 2003
64-bit hosts tools are tested on Linux/Windows 7
Any real test results from DOS or OS/2 are welcome.
64-bin Linux version is stil not usable, there is some problem with
compilers and code generator. I will fix it latter.
Anyway, I forked OW 1.9 as well tested background and change build system to
be similar as what is in Perforce for version 2. I fixed many various
problems, mainly crashing of C++ compiler, fix code generator to proper
initialization of poiters for DLL code, I added LFN support to DOS version
of OW tools, etc..
I hove not list of all them now.
Jiri

Post by Steve Fabian
| All the installs appear to be there at
| http://sourceforge.net/projects/openwatcom/files/current-build/
|
| So is OpenWatcom moving to sourceforge?
The OFFICIAL FTP site, ftp://openwatcom.org, is still distributing version
1.9. It has undergone full regression testing.
Jiri Malik created a FORK for version 2.0 on sourceforge. There is no
record I am personally aware of that it had undergone the full regression
testing, nor that it is a RELEASE. This does not mean that it is not a
well-tested release. So: CAVEAT EMPTOR!

[Jiri Malak]

Hi Ricardo,

you can find details in radme.txt file in OW root.
I am using MS VC++ 2008 for Win64 and GCC for Linux 64-bit build.

A few notes to 64-bit Windows version.
Not all tools are 64-bit. debugger and profiler must be 32-bit because
application created by OW are stil 32-bit. C++ browser, cvpack, ... is also
32-bit because I have problem with porting some C++ application to various
compilers tool chain, I am not strong in C++. Anybody is welcom to help with
this.
I will add support for native debugging on 64-bit hosts later, but until OW
will have 64-bit code generator it has not much sense to do it.

Now following OW tools support 64-bit objects.
- librarian
- resource compiler and resource editors

As soon as I finish with OW full port to 64-bit bilding system I plan to
change OW linker to be able compile 64-bit executable.

Jiri

Post by Ricardo E. Gayoso
Hi Jiri,
It was nice to see a full OpenWatcom toolchain running as native Win64
(amd) applications!
http://sourceforge.net/projects/openwatcom/
I also did wdis wcl386.exe and the asm source is 64 bit (has all the new
registers).
How did you build the toolchain? What compiler did you use to compile
Watcom C++ source code producing 64 bit exes and dlls?
Great work!
Ricardo

[Jiri Malak]

Today I updated OW installers that contains Win64 host OW installation.
All installers, including Win64 installer are available from Sourceforge

http://sourceforge.net/projects/openwatcom/files/current-build/

Jiri

[Steve Fabian]

Jiri Malak wrote:

...
| As soon as I finish with OW full port to 64-bit bilding system I plan
| to change OW linker to be able compile 64-bit executable.

Reverse order might be nicer. If you first permit OW to build 64-b programs,
that version could also be used for building the 64b OW toolset. It's a
question of which comes first - the chicken or the egg. The 32b toolset
could be used to build 64b code, just as the 16b toolset can build 32b
code - the key element is the need for a 64b code generator. I am currently
using many 32b programs on my 64b Win7 computer, and do not notice
appreciable speed difference from the 64b versions, but this may be just due
to my requirements that are user interface heavy.

Personally I am interested in using Fortran (possibly assisted by C) to
build plugins (DLLs) that can be compiled in both 32b and 64b versions.

[Wilton Helm]

That has been my suspicion ever since 64 bit CPUs became common (although
I'm not working in 64 bit at all). The biggest advantage is that the
hardware is accessing memory 64 bits wide, which is unrelated to register
size.

FP has been using between 64 and 80 bits for a long time. 32 bit integers
are almost large enough to represent the US government deficit to the
nearest penny and certainly large enough to represent any physical property
with greater precision than the accuracy with which it can be measured.
There are a few situations where it might make sense, but my guess is that
90% or more of programs never need to handle a quantitiy that won't fit in a
32 bit integer, and even then, a lot of it is in FP anyway.

The only place where anything I would write would benefit from 64 bit code
is bit mapped enumerations. I have a very effective technique that I use to
iterate over subsets of a list, etc. and even handle things like exclusions
using bit mapped form. Most of the time, 32 bits suffices, but occasionally
64 would be nice. I have one situation where I'm actually using 256. It is
on a 16 bit processor, so it took some assembly language functions to
optimize performance.

The real irony is that booleans occupy 1 bit out of a 64 bit word!

Realistically, for most applications 32 bits represents a real sweet spot
and all 64 bits offers is a wider memory bus to help keep the CPU busy.

Wilton

[Lynn McGuire]

Post by Wilton Helm
That has been my suspicion ever since 64 bit CPUs became common (although
I'm not working in 64 bit at all). The biggest advantage is that the
hardware is accessing memory 64 bits wide, which is unrelated to register
size.
FP has been using between 64 and 80 bits for a long time. 32 bit integers
are almost large enough to represent the US government deficit to the
nearest penny and certainly large enough to represent any physical property
with greater precision than the accuracy with which it can be measured.
There are a few situations where it might make sense, but my guess is that
90% or more of programs never need to handle a quantitiy that won't fit in a
32 bit integer, and even then, a lot of it is in FP anyway.
The only place where anything I would write would benefit from 64 bit code
is bit mapped enumerations. I have a very effective technique that I use to
iterate over subsets of a list, etc. and even handle things like exclusions
using bit mapped form. Most of the time, 32 bits suffices, but occasionally
64 would be nice. I have one situation where I'm actually using 256. It is
on a 16 bit processor, so it took some assembly language functions to
optimize performance.
The real irony is that booleans occupy 1 bit out of a 64 bit word!
Realistically, for most applications 32 bits represents a real sweet spot
and all 64 bits offers is a wider memory bus to help keep the CPU busy.
Wilton

I expect to hear this when we start the transition
from 64 bit to 128 bit in 2025. And then 128 bit
to 256 bit in 2040 <g>.

Yes, boolean only needs 1 bit and is a tremendous
waste of space and memory bandwidth. Just the
cost of doing business.

Lynn

[Hans-Bernhard Bröker]

Post by Wilton Helm
FP has been using between 64 and 80 bits for a long time. 32 bit integers
are almost large enough to represent the US government deficit to the
nearest penny and certainly large enough to represent any physical property
with greater precision than the accuracy with which it can be measured.

You're underestimating modern physics by about 3 orders of magnitude, at
the least, 7 if you count the precision of modern ultra-high precision
clocks.

Post by Wilton Helm
The real irony is that booleans occupy 1 bit out of a 64 bit word!

That doesn't matter at all once you consider that there's quite probably
more than twice as much memory on any 64-bit machine than there would
have been on a 32-bit one. I.e. you have the extra 32 bits to spare,
easily. And it's not like 32-bit machines were about to vanish from the
face of the industry next Tuesday.

[Peter C. Chapin]

Post by Wilton Helm
FP has been using between 64 and 80 bits for a long time. 32 bit integers
are almost large enough to represent the US government deficit to the
nearest penny and certainly large enough to represent any physical property
with greater precision than the accuracy with which it can be measured.

There's more to it than that. Numerically unstable algorithm will expand
tiny errors to enormous errors after enough computations on the values
have occured. Since some applications apply literally billions of
computations on the data elements, such ballooning of error is a real
concern.

The right solution is to use a numerically stable algorithm. But sometimes
that's not possible or desirable (say for execution efficiency reasons).
If a careful analysis shows that an unstable algorithm can be safely used,
it may be best to do so. In those cases the extra precision of double or
long double can make or break a computation.

Here I'm not necessarily talking about computations on measured values but
computations on fundamental constants (pi) or in simulations where all
"measured" values are exact by definition.

Post by Wilton Helm
Realistically, for most applications 32 bits represents a real sweet spot
and all 64 bits offers is a wider memory bus to help keep the CPU busy.

64 bit machines can directly access large memories and that's important
for many applications. If I need to manipulate a 20 GiB array, doing so on
a 32 bit machine is awkward and inefficient.

It is true that common compilers for 64 bit targets still use 32 bits for
type 'int' precisely because many applications don't need more and there
is little point in wasting memory by making int 64 bits. However, 64 bit
pointers are universally used (and size_t needs to be 64 bits as well to
properly represent the in-memory size of large objects).

Peter

[Wilton Helm]

Post by Peter C. Chapin
There's more to it than that. Numerically unstable algorithm will expand
tiny errors to enormous errors

True, but I expect that less than 1% of PCs ever run such code, and even
then, almost all such code uses FP which has been available in 80 bit
precision since the 8087.

Post by Peter C. Chapin
64 bit machines can directly access large memories and that's important for
many applications

True, and more common that above, give the emphasis on video, etc. Pointers
may be the biggest use of 64 bits for most users.

But in the big picture 64 bits is mostly a marketing gimick. The average
user surfing the web or writing E-Mail absolutely won't know the difference.
A gamer might. Someone doing image or video processing might. The main
beneficiaries are people doing stuff like global weather prediction that
rely on huge data sets and numerically unstable algorithms.

Its almost like Moore's law says we have all these transistors and we need
to use them so let's find something to use them for.

Wilton

[Steve Fabian]

Wilton Helm wrote:

| Its almost like Moore's law says we have all these transistors and we
| need to use them so let's find something to use them for.

Well said! Just because we can build a skyscraper for the same price as a
single-family home, we don't all need skyscrapers...

And - BTW - make programs harder to use because we have all these unused
features obscuring the primary goal,

[Leif Ekblad]

Hi Jiri,

I'd be interested in a port of WASM to 64-bit, as I currently have to use
JWASM for my work-in-progress on 64-bit code. And the author of JWASM
apparently doesn't want to support generating mixed-bitness binaries, so I
need a few quirks to make it work.

Leif Ekblad

Post by Jiri Malak
Hi Ricardo,
you can find details in radme.txt file in OW root.
I am using MS VC++ 2008 for Win64 and GCC for Linux 64-bit build.
A few notes to 64-bit Windows version.
Not all tools are 64-bit. debugger and profiler must be 32-bit because
application created by OW are stil 32-bit. C++ browser, cvpack, ... is also
32-bit because I have problem with porting some C++ application to various
compilers tool chain, I am not strong in C++. Anybody is welcom to help with
this.
I will add support for native debugging on 64-bit hosts later, but until OW
will have 64-bit code generator it has not much sense to do it.
Now following OW tools support 64-bit objects.
- librarian
- resource compiler and resource editors
As soon as I finish with OW full port to 64-bit bilding system I plan to
change OW linker to be able compile 64-bit executable.
Jiri

Post by Ricardo E. Gayoso
Hi Jiri,
It was nice to see a full OpenWatcom toolchain running as native Win64
(amd) applications!
http://sourceforge.net/projects/openwatcom/
I also did wdis wcl386.exe and the asm source is 64 bit (has all the new
registers).
How did you build the toolchain? What compiler did you use to compile
Watcom C++ source code producing 64 bit exes and dlls?
Great work!
Ricardo

[Lynn McGuire]

Post by Ricardo E. Gayoso
Hi Jiri,
It was nice to see a full OpenWatcom toolchain running as native Win64 (amd)
applications!
http://sourceforge.net/projects/openwatcom/
I also did wdis wcl386.exe and the asm source is 64 bit (has all the new
registers).
How did you build the toolchain? What compiler did you use to compile Watcom
C++ source code producing 64 bit exes and dlls?
Great work!
Ricardo

http://www.gluster.org/2013/08/how-far-the-once-mighty-sourceforge-has-fallen/

Uh oh.

Lynn

[Steve Fabian]

Lynn McGuire wrote:
|
|
http://www.gluster.org/2013/08/how-far-the-once-mighty-sourceforge-has-fallen/
|

The name of the link says it all. The only issue for this NG is one Jiri can
answer: are the OW installers at SF infected, and if they are, when were
they infected? Jiri, if the files have been potentially infected, could you
provide us with the hash codes (CRC32, MD5, or SHA 1, 256, 384 or 512) to
the files along with the UTC time of the files through this NG so we could
verify our downloads.

[Lynn McGuire]

Post by Lynn McGuire
|
|
http://www.gluster.org/2013/08/how-far-the-once-mighty-sourceforge-has-fallen/
|
The name of the link says it all. The only issue for this NG is one Jiri can
answer: are the OW installers at SF infected, and if they are, when were
they infected? Jiri, if the files have been potentially infected, could you
provide us with the hash codes (CRC32, MD5, or SHA 1, 256, 384 or 512) to
the files along with the UTC time of the files through this NG so we could
verify our downloads.

I did not download. I was just happy to
see a version 2.0 of OW. But, just in the
issue of furtherance as I have no code in
2.0 (that I remember).

I would like to see an OW that automatically
uses the vector processors in the P4 / dual
core / quad core cpus.

Lynn

[Jiri Malak]

Steve,

I added file sums.md5 which contains MD5 files checksums.

Jiri

Post by Lynn McGuire
|
|
http://www.gluster.org/2013/08/how-far-the-once-mighty-sourceforge-has-

fallen/

Post by Lynn McGuire
|
The name of the link says it all. The only issue for this NG is one Jiri
can answer: are the OW installers at SF infected, and if they are, when
were they infected? Jiri, if the files have been potentially infected,
could you provide us with the hash codes (CRC32, MD5, or SHA 1, 256, 384
or 512) to the files along with the UTC time of the files through this NG
so we could verify our downloads.

[Steve Fabian]

Jiri Malak wrote:
|
| I added file sums.md5 which contains MD5 files checksums.

Much appreciated, Jiri. I plan to use that file nt only to validate
downloads, but also to determine which files changed since MY previous
(probably sporadic) download by comparing the current version with my last
download file by file. Though retaining the file order may make it simpler,
but with just a few files I can deal with any changes in order.

[tim_c]

Yes it is good news but...

I get an infection alarm in the download.

This may be a false alarm, matches some historic pattern

open-watcom-2_0-f77-win-x86.exe » ZIP » binw/cmdedit.exe - probably
unknown TSR.EXE virus

AV is ESET which is not particularly prone to false positives but does
find stuff often missed. It will be looking for zero-day.

I can report it but first lets hear what the file is about.

Post by Ricardo E. Gayoso
Hi Jiri,
It was nice to see a full OpenWatcom toolchain running as native Win64 (amd)
applications!
http://sourceforge.net/projects/openwatcom/
I also did wdis wcl386.exe and the asm source is 64 bit (has all the new
registers).
How did you build the toolchain? What compiler did you use to compile Watcom
C++ source code producing 64 bit exes and dlls?
Great work!
Ricardo

[n***@nospam.hotmail.com]

Have you ckecked MD5 sums to make sure integrity of downloaded version =
is =

OK?

Post by tim_c
Yes it is good news but...
I get an infection alarm in the download.
This may be a false alarm, matches some historic pattern
open-watcom-2_0-f77-win-x86.exe =C2=BB ZIP =C2=BB binw/cmdedit.exe - p=

robably

Post by tim_c
unknown TSR.EXE virus
AV is ESET which is not particularly prone to false positives but does=
find stuff often missed. It will be looking for zero-day.
I can report it but first lets hear what the file is about.

Post by Ricardo E. Gayoso
Hi Jiri,
It was nice to see a full OpenWatcom toolchain running as native Win6=

4 =

Post by tim_c

Post by Ricardo E. Gayoso
(amd)
applications!
http://sourceforge.net/projects/openwatcom/
I also did wdis wcl386.exe and the asm source is 64 bit (has all the =

new

Post by tim_c

Post by Ricardo E. Gayoso
registers).
How did you build the toolchain? What compiler did you use to compile=

=

Post by tim_c

Post by Ricardo E. Gayoso
Watcom
C++ source code producing 64 bit exes and dlls?
Great work!
Ricardo

-- =

Usando el cliente de correo de Opera: http://www.opera.com/mail/

[tim_c]

No means to do that but it's a zip which is another layer of integrity
checks over basic download. heanet to here works reliably.
(the file is quarantined, awkward to do much with it)

No rush on this one since I very much doubt there is actually an
infection neither do I want to create unnecessary waves.

Post by n***@nospam.hotmail.com
Have you ckecked MD5 sums to make sure integrity of downloaded
version is OK?

Post by tim_c
Yes it is good news but...
I get an infection alarm in the download.
This may be a false alarm, matches some historic pattern
open-watcom-2_0-f77-win-x86.exe » ZIP » binw/cmdedit.exe - probably
unknown TSR.EXE virus
AV is ESET which is not particularly prone to false positives but does
find stuff often missed. It will be looking for zero-day.
I can report it but first lets hear what the file is about.

Post by Ricardo E. Gayoso
Hi Jiri,
It was nice to see a full OpenWatcom toolchain running as native Win64 (amd)
applications!
http://sourceforge.net/projects/openwatcom/
I also did wdis wcl386.exe and the asm source is 64 bit (has all the new
registers).
How did you build the toolchain? What compiler did you use to compile Watcom
C++ source code producing 64 bit exes and dlls?
Great work!
Ricardo

[Steve Fabian]

tim_c wrote:
| No means to do that but it's a zip which is another layer of integrity
| checks over basic download. heanet to here works reliably.
| (the file is quarantined, awkward to do much with it)

Unless you have an extremely unwieldy AV you should be able to get it out of
"quarantine" so you can check it (e.g., compare the file with its hash code
reported by the author).

I had many software packages trigger false virus alarms, with some builds
OK, others misreported. Of course, OW is distriubted as source code (except
wgml), so you can just rebuild the executables and libraries and compare
with the supposedly infected file.

[tim_c]

Post by Steve Fabian
| No means to do that but it's a zip which is another layer of integrity
| checks over basic download. heanet to here works reliably.
| (the file is quarantined, awkward to do much with it)
Unless you have an extremely unwieldy AV you should be able to get it out of
"quarantine" so you can check it (e.g., compare the file with its hash code
reported by the author).
I had many software packages trigger false virus alarms, with some builds
OK, others misreported. Of course, OW is distriubted as source code (except
wgml), so you can just rebuild the executables and libraries and compare
with the supposedly infected file.

It's easy enough to check the whole archive, when I look the only md5
given. (AV merely prevents risky actions)

Not touched this stuff for a long time after a dismal experience over
confused signatures. I've installed the MS tool (no time to research
other tools). This gives a mismatch but I've nothing else on hand to
verify the tool.
Now, the entire archive pass download check and scans internally without
error, must pass other levels of checksums so this is strange.

Looks like I grabbed the wrong OW file anyway, SF proffers the f77
archive. The download count points to others doing the same.

Grab the correct one tomorrow.

[tim_c]

Both archives fail md5 but I don't know what actually is meant by md5
checksum, of what exactly? Two downloaded files as .exe do not hash here
to the value given in the .md5 file.

If I try to execute the installer I get the usual front page but with an
error notice, cannot find setup.inf (nothing to do with AV)

Post by tim_c

Post by Steve Fabian
| No means to do that but it's a zip which is another layer of integrity
| checks over basic download. heanet to here works reliably.
| (the file is quarantined, awkward to do much with it)
Unless you have an extremely unwieldy AV you should be able to get it out of
"quarantine" so you can check it (e.g., compare the file with its hash code
reported by the author).
I had many software packages trigger false virus alarms, with some builds
OK, others misreported. Of course, OW is distriubted as source code (except
wgml), so you can just rebuild the executables and libraries and compare
with the supposedly infected file.

It's easy enough to check the whole archive, when I look the only md5
given. (AV merely prevents risky actions)
Not touched this stuff for a long time after a dismal experience over
confused signatures. I've installed the MS tool (no time to research
other tools). This gives a mismatch but I've nothing else on hand to
verify the tool.
Now, the entire archive pass download check and scans internally without
error, must pass other levels of checksums so this is strange.
Looks like I grabbed the wrong OW file anyway, SF proffers the f77
archive. The download count points to others doing the same.
Grab the correct one tomorrow.

[Paul S. Person]

Post by tim_c
Both archives fail md5 but I don't know what actually is meant by md5
checksum, of what exactly? Two downloaded files as .exe do not hash here
to the value given in the .md5 file.

This /should/, as I understand it, mean that the file you got is not
the file the md5 given was computed on.

Post by tim_c
If I try to execute the installer I get the usual front page but with an
error notice, cannot find setup.inf (nothing to do with AV)

If it weren't for the md5 failure, I'd say it means that somebody
doesn't know how to write Windows installers (not that I do). But with
an md5 failure, it /could/ mean that somebody removed the setup.inf
file from the installer "just for fun".

The /real/ fun begins when the current version, say "_x23", can't
install because it can't find some file allegedly created by some
earlier version, say "_x14". Note that the older version is so old
that the user doesn't even remember installing it, never mind having a
clue as to where the file might be!

[tim_c]

I'm perplexed too, doesn't make sense.

I've now verified the Microsoft fciv hash tool for md5 and sha1 using
http://www.nsrl.nist.gov/testdata/ zip file near bottom of page.
fciv -both file

Oddly the archive extractor here cannot open the install archive but AV
can look inside. On looking closer I find the archiver in most but not
all cases can. (drat!)
Opening the file with a binary editor shows nothing unusual and Windows
will execute it.

That leaves the possibility the AV has altered the file to stop it being
opened but disable has previously meant just that, I handle live
infections sometimes, need to for testing systems or investigation.

This is getting too involved. Time to think about it.

Post by Paul S. Person

Post by tim_c
Both archives fail md5 but I don't know what actually is meant by md5
checksum, of what exactly? Two downloaded files as .exe do not hash here
to the value given in the .md5 file.

This /should/, as I understand it, mean that the file you got is not
the file the md5 given was computed on.

Post by tim_c
If I try to execute the installer I get the usual front page but with an
error notice, cannot find setup.inf (nothing to do with AV)

If it weren't for the md5 failure, I'd say it means that somebody
doesn't know how to write Windows installers (not that I do). But with
an md5 failure, it /could/ mean that somebody removed the setup.inf
file from the installer "just for fun".
The /real/ fun begins when the current version, say "_x23", can't
install because it can't find some file allegedly created by some
earlier version, say "_x14". Note that the older version is so old
that the user doesn't even remember installing it, never mind having a
clue as to where the file might be!

[Steve Fabian]

tim_c wrote:
| I'm perplexed too, doesn't make sense.
|
| I've now verified the Microsoft fciv hash tool for md5 and sha1 using
| http://www.nsrl.nist.gov/testdata/ zip file near bottom of page.
| fciv -both file

The FREE command processor TCC/LE from JPsoft.com (WinXP and later), and its
freeware predecessor 4DOS (for DOS and earlier versions of Windows) have
built-in functions to determine both the CRC32 and MD5 hash codes for files.
I used them to verify that Jiri's files I downloaded from SourceForge
matched Jiri's published hash codes in just a few minutes.

[tim_c]

Post by Steve Fabian
| I'm perplexed too, doesn't make sense.
|
| I've now verified the Microsoft fciv hash tool for md5 and sha1 using
| http://www.nsrl.nist.gov/testdata/ zip file near bottom of page.
| fciv -both file
The FREE command processor TCC/LE from JPsoft.com (WinXP and later), and its
freeware predecessor 4DOS (for DOS and earlier versions of Windows) have
built-in functions to determine both the CRC32 and MD5 hash codes for files.
I used them to verify that Jiri's files I downloaded from SourceForge
matched Jiri's published hash codes in just a few minutes.

Ah, good, that narrows things, thanks.

[Jeremy Nicoll - news posts]

Post by tim_c
AV is ESET which is not particularly prone to false positives but does
find stuff often missed. It will be looking for zero-day.

It's worth uploading the suspect file to VirusTotal to see what other a/v
products make of it: http://www.virustotal.com/

Be aware that VT send files that any a/v product thinks are infected to
various a/v vendors for them to examine more closely - which won't matter
here - but means sometimes VT isn't a good place to send confidential files
to.

[Wilton Helm]

This post might be inappropriate. Click to display it.