DOS ain't dead

OpenWatcom 1.7 final has just been released on 18 August 2007.

Website: http://www.openwatcom.org/
Changes: http://www.openwatcom.org/index.php/C_Compilers_Release_Changes
Download: http://www.openwatcom.org/index.php/Download

> Download: http://www.openwatcom.org/index.php/Download

But open_watcom_1.7.0-src.tar.bz2 (or .zip) is still missing.

---
Forum admin

> > Download: http://www.openwatcom.org/index.php/Download
>
> But open_watcom_1.7.0-src.tar.bz2 (or .zip) is
> still missing.

Probably because they haven't truly finished packaging it up yet. But if you're impatient, just get the daily pack (ow_daily.tar.bz2, 21-Aug-2007 00:32, 25M).

P.S. I can't understand why put sources in both .ZIP and .BZ2. Bzip2 can be unpacked even in very low memory via -s (albeit quite a bit slower) and obviously offers better text compression. (And LPAQ1 probably'd be even better, but probably no chance of that, heh.)

---
Know your limits.h

> Download: http://www.openwatcom.org/index.php/Download

See also:

http://openwatcom.org/index.php/Alternative_Open_Watcom_distribution

DOS related info added by rr

> P.S. I can't understand why put sources in both .ZIP and .BZ2

Many projects even triple-secure their packages by offering ZIP, TAR-GZIP and TAR-BZIP2 files ... you know, you can't expect any acceptance of TAR from "Windows" users ... and GZIP is for low-memory (2 MiB or less) machines running Loonix ... but don't ask me how they get it working

Did anyone test the WATCOM 1.7 ? Better than 1.6 ? Linker fully working ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > Download: http://www.openwatcom.org/index.php/Download
>
> See also:
>
> http://openwatcom.org/index.php/Alternative_Open_Watcom_distribution
>
> DOS related info added by rr

I know, I've seen that, but that .ZIP collection hasn't been updated for 1.7 (yet?? Arkady??)

> > P.S. I can't understand why put sources in both .ZIP and .BZ2
>
> Many projects even triple-secure their packages by offering ZIP, TAR-GZIP
> and TAR-BZIP2 files ... you know, you can't expect any acceptance of TAR
> from "Windows" users ... and GZIP is for low-memory (2 MiB or less)
> machines running Loonix ... but don't ask me how they get it working
>

Well, .ZIP is flexible archiving, allowing partial recovery if the file is somewhat corrupted (same with Bzip2, but this is usually less available b/c of the default 900kb blocksize). The only real reason to use .TGZ is that it's slightly better compression than .ZIP (due to solid, all-in-one compression instead of compressing files individually). But like I said, LPAQ1 compresses even better than Bzip2, even when only using 6 MB of RAM.

> Did anyone test the WATCOM 1.7 ? Better than 1.6 ? Linker fully working ?

I haven't really tested it yet, but where are we expected to report bugs to? (Their newsgroups??)

---
Know your limits.h

> > Did anyone test the WATCOM 1.7 ? Better than 1.6 ? Linker fully working
> ?

the severe bug in v1.6 - 32bit DOS extended binaries did pass an invalid environment pointer when launching another application - has been fixed in v1.7, so yes, v1.7 works better.

btw, DOS386, I'm sure the OW people would be very happy if there is a volunteer thoroughly testing the DOS binaries *before* the final version is released. What about you? That would be a(nother) good chance to do something constructive for DOS.

> I haven't really tested it yet, but where are we expected to report bugs
> to? (Their newsgroups??)

Yes. There is also http://bugzilla.openwatcom.org/

---
MS-DOS forever!

> DOS related info added by rr

Uh, you're sooo funny.

> Did anyone test the WATCOM 1.7 ? Better than 1.6 ? Linker fully working ?

I successfully tested RC2 with zlib and lspci.
Gisle Vanem used 1.7 final for Watt-32.

---
Forum admin

> > Download: http://www.openwatcom.org/index.php/Download
>
> But open_watcom_1.7.0-src.tar.bz2 (or .zip) is
> still missing.

Full source code has been made available by now.

---
Forum admin

> > Did anyone test the WATCOM 1.7 ? Better than 1.6 ? Linker fully working
> ?
>
> I successfully tested RC2 with zlib and lspci.
> Gisle Vanem used 1.7 final for Watt-32.

Obviously they never did put in the LFN stuff automatically for DOS (a la DJGPP) like they wanted. Granted, I guess it's more complicated than that (having to update the CLIB or whatever), but I was still hoping!

---
Know your limits.h

> Obviously they never did put in the LFN stuff automatically for DOS (a la

Yes, that's a pity.

> DJGPP) like they wanted. Granted, I guess it's more complicated than that
> (having to update the CLIB or whatever), but I was still hoping!

There's so much to do in the DOS world... Maybe we should focus on one or two proejcts instead of ten.

---
Forum admin

> I know, I've seen that, but that .ZIP collection hasn't been updated for
> 1.7 (yet?? Arkady??)

Arkady will do it "later".

---
Forum admin

> > I know, I've seen that, but that .ZIP collection hasn't been updated for
> > 1.7 (yet?? Arkady??)
>
> Arkady will do it "later".

Info-Zip supports "-f" (freshen) and "-u" (update), so I doubt it'd be hard for any of us to manually upgrade our pre-existing .ZIPs. Of course, is it worth it? (Some people still use 1.3, for freak's sake! What was so great / stable about that one?)

---
Know your limits.h

> > Arkady will do it "later".
>
> Info-Zip supports "-f" (freshen) and "-u" (update), so I doubt it'd be
> hard for any of us to manually upgrade our pre-existing .ZIPs. Of course,

Then please do so, but tell it to Arkady too.

---
Forum admin

> > DOS related info added by rr
>
> Uh, you're sooo funny.

Sorry, I didn't notice this article's author name.
But I'm not that "Rr". I don't know, who he/she is.

---
Forum admin

> There's so much to do in the DOS world...

I know, weird eh? But lots of stuff is (now) outdated / buggy, so it has to be reimplemented (usually b/c closed src, doh!).

> Maybe we should focus on one or two proejcts instead of ten.

Easier said than done!!!

---
Know your limits.h

> > Maybe we should focus on one or two proejcts instead of ten.
>
> Easier said than done!!!

Yes. But so we don't get bored.

---
Forum admin

> has been fixed in v1.7, so yes, v1.7 works better.

16-bit also works better, or same at least ?

> sure the OW people would be very happy if there is a volunteer thoroughly
> testing the DOS binaries *before* the final version is released. What about
> you? That would be a(nother) good chance to do something constructive for DOS.

Thanks for the idea, but I'm not the appropriate person. As you might know/suspect, my C knowledge (even worse C++ , WATCOM supports - or is supposed to support at least) in not the best (thanks to ladsoft for some recent improvements ) and ... I don't like the language too much (ASM is much better ) and ... see below

rr wrote:

> so much to do in the DOS world... Maybe we should focus on one or two proejcts instead of ten.

Definitely. In "Category: 32-bit C compiler" my priority is CC386 . It is far more promising for DOS and matches my needs much better.

[+] CC386 is much less messy and bloated (very important for me)
[+] CC386 has a very good support (very important for me)
[+] CC386 has an IDE coming (important for me also)
[+] CC386 can output ASM (very important for me)
[+] CC386 supports inline ASM with usable syntax (important for me)
[+] CC386 has a DOS download package (YES, I am sensitive to issues like this)

[-] CC386 supports no C++ (but will later ?) (not important for me)
[-] CC386 doesn't support 16-bit RM (obviously critical for FreeDOS kernel, but not "directly" for me, 16-bit RM C code is disgusting for me )
[-] CC386 can't compile MPXPLAY nor VGAP386 as-is (but the syntax of them is horrrrrible, differences are more than justified)
[-] CC386 has less "optimization" than VCC (probably also GCC and WATCOM) (not very important for me)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > has been fixed in v1.7, so yes, v1.7 works better.
>
> 16-bit also works better, or same at least ?

Better.

> Definitely. In "Category: 32-bit C compiler" my priority is CC386.

It's nice, but I don't need another compiler.

> It is far more promising for DOS and matches my needs much better.
>
> [+] CC386 is much less messy and bloated (very important for me)

OK

> [+] CC386 has a very good support (very important for me)

It's one person's "baby". Who knows, what happens in the future?

> [+] CC386 has an IDE coming (important for me also)

DJGPP already has RHIDE, but you can easily use any other text editor.

> [+] CC386 can output ASM (very important for me)

Same for DJGPP and probably Open Watcom.

> [+] CC386 supports inline ASM with usable syntax (important for me)

Same for DJGPP.

> [+] CC386 has a DOS download package (YES, I am sensitive to issues like
> this)

DJGPP is DOS.

---
Forum admin

> > [+] CC386 is much less messy and bloated (very important for me)
>
> OK

OpenWatcom ain't too bloated if all you want is DOS host / target, probably around (just guessing) like 5 MB .ZIP'd (or 10 MB or so unpacked / UPX'd).

> > [+] CC386 supports inline ASM with usable syntax (important for me)
>
> Same for DJGPP.

I know recent GASes support Intel syntax, but I haven't ever (looked for or) seen any examples. Know of any? (I assume yes.)

P.S. I was coding a stupid app today in both Micro-C 3.23 and TC++ 1.01, and they both support inline assembly similarly (both via ArrowASM, use /Easm.exe for TC++). Of course, Micro-C is wimpier but smaller.

> > [+] CC386 has a DOS download package (YES, I am sensitive to issues
> like
> > this)
>
> DJGPP is DOS.

Very very good (compatible) compiler but not optimal for small apps.

> [-] CC386 doesn't support 16-bit RM (obviously critical for FreeDOS
> kernel, but not "directly" for me, 16-bit RM C code is disgusting for
> me )

Yes, the FreeDOS kernel can be compiled by Turbo C (very easy, tried it successfully) or OpenWatcom (haven't succeeded yet, didn't try too too hard, does FreeDOS need it to be in C:\WATCOM ??).

---
Know your limits.h

> [+] CC386 is much less messy and bloated (very important for me)
> [+] CC386 has a very good support (very important for me)
> [+] CC386 has an IDE coming (important for me also)
> [+] CC386 can output ASM (very important for me)
> [+] CC386 supports inline ASM with usable syntax (important for me)
> [+] CC386 has a DOS download package (YES, I am sensitive to issues like
> this)
>
> [-] CC386 supports no C++ (but will later ?) (not important for me)
> [-] CC386 doesn't support 16-bit RM (obviously critical for FreeDOS
> kernel, but not "directly" for me, 16-bit RM C code is disgusting for me
> [-] CC386 can't compile MPXPLAY nor VGAP386 as-is (but the syntax of them
> is horrrrrible, differences are more than justified)
> [-] CC386 has less "optimization" than VCC (probably also GCC and WATCOM)
> (not very important for me)

there are probably some points missing:

[-] CC386 has a rather small "user base", so the possibility that it will be you who discovers new bugs is rather high.
[-] CC386 is a "one person" project, which most likely will die if this person looses interest.
[-] CC386 has no debugging support for 32bit protected-mode DOS.

IMO, taking everything into account, Open Watcom currently is ways more important for DOS than CC386. And please note that there IS support for DOS in Open Watcom. Please don't repeat the silly claims done by the "Evil DoctoR" admin that OW has virtually abandoned DOS support! You just cannot step in and force the people to fix bugs or add features you would like to have, you will need to convince someone to do the job or do it yourself.

---
MS-DOS forever!

> there are probably some points missing:
>
> [-] CC386 has a rather small "user base", so the possibility that it will
> be you who discovers new bugs is rather high.

Yes, but it's worth it, CC386 is very useful and fun too.

CC386 has improved a lot since I've been testing (past year or two), due more to David's massive work ethic than mine.

> [-] CC386 is a "one person" project, which most likely will die if this
> person looses interest.

He hasn't lost interest yet, and it's been a few years.

> [-] CC386 has no debugging support for 32bit protected-mode DOS.

+v used to work (but I haven't tried it recently), doesn't that count? (Or did you mean symbolic or source-level only?)

> IMO, taking everything into account, Open Watcom currently is ways more
> important for DOS than CC386.

Well, it's more ambitious since it covers 16-bit and 32-bit stuff (as well as other OSes). It's indeed very good (and used a lot because it's the official compiler of FreeDOS). Some things of theirs won't compile with CC386 because of explicit 16-bit support (e.g. XCOPY).

---
Know your limits.h

> DOS in Open Watcom. Please don't repeat the silly claims done by the "Evil
> DoctoR" admin that OW has virtually abandoned DOS support! You just cannot

Has anyone seen the source code of OpenWatcom? It would be more difficult to get rid of dos code than to keep it.
There are a lot of nice things in it like a windowing library that allows you to make windows32/16 gui, windows console, DOS32 and OS/2 windowed applications from the same code. For example debugger and installer use those libraries, so dos, win and OS/2 versions build from the same source.
Really nice things, just not commented and documented (at all).

> [-] CC386 has a rather small "user base", so the possibility that it will
> be you who discovers new bugs is rather high.

Very true

> [-] CC386 is a "one person" project, which most likely will die if this
> person looses interest.

Very true ... I just hope it won't happen soon, and, I don't absolutely have to throw away something just because maintainer[s] has/have gone ... I don't need doubling the number of "features" every 6 months

> IMO, taking everything into account, Open Watcom currently is ways more
> important for DOS than CC386.

Because of FreeDOS kernel.

> And please note that there IS support for DOS in Open Watcom.
> Please don't repeat the silly claims

I'll be happy to notice this and shut up with "silly claims"

OTOH, > 1 year ago, after OW 1.5 release, bringing nothing than regressions and new criminal bugs, verified by several trusted experts, including you (Japheth), criticism was the sad truth and not a "silly claim"

> force the people to fix bugs or add features you would like to have

... or even worse to remove "features"

> need to convince someone to do the job or do it yourself.

Very true. That's the experience and the reason for avoiding HL compilers as much as possible and preferring ASM not having this silly problem by design

Matjaz wrote:

> seen the source code of OpenWatcom? It would be more difficult
> to get rid of dos code than to keep it.

Not true. Dead code can remain (anyone cares about bloat ? ), just remove "official" support ...

Rugxulo wrote:

> FreeDOS). Some things of theirs won't compile with
> CC386 because of explicit 16-bit support (e.g. XCOPY).

Possibly the kernel also

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > 16-bit also works better, or same at least ?
> Better.

Very good. Hoping preliminary results will persist

> It's nice, but I don't need another compiler.

OK ... for me it is the first usable C one

> DJGPP already has RHIDE, but you can easily use any other text editor.

RHIDE is buggy, as well as all (?) editors except Kinesics and (almost) FASMD

> Same for DJGPP (output ASM)

Unusable GAS syntax

> and probably Open Watcom. (output ASM)

Anyone can confirm this ? What syntax ?

> Same for DJGPP (inline ASM)

GAS

> DJGPP is DOS.

YES

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > DJGPP already has RHIDE, but you can easily use any other text editor.
>
> RHIDE is buggy, as well as all (?) editors except Kinesics and (almost)
> FASMD

Kinesics is not open source, so fix RHIDE, if you really need it.

EDIT: You can get a Kinesics tar source archive for UNIX systems, but its license is unclear to me.

> > Same for DJGPP (output ASM)
>
> Unusable GAS syntax

GAS supports .intel_syntax noprefix for seven years now (since binutils version 2.10)!

---
Forum admin

> Has anyone seen the source code of OpenWatcom? It would be more difficult
> to get rid of dos code than to keep it.
> There are a lot of nice things in it like a windowing library that allows
> you to make windows32/16 gui, windows console, DOS32 and OS/2 windowed
> applications from the same code. For example debugger and installer use
> those libraries, so dos, win and OS/2 versions build from the same
> source.
> Really nice things, just not commented and documented (at all).

I looked into WASM, WLINK and WD source code. Once I made a change to WLINK. This worked, but I was successful only because I know "by heart" the formats of binaries and object modules. Besides the lack of comments there is another disadvantage IMO: the WD tools want to cover all platforms and formats, which inevitably requires to implement many "layers" and makes the source more difficult to understand than necessary.

---
MS-DOS forever!

> > > Same for DJGPP (output ASM)
> >
> > Unusable GAS syntax
>
> GAS supports .intel_syntax noprefix for seven years now
> (since binutils version 2.10)!

gcc -s -S -Os -masm=intel myfile.c -o myfile.asm (it works, just tested)

---
Know your limits.h

> RHIDE is buggy, as well as all (?) editors except Kinesics and (almost)
> FASMD

All large programs have bugs. But many editors are still usable and more powerful than Kinesics, which doesn't do much and has no DOS version.

> OTOH, > 1 year ago, after OW 1.5 release, bringing nothing than
> regressions and new criminal bugs, verified by several trusted experts,
> including you (Japheth), criticism was the sad truth and not a "silly
> claim"

criticism in form of a bug report is no problem. The "silly claim" I meant - IIRC - was kind of "OW has no DOS installer, therefore it is no DOS application anymore (and should be ignored by DOS users)".

---
MS-DOS forever!

> > RHIDE is buggy, as well as all (?) editors except Kinesics and (almost)
> > FASMD
>
> All large programs have bugs. But many editors are still usable and more
> powerful than Kinesics, which doesn't do much and has no DOS version.

I use TDE mostly, but VILE is darn good, too (as well as XVI).

I assume you're aware of rr's "new" compiles of FED and JED (plus the recently mentioned mined and FTE). Also, some people love SETEDIT or VIM or GNU Emacs or ZED or TPE or even Freemacs. My favorite ultra tiny one these days is EZEDIT. (Yes, everybody and their brother has written a text editor, and they're usually very different but cool.)

Anyways, Japheth just updated S.ZIP (SD.EXE is the DOS version, only 61k UPX'd, now has HDPMI32 built-in!). Maybe you'll enjoy that!

NTOSKRNL_VXE, that should keep you busy for a while.

---
Know your limits.h

> I assume you're aware of rr's "new" compiles of FED and JED

FED yes, JED no. rr: Where are you hiding it?

> > I assume you're aware of rr's "new" compiles of FED and JED
>
> FED yes, JED no. rr: Where are you hiding it?

It's easier to just get it from me than wait for him.

http://www.geocities.com/snoopimeanie/jed9918d.zip (.EXE dated May 30, 2007)

---
Know your limits.h

> > FED yes, JED no. rr: Where are you hiding it?
>
> It's easier to just get it from me than wait for him.
>
> http://www.geocities.com/snoopimeanie/jed9918d.zip (.EXE dated May 30,
> 2007)

Got it. Thanks!

> get a Kinesics tar source archive for UNIX systems, but its license is unclear to me.

At least it's 100% safe and legal to use the binary

> GAS supports .intel_syntax noprefix for seven years now
> (since binutils version 2.10)

I had known this (except that for exactly 7.00000000 years ...) but does GCC accept it for inline ASM as well ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Steve wrote:

> many editors are still usable and more powerful than Kinesics, which
> doesn't do much and has no DOS version.

Kinesics does well what it's supposed to (want more ?) on DOS, yeah ... the native DOS version indeed is obsolete, 16-bit and unusable.

Rugxulo wrote:

> Anyways, Japheth just updated S.ZIP

Sure you're aware that it's NOT a text editor

> (SD.EXE is the DOS version, only 61k UPX'd

NO. It's 102 KiB (without UPX)

> now has HDPMI32 built-in!). Maybe you'll enjoy that!

Very good

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Steve wrote:
>
> > many editors are still usable and more powerful than Kinesics, which
> > doesn't do much and has no DOS version.
>
> Kinesics does well what it's supposed to (want more ?) on DOS, yeah ...
> the native DOS version indeed is obsolete, 16-bit and unusable.

Right, there's only an old crappy DOS version. In a Windows editor (or any other program that's supposed to do real work), yes, I want more. As I see it, there's no reason to put up with low functionality and Windows overhead.

> > get a Kinesics tar source archive for UNIX systems, but its license is
> unclear to me.
>
> At least it's 100% safe and legal to use the binary

For some that's not enough.

> > GAS supports .intel_syntax noprefix for seven years now
> > (since binutils version 2.10)
>
> I had known this (except that for exactly 7.00000000 years ...) but does
> GCC accept it for inline ASM as well ?

Why did you not try it yourself?

int main()
{
   asm(".intel_syntax noprefix");
   asm("mov eax, 3");
   asm("int 0x10");
   asm(".att_syntax prefix");
   return 0;
}

Build command: gcc -Wall -O2 -s main.c -o main.exe

---
Forum admin

> Why did you not try it yourself?
int main()
{
   asm(".intel_syntax noprefix");
   asm("mov eax, 3");
   asm("int 0x10");
   asm(".att_syntax prefix");
   return 0;
}
> Build command: gcc -Wall -O2 -s main.c -o main.exe

Thanks. I don't have it installed now and it always made me angry in the past

Would one asm be sufficient for a ASM block ? And ".att_syntax prefix" is obligatory at he end ?

What to download if I want the most "raw" (C->ASM) GCC (no libs, no "autoconf", no RHIDE, no Ada/Fortran/C++ , ...) ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Japheth wrote:

> I looked into WASM, WLINK and WD source code. Once I made a change to WLINK

What about WASM ? In not very far past (cca 2 months ago) you claimed WASM to be an unusable toy - is this still valid for 1.7 ? Is WASM the only bad piece inside ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Would one asm be sufficient for a ASM block ? And ".att_syntax
> prefix" is obligatory at he end ?

You could also write (\n are mandatory!):

int main()
{
   asm("mov eax, 3\n"
       "int 0x10\n");
   return 0;
}

Build command: gcc -Wall -O2 -s -masm=intel main.c -o main.exe

If you need to write large assembly snippets, it's better to write separate .S files for GAS or just use NASM.

see Brennan's Guide to Inline Assembly for more information

> What to download if I want the most "raw" (C->ASM) GCC (no
> libs, no "autoconf", no RHIDE, no Ada/Fortran/C++ , ...) ?

1) Try the DJGPP Zip File Picker.
2) You need "v2/djdev203.zip", "v2gnu/bnu217b.zip", "v2gnu/gcc421b.zip". That's less than 10 MiB. (Older versions are usually smaller.)

---
Forum admin

> Sure you're aware that it's NOT a text editor

I think I will rename it to SINATE.

---
MS-DOS forever!

> FED yes, JED no. rr: Where are you hiding it?

It's here: jed9918d.zip

There will be a new version in the next two weeks. But expect only minor changes.

---
Forum admin

> > Sure you're aware that it's NOT a text editor
>
> I think I will rename it to SINATE.

I assume he's just being silly because it does hex too, perhaps?

---
Know your limits.h

> If you need to write large assembly snippets, it's better to write
> separate .S files for GAS or just use NASM.

Or Yasm or FASM (duh). Or, better yet, just use __dpmi_int() for real mode stuff and int86() otherwise (I think??).

> 1) Try the DJGPP Zip
> File Picker.
> 2) You need "v2/djdev203.zip", "v2gnu/bnu217b.zip", "v2gnu/gcc421b.zip".
> That's less than 10 MiB. (Older versions are usually smaller.)

Even from that, you can delete a lot of stuff and still get what you want. (There used to be EZ-GCC for DJv1, but that's > 10 years ago, so I've never tried it, not recommended b/c age ... v2 is much much better).

I've actually wanted for a while to make a stripped down DJGPP download (preferably UHarc'd or maybe LPAQ1'd or even 7-ZIP'd) without .INF or .VER / .MFT or weird utils like OBJDUMP / READELF (or whatever those dumb things are called) that you don't need for compiling. But last I checked, it didn't fit (UHarc'd, unUPX'd in order to improve compression) on one 1.44 MB floppy anymore, and I'm hesitant to use an older DJDEV (e.g. 2.01) b/c bugs. I'm sure there's a way, though ("where there's a will ...").

---
Know your limits.h

> > > Sure you're aware that it's NOT a text editor
> >
> > I think I will rename it to SINATE.
>
> I assume he's just being silly because it does hex too, perhaps?

Don't see the silly point

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> You could also write (\n are mandatory!):
...
> Build command: gcc -Wall -O2 -s -masm=intel main.c -o main.exe

Thanks. Better, but still a bit silly

> If you need to write large assembly snippets, it's better to write
> separate .S files for GAS or just use NASM.

YES.

> Try the DJGPP Zip File Picker

That's where I usually fail

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > > > Sure you're aware that it's NOT a text editor
> > >
> > > I think I will rename it to SINATE.
> >
> > I assume he's just being silly because it does hex too, perhaps?
>
> Don't see the silly point

If he puts a hex on you, then you will see the point.

> What about WASM ? In not very far past (cca 2 months ago) you claimed WASM
> to be an unusable toy - is this still valid for 1.7

AFAICT WASM hasn't evolved much from OW v1.6 to v1.7., so I think it is still valid to call it "unusable toy". The biggest problems are:

- you cannot be sure that the codegen works flawlessly
- local labels inside a proc not supported

---
MS-DOS forever!

> > Try the DJGPP Zip File Picker
>
> That's where I usually fail

Just kidding? If not, what's the problem?

---
Forum admin

> > > > > Sure you're aware that it's NOT a text editor
> > > >
> > > > I think I will rename it to SINATE.
> > >
> > > I assume he's just being silly because it does hex too, perhaps?
> >
> > Don't see the silly point
>
> If he puts a hex on you, then you will see the point.

Actually, my bad, it's NOT a text editor, only a text "viewer" and hex "editor" (strangely). It sure looks like a text editor, though.

---
Know your limits.h

> > If he puts a hex on you, then you will see the point.
>
> Actually, my bad, it's NOT a text editor, only a text "viewer" and hex
> "editor" (strangely). It sure looks like a text editor, though.

I was thinking Japheth was having a little joke, inspired by these guys:
Website http://www.sinate.net/