News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Strange behavior of DOS assemblers

Started by Gunther, November 22, 2021, 12:14:47 PM

Previous topic - Next topic

Gunther

Attached to this post is the archive video.zip. The folder video has two subdirectories: video1 and video2. In both is the source code and the running EXE of a simple Real Mode DOS program. In addition I have written a
batch file to generate the EXE with JWASM for DOS.

That's the background: At the moment I have to program for a company in an embedded DOS with an 80386 without FPU. Everything must run in 32 bit Protected Mode. I use therefore BIOS interrupts if possible. These
can be used in Real Mode as well as in Protected Mode. Why? A good DOS extender - like HX from Japheth - simply reflects the BIOS interrupts.

The logic of the program is very simple: It waits for a keystroke by calling the procedure Wait and then goes back to the operating system. The BIOS interrupt 16h is used for Wait.

Video1.exe does exactly that. But video2.exe doesn't call Wait, but immediately falls back to the command line. The difference between both programs is only in the order of the first two lines.

video1.asm:

    .model small
    .386


video2.asm:

    .386
    .model small


All other lines of the source code are identical.

That's a strange thing to say. I'm clearly emphasizing here that this obviously has nothing to do with JWASM. The TASM 4 behaves in the same way. How it looks with MASM, I can not say, because I do not have ML 6.11.
Maybe someone can test this?

I have tested the programs under DOSBox 0.74-3, FreeDos 1.1 with VirtualBox and native DOS 7. The results are always the same.

But what is the cause of this behavior? The processor directive is only about code generation. It can be placed anywhere in the source code. Or am I seeing this wrong?
You have to know the facts before you can distort them.

HSE

I think all ML versions must work. But you have to use link16.exe. (Still I don't installed Dosbox here).
Equations in Assembly: SmplMath

nidud

#2
deleted

Gunther

Quote from: HSE on November 22, 2021, 12:46:01 PM
I think all ML versions must work. But you have to use link16.exe. (Still I don't installed Dosbox here).

Yes, they will work. But that's not the question. It is clear that you need a 16 bit linker. I bet that ML with link16 shows the same behavior.

Quote from: nidud on November 22, 2021, 12:49:12 PM
The bitness of the program is defined by the first segment, and as the default CPU is 8086 this will be WORD.
This is probably the cause. This thread is mainly for informational purposes. I have been writing DOS programs for 40 years now, but the behavior has surprised me. We live and learn.
You have to know the facts before you can distort them.

_japheth

Quote from: Gunther on November 22, 2021, 01:33:13 PM
This is probably the cause. ...We live and learn.

Definitely. BTW, you can make masm(jwasm generate a listing file that includes the internally generated statements - use cmdline options -Fl AND -Sg.
Dummheit, gepaart mit Dreistigkeit - eine furchtbare Macht.

Gunther

Quote from: _japheth on November 22, 2021, 05:24:39 PM
Definitely. BTW, you can make masm(jwasm generate a listing file that includes the internally generated statements - use cmdline options -Fl AND -Sg.

Andreas, that's a good point.  :thumbsup:
You have to know the facts before you can distort them.

Gunther

The processor directive can also be placed at the beginning of the source code. However, USE must then be used:

    .386
DGROUP group _DATA, STAK        ; automatic data group

_TEXT  segment word public use16 'CODE'
       assume  cs:_TEXT, ds:DGROUP, ss:STAK

_TEXT  ends


I've put a working example with the functionality of video1 as another attachment under post #1 of this thread.
You have to know the facts before you can distort them.