Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.msdos.programmer > #4088 > unrolled thread

How to access stack-based data (strings) when SS <> DS ?

Back to article view | Back to comp.os.msdos.programmer

Contents

  How to access stack-based data (strings) when SS <>  DS ? "R.Wieser" <address@not.available> - 2021-12-04 08:56 +0100
    Re: How to access stack-based data (strings) when SS <>  DS ? "Kerr-Mudd, John" <admin@127.0.0.1> - 2021-12-04 12:47 +0000
      Re: How to access stack-based data (strings) when SS <>  DS ? "R.Wieser" <address@not.available> - 2021-12-04 15:57 +0100
        Re: How to access stack-based data (strings) when SS <>  DS ? "Kerr-Mudd, John" <admin@127.0.0.1> - 2021-12-04 16:13 +0000
          Re: How to access stack-based data (strings) when SS <>  DS ? "R.Wieser" <address@not.available> - 2021-12-04 18:41 +0100
            Re: How to access stack-based data (strings) when SS <>  DS ? "Kerr-Mudd, John" <admin@127.0.0.1> - 2021-12-04 20:28 +0000
              Re: How to access stack-based data (strings) when SS <>  DS ? "R.Wieser" <address@not.available> - 2021-12-05 08:56 +0100
                Re: How to access stack-based data (strings) when SS <>  DS ? "Kerr-Mudd, John" <admin@127.0.0.1> - 2021-12-05 10:32 +0000
                  Re: How to access stack-based data (strings) when SS <>  DS ? "R.Wieser" <address@not.available> - 2021-12-05 13:11 +0100
                    Re: How to access stack-based data (strings) when SS <>  DS ? "Kerr-Mudd, John" <admin@127.0.0.1> - 2021-12-05 12:21 +0000
                      Re: How to access stack-based data (strings) when SS <>  DS ? "R.Wieser" <address@not.available> - 2021-12-05 14:59 +0100
          Re: How to access stack-based data (strings) when SS <>  DS ? "R.Wieser" <address@not.available> - 2021-12-04 19:00 +0100
    Re: How to access stack-based data (strings) when SS <>  DS ? JJ <jj4public@gmail.com> - 2021-12-05 14:27 +0700
      Re: How to access stack-based data (strings) when SS <>  DS ? "R.Wieser" <address@not.available> - 2021-12-05 12:43 +0100
    Re: How to access stack-based data (strings) when SS <> DS ? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2021-12-05 22:25 -0800
      Re: How to access stack-based data (strings) when SS <> DS ? Mateusz Viste <mateusz@xyz.invalid> - 2021-12-06 09:30 +0100
      Re: How to access stack-based data (strings) when SS <> DS ? "R.Wieser" <address@not.available> - 2021-12-06 14:33 +0100
        Re: How to access stack-based data (strings) when SS <> DS ? Herbert Kleebauer <klee@unibwm.de> - 2021-12-06 19:01 +0100
          Re: How to access stack-based data (strings) when SS <> DS ? "R.Wieser" <address@not.available> - 2021-12-06 21:16 +0100
            Re: How to access stack-based data (strings) when SS <> DS ? Herbert Kleebauer <klee@unibwm.de> - 2021-12-07 00:19 +0100
              Re: How to access stack-based data (strings) when SS <> DS ? Mateusz Viste <mateusz@xyz.invalid> - 2021-12-07 09:31 +0100
              Re: How to access stack-based data (strings) when SS <> DS ? "R.Wieser" <address@not.available> - 2021-12-07 09:37 +0100
              Re: How to access stack-based data (strings) when SS <> DS ?   Newbie language. "R.Wieser" <address@not.available> - 2021-12-08 10:16 +0100
                Re: How to access stack-based data (strings) when SS <> DS ? Newbie language. Herbert Kleebauer <klee@unibwm.de> - 2021-12-08 17:39 +0100
                  Re: How to access stack-based data (strings) when SS <> DS ? Newbie language. "Kerr-Mudd, John" <admin@127.0.0.1> - 2021-12-08 17:37 +0000
                    Re: How to access stack-based data (strings) when SS <> DS ? Newbie language. Herbert Kleebauer <klee@unibwm.de> - 2021-12-08 22:31 +0100
                      Re: How to access stack-based data (strings) when SS <> DS ? Newbie language. "Kerr-Mudd, John" <admin@127.0.0.1> - 2021-12-09 21:43 +0000
                  Re: How to access stack-based data (strings) when SS <> DS ? Newbie language. "R.Wieser" <address@not.available> - 2021-12-08 22:19 +0100
        Re: How to access stack-based data (strings) when SS <> DS ? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2021-12-06 22:40 -0800
          Re: How to access stack-based data (strings) when SS <> DS ? "R.Wieser" <address@not.available> - 2021-12-07 10:17 +0100

Page 2 of 2 — ← Prev page 1 [2]

#4128 — Re: How to access stack-based data (strings) when SS <> DS ?

2021-12-07 at 00:19 +0100, Herbert Kleebauer 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.

In this line of thoughts, writing Java doesn't make sense, because it
requires installing a JRE first. Writing JavaScript doesn't make sense
because it requires a browser, even PHP is stupid because it is not
stand-alone executable code...

> Because normally a program is not only executed once. And if the
> code still can be useful in a few years, it shouldn't be written
> for a system which is obsolete already now.

16-bit code has bigger chances of being useful in a few years than a
"modern" code has, given that libraries change, operating systems
change, etc. DOS is one of the very few "APIs" that are stable, while
the rest of the IT ecosystem is a moving target. Nowadays it is easy to
run a 16-bit program in a browser. Try doing the same with any other
executable program.

> Even if done as a hobby, the result should be something useful.

Ah, I only noticed the name now... A German. Should've guessed earlier.

Mateusz

[toc] | [prev] | [next] | [standalone]

#4129 — Re: How to access stack-based data (strings) when SS <> DS ?

Herbert,

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

Fail.  No such destinction was made by you.  And you are talking to someone 
who (obviously?) has been doing 16-bit programming for a while now.  IOW, it 
looks like you are shifting goalposts.

> Because normally a program is not only executed once.

Fail again, as you making an assumption towards what *I* do with the result. 
I could ofcourse tell you I've written 16-bit programs years ago that I 
still use, but somehow I think you will just discard that as an "exception 
to the rule".

> Even if done as a hobby, the result should be something useful.

And thats the actual point, isn't it ?   You do not see the usefullness of 
what I'm doing.

But instead of asking you just come out challenging me, suggesting that I 
should stop doing it, even though I enjoy doing it.

And for the record, enjoying doing something is all thats needed for a 
hobby - even if the result is of no use to anyone, including the one 
practicing it.    I'm sure you can think of a few hobbies like that..   I'll 
give you the first one : collecting sugar sachets..

> Why mess around to make pictures with a camera.

You hit the nail on the head, but do not seem to be aware of it ....

Why /would/ you take pictures ?   You would just waste *heaps* of time 
making them, on possibly /very/ expensive equipment.  And than spend even 
more time on tagging them, possibly color-correcting, cropping and than 
sorting/putting them into easy-findable-and-viewable groups.     All so they 
can be shown off to people who, more often than not, do not really care.

And by the way, I've got a friend which does all of the above, and is 
mulling to go professional.  He's simply that good.  Something he would not 
have known if he hadn't picked up  photographing as a hobby ...

> but many programs written for MSDOS can still be executed in the current 
> 32 bit Windows version.

Funny, the thing you started with was claiming that they wouldn't - and that 
I, for that reason, should not be doing any 16-bit programming (anymore) ...

> The problem is, that AMD removed v86 mode in 64 bit mode

So they should have to support a 16 /as well as/ a 32 bit mode next to the 
native, 64-bit one ?   'Cause that is what they did : just like a 32-bit 
processor supported a 16-bit mode (one step down), a 64-bit processor now 
supports a 32-bit mode.

> Microsoft didn't add a software DOS emulator in 64 bit Windows.

Than look around a bit.  Don't expect MS to just drop everything into your 
lap.  Google for "DOSBox 64-bit".

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#4132 — Re: How to access stack-based data (strings) when SS <> DS ? Newbie language.

Herbert,

A reply to your "no good for starters" claim :

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

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

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.

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.

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

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

Though I think that programming machine code on a micro controller, possibly 
mounted on a model car or a robotic something, would be even better : most 
people need, especially when starting, to see a direct result of what they 
have put their energy into.

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.

I hope that answers your (second, new) question.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#4133 — Re: How to access stack-based data (strings) when SS <> DS ? Newbie language.

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

             KERNEL32_ExitProcess:
                 dc.w    0
                 dc.b    'ExitProcess',0
                 even
             KERNEL32_GetStdHandle:
                 dc.w    0
                 dc.b    'GetStdHandle',0
                 even
             KERNEL32_ReadFile:
                 dc.w    0
                 dc.b    'ReadFile',0
                 even
             KERNEL32_WriteFile:
                 dc.w    0
                 dc.b    'WriteFile',0
                 even
         seg32
         winmain::

       ENDIF

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

       IF OS==2        ; Linux
         seg32
         @=$08048000
         code_offset=@@
         code_addr:
;--------------------------- ELF header -----------------------------------
         dc.l $464c457f,$00010101,0,0,$00030002,1,main,$34,0,0,$00200034,2,0
         dc.l 1,code_offset,code_addr,code_addr,code_filez,code_memsz,5,4096
         dc.l 1,data_offset,data_addr,data_addr,data_filez,data_memsz,6,4096
;--------------------------- code ------------------------------------------
         main:
       ENDIF

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

;MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
;MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
;MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM

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


;MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
;MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
;MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM



;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;  OS specific functions: getc, putc, exit                        ;;
;;  0: DOS  1: WINDOwS  2: LINUX                                   ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


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

IF OS==0        ; DOS

getc:   eor.l   r0,r0
         movem.l r0-r7,-(sp)
         move.w  #$3f00,r0
         lea.w   28.b(r7),r1
         move.w  #1,r2
         eor.w   r3,r3
         trap    #$21
         bcs.b   _20
         cmp.w   r0,r2
         movem.l (sp)+,r0-r7
         beq.b   _10
         move.l  #-1,r0
    _10: rts.l
    _20: move.b  #-1,r0
         br.b    exit

putc:   movem.l r0-r7,-(sp)
         move.w  #$4000,r0
         lea.w   28.b(r7),r1
         move.w  #1,r2
         move.w  r2,r3
         trap    #$21
         bcs.b   _20
         cmp.w   r0,r2
         bne.b   _20
         movem.l (sp)+,r0-r7
         rts.l
    _20: move.b  #-1,r0
         br.b    exit

exit:   move.b  #$4c,m0
         trap    #$21

ENDIF

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

IF OS==1        ; WINDOWS

getc:   eor.l   r0,r0
         movem.l r0-r7,-(sp)
         lea.l   28.b(r7),r1
         move.l  r0,-(sp)
         move.l  r7,r2

         add.l   _handle,r0
         bne.b   _10
         moveq.l #-10,-(sp)
         jsr.l   (GetStdHandle)
         move.l  r0,_handle

_10:    moveq.l #0,-(sp)
         move.l  r2,-(sp)
         moveq.l #1,-(sp)
         move.l  r1,-(sp)
         move.l  r0,-(sp)
         jsr.l   (ReadFile)
         move.l  (sp)+,r1
         or.l    r0,r0
         bne.b   _20
         orq.l   #-1,r0
         br.b    exit
_20:    cmp.l   #1,r1
         movem.l (sp)+,r0-r7
         beq.b   _30
         move.l  #-1,r0
_30:    rts.l

         even4
_handle:dc.l    0


putc:   movem.l r0-r7,-(sp)
         lea.l   28.b(r7),r1
         move.l  r0,-(sp)
         move.l  r7,r2

         eor.l   r0,r0
         add.l   _handle,r0
         bne.b   _10
         moveq.l #-11,-(sp)
         jsr.l   (GetStdHandle)
         move.l  r0,_handle

_10:    moveq.l #0,-(sp)
         move.l  r2,-(sp)
         moveq.l #1,-(sp)
         move.l  r1,-(sp)
         move.l  r0,-(sp)
         jsr.l   (WriteFile)
         move.l  (sp)+,r1
         or.l    r0,r0
         bne.b   _20
_30:    orq.l   #-1,r0
         br.b    exit
_20:    cmp.l   #1,r1
         bne.b   _30
         movem.l (sp)+,r0-r7
         rts.l

         even4
_handle:dc.l    0


exit:   move.l  r0,-(sp)
         jsr.l   (ExitProcess)   ; exit program

ENDIF

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

IF OS==2        ; LINUX

getc:   eor.l   r0,r0
         movem.l r0-r7,-(sp)
         move.l  #0,r3           ; stdin
         lea.l   28.b(r7),r2
         move.l  #1,r1           ; 1 byte
         move.l  #3,r0           ; read
         trap    #$80
         tst.l   r0,r0
         bmi.b   _10
         movem.l (sp)+,r0-r7
         bne.b   _20
         orq.l   #-1,r0
    _20: rts.l
    _10: orq.l   #-1,r0          ; return code
         br.b    exit


putc:   movem.l r0-r7,-(sp)
         move.l  #1,r3           ; stdout
         lea.l   28.b(r7),r2
         move.l  #1,r1           ; 1 byte
         move.l  #4,r0           ; write
         trap    #$80
         cmpq.l  #1,r0
         bne.b   _10
         movem.l (sp)+,r0-r7
         rts.l
    _10: orq.l   #-1,r0          ; return code
         br.b    exit


exit:   move.l  r0,r3           ; return code
         move.l  #1,r0           ; exit
         trap    #$80

ENDIF
;===========================================================================
;===========================================================================


;===========================================================================
;===========================================================================
       IF OS==1        ; WINDOWS
         VSizeOf_text==@-Imagebase-VBaseOf_text
                 @a=@
                 evencom FileAlignment
                 @=@a

         FSizeOf_text==@@-FBaseOf_text
         SizeOfCode==FSizeOf_text

         FBaseOf_idat==@@
         VBaseOf_idat==(@-ImageBase+SectionAlignment-1)/SectionAlignment*SectionAlignment
         BaseOfData==VBaseOf_idat
         @=ImageBase+VBaseOf_idat
       ENDIF

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

       IF OS==2        ; Linux
         code_filez=@@-code_offset
         code_memsz= @-code_addr
         even 4
         @=(@+4095)/4096*4096+(@@\4096)
         data_offset=@@
         data_addr:
       ENDIF

;MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
;MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
;MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM

;--------------------------- initialized data ------------------------------
;some_initialized_data: dc.l    3

;MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
;MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
;MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM


;===========================================================================
       IF OS==1        ; WINDOWS

         VSizeOf_idat==@-Imagebase-VBaseOf_idat
                 @a=@
                 evencom FileAlignment
                 @=@a
         FSizeOf_idat==@@-FBaseOf_idat

         SizeOfInitializedData==FSizeOf_idat

         FBaseOf_udat==@@
         VBaseOf_udat==(@-ImageBase+SectionAlignment-1)/SectionAlignment*SectionAlignment
         @=ImageBase+VBaseOf_udat
       ENDIF

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

;MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
;MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
;MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM

;--------------------------- uninitialized data ----------------------------
;some_uninitialized_data: blk.b 20
;---------------------------------------------------------------------------

;MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
;MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM
;MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM

;===========================================================================
       IF OS==1        ; WINDOWS

         VSizeOf_udat==@-Imagebase-VBaseOf_udat
                 @a=@
                 evencom FileAlignment
                 @=@a
         FSizeOf_udat==@@-FBaseOf_udat

         SizeOfUninitializedData==VSizeOf_udat
         SizeOfImage==(@-ImageBase+SectionAlignment-1)/SectionAlignment*SectionAlignment
       ENDIF

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

       IF OS==2        ; Linux
         data_filez=@@-data_offset
         data_memsz= @-data_addr
       ENDIF

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

[toc] | [prev] | [next] | [standalone]

#4134 — Re: How to access stack-based data (strings) when SS <> DS ? Newbie language.

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.

[toc] | [prev] | [next] | [standalone]

#4136 — Re: How to access stack-based data (strings) when SS <> DS ? Newbie language.

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?

[toc] | [prev] | [next] | [standalone]

#4141 — Re: How to access stack-based data (strings) when SS <> DS ? Newbie language.

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.

[toc] | [prev] | [next] | [standalone]

#4135 — Re: How to access stack-based data (strings) when SS <> DS ? Newbie language.

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.

[toc] | [prev] | [next] | [standalone]

#4127 — Re: How to access stack-based data (strings) when SS <> DS ?

On Monday, December 6, 2021 at 5:33:38 AM UTC-8, R.Wieser wrote:
> Alexei,
> > I'd advise looking into some kind of macro assembly.
> Borlands Tasm does support macros. But alas, they do not measure up to the 
> inbuild method of calling procedures and its checking of the (ammount and 
> type of) provided arguments.
> > If your assembler can tell you where (in what segment) a variable 
> > is allocated
> Nope. That "lea dx,[bp-xxxx]" implicitily uses SS as its base. There is no 
> way to tell by looking at DX itself.

I'm not suggesting to magically deduce something from a register.
I'm thinking more of declaring a symbol for each string and deducing
the segment from that symbol (or it maybe a pair of symbols, one
for the offset, the other for the segment).

> > (assuming it can actually allocate a variable on the stack just like in 
> > the data segment)
> <huh?> You're the second one who doubts that, even though procedure-local 
> variables are a thing in most any language ...

I don't remember the details and they are important.

> > and if the assembler can conditionally assemble code based on that, 
> > then you can eliminate some unnecessary segment manipulation.
> I'm not at all sure I can override build-in menemonics to execute a macro 
> ... Otherwise I would need to add pseudo(?) code around pretty-much 
> everything.

I'm afraid that's unavoidable.

> > Lastly, perhaps you should be using segmented memory
> Isn't that what is what started my problem ? Putting DS into a different 
> segment than SS ?

Sorry, it should've been "should NOT be using segmented memory".

> > or you could generate code by some means other than the 
> > assembler and more higher level.
> :-) I like Assembly because it /doesn't/ hide all kinds of stuff from me. 

Then embrace it. Write all of the plumbing by hand. :)

Alex

[toc] | [prev] | [next] | [standalone]

#4130 — Re: How to access stack-based data (strings) when SS <> DS ?

Alexei,

> I'm thinking more of declaring a symbol for each string and deducing
> the segment from that symbol (or it maybe a pair of symbols, one
> for the offset, the other for the segment).

To be honest, I didn't think of that.

It would possibly be workable for simple situations, like the 
single-argument int 21h, AH=09h.   It wouldn't for anything that used more 
than one pointer argument (into different segments) though.

IOW, it would need constant scrutiny by me, the programmer, to make sure 
that all (applied by macros ?) "fixes" would actually work.  :-(    Ehh... 
no.  Although possible not really a solution.

> I don't remember the details and they are important.

I did not provide any other than "[stack based item]", which I thought would 
be picked up by anyone here as either "[bp-xxxx]" or "[sp+xxxx]".   I was 
mistaken. :-|

> I'm afraid that's unavoidable.

That is what I thought, but wanted to make sure I did not overlook anything 
/ something simpler.

>> > Lastly, perhaps you should be using segmented memory
>> Isn't that what is what started my problem ? Putting DS into a different
>> segment than SS ?
>
> Sorry, it should've been "should NOT be using segmented memory".

:-) In that case, I'm not (yet).    I've been using the "tiny" memory model 
where CS = DS = SS , as that one is easiest to work with and I simply have 
never had the need for more memory (in relation to those three segments).

Its just that I saw a possible situation (I was thinking about recursion and 
how it gobbles stack memory), and wondered how that would work.  As it turns 
out, not even Borland actually wished to burn their fingers on it - all its 
memory models set SS to the same as DS.

> Then embrace it. Write all of the plumbing by hand. :)

As programmers we're supposed to be "lazy".  If something repeats than we 
rather spend an hour to solve a 10 minute problem than to write it twice, 
let alone more than that. :-)

The bottom line is that a memory model with SS <> DS is simply no fun to 
deal with.   As I could have guessed if I would have looked at the offered 
memory models earlier.   Hmmm... Probably would not have stopped me from 
asking though. <whistle>

Regards,
Rudy Wieser

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.os.msdos.programmer

csiph-web