On 08.12.2021 10:16, R.Wieser wrote:

>> A program is written in order to be executed. To write a program
>> which can be executed on nearly none of the current computers
>> (without first installing additional software like DOSBox) doesn't
>> make much sense. And therefore it doesn't also make much sense for a
>> "starter" to start with 16 bit coding instead of the much easier
>> 32 bit coding.
>
> 1) In relation to "without first installing additional software ". Most
> programming languages need you to install software and configure it. Heaps
> of it. To create 16-bit programs al you need are three executables (an
> editor, the assembler and the linker) and *perhaps* (something like) DOSBox.

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 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 ......

> 2) Its "much easier 32 bit coding" was, IIRC related to having all segments
> ontop of each other. Funny thing that, as that is exactly what the "tiny"
> memory model does for a 16-bit program. Yes, because it makes things
> simple (my question was just about me thinking "outside the box").

No, that's not the reason. I always used .com programs in DOS so I
never had to mess around with segment registers. But I also used
32 bit registers and addressing modes in 16 bit DOS programs, because
that makes assembly programming so much easier.

> As for using 32-bit (or 64-bit) coding instead of 16-bit ? I don't think
> it matters much - though I think that the best way to learn actual
> programming is /not/ to have too much support from libraries and the like.

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

> When you have it becomes too easy to create monstrocities instead of the way
> more apropriate (smaller, faster) processor commands. One example I still
> remember is how someone using a higher language isolated a bit in a value :
> (SomeValue & 2^SomeBit) <> 0. Yuck.

This tells the compiler what he has to do, not how it has to be down.
Look at the generated code and you will see, that in most case the
compiler generates better code than an average assembly programmer.

> Bottom line : When learning to really program* I think that using a "dumb"
> target is best. 16-bit DOS programming would be a good choice, both because
> it offers only basic I/O support as well as most people nowerdays have
> computers and thus can do it anywhere (school as well as at home).

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?

> *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.

> In other words : Its not about which language or platform you use, as long
> as it teaches you what makes the bottom layer (the processor and I/O) tick,
> as well as makes you aware that everything comes with a cost (execution time
> and/or resource wise). Those are lessons that should be learned early on.

If it doesn't matter which platform you use, then there is no advantage
in using an obsolete platform instead of a current platform. But it is
a big disadvantage if the generated code can't be executed on a current platform.

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.

OS=0 ; 0: DOS 1: WINDOWS 2: LINUX ;;

;===========================================================================
;===========================================================================

IF OS==0 ; DOS
@=$100
ENDIF

;===========================================================================
;===========================================================================

IF OS==1
UseIdatSection=0 ; 0 if no idat section is used
UseUdatSection=0 ; 0 if no udat section is used

dc.w 'ZM',dosfilesize\512, (dosfilesize-1)/512+1
dc.w 0,doshead_end/16,0,$ffff,0,dosstack,0,dosmain
dc.w 0,reloc,0,0,0,0,0,0,0
dc.l 0,0,0,0,0,WinHeader
reloc:
doshead_end:
@=$0
dosmain:move.w s6,-(sp)
move.w (sp)+,s0
move.w #_text,r1
move.b #$09,m0
trap #$21
move.w #$4c01,r0
trap #$21
_text: dc.b 'Nice to meet somebody who is still using DOS,',13,10
dc.b 'but his program requires Win32.',13,10,'$'
even 16

dosstack=@+256
dosfilesize=@+256

ImageBase== $00400000
SectionAlignment== 4096
FileAlignment== 512
WinHeader=@@
@=ImageBase
dc.b 'PE',0,0
dc.w $014c,NumberOfSections
dc.l $36a57950,0,0
dc.w SizeOfOptionalHeader,$010f

@a=@
dc.w $010b
dc.b 5,12
dc.l SizeOfCode,SizeOfInitializedData,SizeOfUninitializedData
dc.l winmain-ImageBase,BaseOfCode,BaseOfData,ImageBase
dc.l SectionAlignment,FileAlignment
dc.w 4,0,0,0,4,0
dc.l 0,SizeOfImage,SizeOfHeaders, 0
dc.w 3 ; 2:GUI 3:character subsystem.
dc.w 0
dc.l $100000,$1000,$100000,$1000,$0,NumberOfRvaAndSize

@b=@
dc.l 0,0,imp_start,imp_size,0,0,0,0,0,0,0,0,0,0,0,0
dc.l 0,0,0,0,0,0,0,0,iat_start,iat_size,0,0,0,0,0,0
NumberOfRvaAndSize = (@-@b)/8
SizeOfOptionalHeader = @-@a

@a=@
dc.b '.text',0,0,0
dc.l VSizeOf_text,VBaseOf_text,FSizeOf_text,FBaseOf_text,0,0
dc.w 0,0
dc.l $e0000020

IF UseIdatSection
dc.b '.idat',0,0,0
dc.l VSizeOf_idat,VBaseOf_idat,FSizeOf_idat,FBaseOf_idat,0,0
dc.w 0,0
dc.l $e0000040
ENDIF

IF UseUdatSection
dc.b '.udat',0,0,0
dc.l VSizeOf_udat,VBaseOf_udat,FSizeOf_udat,FBaseOf_udat,0,0
dc.w 0,0
dc.l $e0000080
ENDIF

NumberOfSections=(@-@a)/40
evencom FileAlignment
SizeOfHeaders==@@

FBaseOf_text==@@
VBaseOf_text==(@-ImageBase+SectionAlignment-1)/SectionAlignment*SectionAlignment
BaseOfCode==VBaseOf_text
@=ImageBase+VBaseOf_text

iat_start=@-ImageBase

KERNEL32_thunk:
ExitProcess:: dc.l KERNEL32_ExitProcess -ImageBase
GetStdHandle:: dc.l KERNEL32_GetStdHandle -ImageBase
ReadFile:: dc.l KERNEL32_ReadFile -ImageBase
WriteFile:: dc.l KERNEL32_WriteFile -ImageBase
dc.l 0

iat_size=@-ImageBase-iat_start

imp_start==@-ImageBase
imp:

dc.l KERNEL32_import -ImageBase
dc.l 0
dc.l 0
dc.l KERNEL32_name -ImageBase
dc.l KERNEL32_thunk -ImageBase

dc.l 0,0,0,0,0

imp_size==@-imp

KERNEL32_name:
dc.b 'KERNEL32.dll',0
even

KERNEL32_import:
dc.l KERNEL32_ExitProcess -ImageBase
dc.l KERNEL32_GetStdHandle -ImageBase
dc.l KERNEL32_ReadFile -ImageBase
dc.l KERNEL32_WriteFile -ImageBase
dc.l 0
even

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.

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.

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?

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.