Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

MSDOS 4.0 -- MASM as standard (Announce)

posted by kerravon E-mail, Sydney, Free World South, 29.04.2025, 21:43

> > Name clash.
> >
> > as86 as shipped on the PDOS/386 disk.
> >
> > https://github.com/robertapengelly/as86
>
> I see a Makefile.wcd there, is it using OpenWatcom's wmake?
I use pdmake, but I just tried wmake, and it worked too:

wmake -h -e -a -ms -f makefile.wcd

(although I didn't rebuild pdpclib so I got a link error)

> It does (allegedly) produce a large model DOS .EXE.
>
> Wmake does support "*wcl" for longer cmdlines (indirectly via env vars). It
> also has "rm" built-in and some other nifty features.
>
> (Speaking of "standard", why force Gmake on BSD? They have their own
> make.)
So once again, I consider nmake to be standard, and
you should use a subset of that.

> > It's a subset of masm and completely public domain.
> >
> > This is what I see as the future - enhancing this
> > public domain assembler so that it gets closer to
> > be able to do things like assemble MSDOS 4.0 source code.
>
> I see your point, but MASM has a lot of heavy features. I don't think even
> TASM fully supported them all.
Sure. So use a subset of masm, so that you can use
a competitor to Microsoft.

While the professionals can still use the commercially
supported assembler.

> In particular, one thing that MASM and TASM supported was memory references
> without square brackets, e.g. "MOV MyWordVar,13" instead of "MOV
> [MyWordVar],13". This is somewhat ambiguous (albeit more concise) and not
> supported by almost anyone else (over a dozen different assemblers), so not
> just NASM.
So don't write code like that.

> Macros, structs, preprocessor, outputs, and other weird features. For just
> a "simple" assembler program, MASM is overkill.
So don't use those features.

In a professional setting, they may use those features
(that's likely why the features exist in the first place).
And then professionals will be stuck with Microsoft.
They probably don't mind being stuck with Microsoft,
and don't even consider it to be "stuck".

They likely consider it to be "stuck" if they use syntax
supported only by nasm, so any issue they get they have
to pay full unlimited western contract rates to someone
on the internet to fix it. Instead of simply switching to
a commercially-supported competitor.

> Yes, it was popular, but no, it's not standard (or even commonly
> supported).
A subset is commonly supported.

> > > > > unlike the MASM that ships with the
> > > > > 2024 April MS-DOS v4 release. So therefore I think NASM is better.
>
> They ship MASM v5, right?
They ship 5.1, yes.

D:\devel\DOS4\TOOLS>masm
Microsoft (R) Macro Assembler Version 5.10
Copyright (C) Microsoft Corp 1981, 1988. All rights reserved.


> > Yes, Microsoft has always set the standard in this area.
>
> MS does not always support standards. Their BASICs were never "standard".
> However, I think C# did get a few standards, and some things (e.g.
> PowerShell, which even runs on Linux) are written in it.
I didn't say MS set the standard for BASIC. There is an
ISO committee for that, I believe.

Are you saying that MS BASIC doesn't even supported the
first version of the ISO standard?

> I would not hold their work up as a good example of standard anything (nor
I am not aware of any part of the ISO/IEC 9899:1990
standard that Microsoft violates in any of their
compilers since Microsoft C 6.0. Perhaps you could
show me an example?

> Linux although some few people may try). Some people are more interested in
> feature creep and competitive advantages rather than portability to
> unsupported, no longer sold OSes or cpus. (Modern software seems to
> primarily care about x64 and AArch64.)
Sure - different people have different goals. If
someone wants to jump on the FSF bandwagon then
that limits their choices to certain software.

They live in the free world - go for it!

I'm just saying I personally don't want to get
involved because I have a different goal.

In the osdev community there are heaps of people
writing OSes - and they all write the exact same
Unix clone. And they all abandon it after a short
time. So we have 50 million mini Unix clones available.

Noone at all sat down for 30+ years to write something
that was a mini Microsoft clone.

Well. Just one person. With a different goal to
everyone else.

> > Actually, I consider whatever works on masm, wasm, jwasm and as86
> > to be "standard".
I should have included "tasm", which is still
available commercially and supported.

> Just from (admittedly limited) personal experience, very few IA-16
> assemblers agree on anything.
They all have incompatible extensions in the hope that
you will become beholden to their product.

I don't want to become beholden to any of them, so I
use a subset that works on all.

> It's not like C or Pascal (with actual
> standards) although even there, differences exist. (MASM was originally
> written in Pascal but switched to their C compiler for mixed memory model
> speedups. Of course, MASM also stopped being DOS-hosted in 1995, stopped
> being sold as a separate product later, and removed all 16-bit instruction
> support in 2010, IIRC. OS/2 support is also long gone.)
Visual Studio 2022 with x64 to x86 command line:

C:\devel\pdos\pdpclib>ml -DPOLLUTE -c -nologo -DMSC -D__SZ4__ -Dmemodel=huge -omf dosstart.asm
Assembling: dosstart.asm

C:\devel\pdos\pdpclib>dir dosstart.*
Volume in drive C has no label.
Volume Serial Number is 2E16-A311

Directory of C:\devel\pdos\pdpclib

2025-04-29 07:52 PM 6,955 dosstart.asm
2025-04-30 05:30 AM 464 dosstart.obj


I didn't test it beyond that. I use an older version.

> Standards exist, even unofficial ones, but you more or less have to cope
> with your own workarounds.
I'm already doing that. And I've been doing that
since around 1989-ish - using tasm and trying to
write my assembler code so that it works on masm
as well. Although I rarely wrote in assembler. I
instead wrote in C90 and used Turbo C 2.0.

> (It's feasible to write a Sed script to quickly
> adapt syntax between assemblers for specific bits of code.)
So - convert all the code to standard masm/tasm/as86
syntax before shipping if it's so easy, so that people
don't need to learn a non-standard language.

> "Standard"? You don't strictly need it.
Correct. You only really need food, shelter and clothing.

> You can roll your own syntax.
I can remember a line from during the Iraq war.

A US spokesman was showing Al Jazeera TV to a group
of Iraqis and pointing out all the lies.

And an Iraqi asked a question - "Are you saying we
shouldn't watch Al Jazeera?".

His reply was "It's my job to tell you what you should
or shouldn't watch. It's a free country. Watch whatever
you want."

> Admittedly weird (and annoying when everybody is incompatible) but totally
> valid if you can prove it's better somehow (ahem, TASM's Ideal mode).
Absolutely. Depending on your goals, you may well be
happy to use TASM's ideal mode and tie yourself down
to one commercially supported assembler.

Or use nasm and tie yourself down to one assembler that
is supported by yourself or whoever you can afford to
pay to wade through thousands of lines of copyrighted
(by someone else) code to fix their code.

Some people still watch Al Jazeera too. Admittedly I'm
one of those though. I don't think they lie on the
English version and give me more coverage of what I'm
interested in (Syria). (or was interested in, anyway -
right at the moment I am interested in NE executables
and am doing a hexdump of an OS/2 1.0 executable so
that I can answer Robert's questions so that he can
add support to slink - which again I consider to be
the future of 16-bit - I'm using it for a reason - but
yes, different people have different goals).

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22552 Postings in 2097 Threads, 401 registered users, 56 users online (1 registered, 55 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum