From Newsgroup: comp.os.msdos.programmer

On Wed, 8 Dec 2021 17:39:07 +0100
Herbert Kleebauer <klee@unibwm.de> wrote:

On 08.12.2021 10:16, R.Wieser wrote:

A program is written in order to be executed. To write a program

Why is 16-bit DOS programming a good choice in the year 2021?
The code below reads from stdin, converts any upper case to lower
case letters and writes it to stdout:

loop: bsr.l getc ; get char from stdin
cmpq.l #-1,r0 ; EOF
bne.b _10 ; branch if not
andq.l #0,r0
bsr.l exit

_10: cmp.b #'A',r0
blo.b _20
cmp.b #'Z',r0
bhi.b _20
add.b #'a'-'A',r0
_20: bsr.l putc ; write char to stdout
br.b loop ; go on

Is this 16 bit DOS or 32 bit Windows programming or is it even
a LINUX program?

[]

Now the answer to the above question, it is neither a DOS, Windows or Linux code,
it is all three at the same time. Just set OS to 0,1 or 2 and the assembler will generate an executable for the selected OS from the same source code. Not even a single byte is generated by the assembler or a linker which is
not explicitly specified in the source code.

[]
Wonderful stuff, but it's not a standard language. I suspect you also need am assembler/compiler that isn't available (without installing) on any of the OS's.

So why dis anyone doing their own thing?

(16bit x86 asm DOS for me, if you noticed my attempt at a tetris update)
--
Bah, and indeed Humbug.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.programmer

Herbert,

It doesn't matter how much software you have to install to create a
program.
But once created, it should be possible to execute the program on a
standard Windows installation without first installing additional
software.

It doesn't work that way for Windows programs ...

It is always frustrating if you copy a program on an USB drive
to use it on a different PC and then all what you get is: This program
can't be executed because ......

... and reading from the above you know it.

But if that is your yardstick I guess thats the end of the story. Its
over, curtains close, you all can go home now.


It has to be said though : where I can run those 16-bit DOS programs on any Win32 'puter and with the help of DOSBox also on a Win64 machine, your own 64-bit programs won't have it that easy. Apart from those dependancies they will never run on a Win32 machine, and they might also barf on an earlier version of Windows.

No, that's not the reason. I always used .com programs in DOS so I never had to mess around with segment registers.

lol. You are disagreeing with while agreeing with me. The only difference
is that you look at the COM model, while I thought of the EXE one.

To use 32 bit addressing modes has nothing to do with libraries.

In that case, might I maybe have ment something else ? And if so, what ? Maybe I was referring to something we already spoke of ? Do remember that
I also said "(or 64-bit)". Does that perhaps ring a bell ?

Playing dumb doesn't score you any points. It just shows what kind of
person you want to be.

This tells the compiler what he has to do, not how it has to be down.

Its hard isn't it ? Understanding the point of an example ? I've also
made no mention of a language, or if it would be compiled or not. Funny
how you seem know exactly what I've must have ment when it benefits you, but have lots of trouble figuring it out when it doesn't ...

Why is 16-bit DOS programming a good choice in the year 2021?

Why are you ignoring that I also mentioned other possible platforms ?

Is this 16 bit DOS or 32 bit Windows programming or is it even
a LINUX program?

Your point ?

*as opposed to slap-dashing some scripting / high-level language
together.

I would even go a step further and directly generate all bytes in
the executable file, this way you can see how the interface to the OS
works.

It looks like what you said has something to do with what you quoted there, but heaven knows what.

And no, you would not be able to do that. Or you would need to drop the
"the OS" and be more specific than that.

If it doesn't matter which platform you use, then there is no advantage
in using an obsolete platform instead of a current platform.

And you have been refusing to listen to what I've been telling you, only taking your own circumstances into account. On multiple points.

But it is a big disadvantage if the generated code can't be executed on a current platform.

And water is still wet ?

Now the answer to the above question, it is neither a DOS, Windows or
Linux code,
it is all three at the same time.

:-) Yeah, if you massage it enough I'm sure that you will be able to get something runnable outof it. Just have to either replace those "getc" and "putc" pseudos with code outof some library, wrap some target-environment specific initialisation and finalisation code around it and sure it will do something.

You will have no clue what is actually executed though.

Heck, maybe that compiler you mentioned earlier wil just replace it with something else altogether !

Just set OS to 0,1 or 2 and the assembler will generate an executable for the selected OS from the same source code.

"You keep using that word, Assembler. I don't think it means what you think it means."
-- The princes bride.

As for that listing below it ? Nope, its not. Its several programs -
which do not even need to be doing the same* - pushed together and using the preprocessor to filter the selected parts out - and ofcourse some of the
above mentioned massaging of its pseudos.

*and if youre not /very/ carefull *will* do something different. Perhaps even on purpose ...

But hey, if your thing is to "prove" that you can have some program that
will work on multiple platforms than you failed. Before you can run it
you first need to pull it thru that "Assembler" of yours, and than it looses all of its multi-platform capabilities.


But lets draw the line here.

You've shown that for you only your own circumstances matter (even ignoring that I mentioned other environments and languages), as well as rather
quickly deviating from the subject to something else you think you can control.

So, goodbye. Have a good life.

Regards,
Rudy Wieser

P.s.
I did not actually try to look at that lengthy code. Your description made clear that you tried to do the "assembly" equivalent of a "portable" C program. And thats old hat.



--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.programmer

On 08.12.2021 18:37, Kerr-Mudd, John wrote:

I suspect you also need am assembler/compiler that isn't available (without installing) on any of the OS's.

As I already said, it doesn't matter what you have to install
to create a program. But the created program should run without
the need of additional software/libraries which are not part of
a standard OS installation. The assembler I use is a single exe
file and doesn't need to be "installed". And the C source of the
assembler (also only a single C file) can be compiled with any
C compiler.

So why dis anyone doing their own thing?

Because I learned more about assembly programming writing the
assembler than writing assembly programs using the assembler.

(16bit x86 asm DOS for me, if you noticed my attempt at a tetris update)

I know, but I can't test the programs because they don't run in
64 bit Windows. Why not do it with 1024 byte 32 bit exe files instead
of 256 byte 16 bit com files?
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.msdos.programmer

On Wed, 8 Dec 2021 22:31:50 +0100
Herbert Kleebauer <klee@unibwm.de> wrote:

On 08.12.2021 18:37, Kerr-Mudd, John wrote:

I suspect you also need am assembler/compiler that isn't available (without installing) on any of the OS's.

As I already said, it doesn't matter what you have to install
to create a program. But the created program should run without
the need of additional software/libraries which are not part of
a standard OS installation. The assembler I use is a single exe
file and doesn't need to be "installed". And the C source of the
assembler (also only a single C file) can be compiled with any
C compiler.

So why dis anyone doing their own thing?

Because I learned more about assembly programming writing the
assembler than writing assembly programs using the assembler.

That's worthy, but it isn't everyone's path.

(16bit x86 asm DOS for me, if you noticed my attempt at a tetris update)

I know, but I can't test the programs because they don't run in
64 bit Windows. Why not do it with 1024 byte 32 bit exe files instead
of 256 byte 16 bit com files?

Sorry.

'cos I'm stuck in the past? I'm late to the demoscene!
1k - ridiculous overhead!
--
Bah, and indeed Humbug.
--- Synchronet 3.21d-Linux NewsLink 1.2