format binary as "LE"

Index > Main > format binary as "LE"

Author

Thread

DOS386

Joined: 08 Dec 2006
Posts: 1905

DOS386 29 May 2007, 06:22

World's first Shocked

Code:

;
; FASM example of creation of a linear ( exponential soon  )
; executable ("LE") for running on DOS/32A extender.
;
; Compiles directly from .ASM into .LE , no linker 
;
; Use "SB" tool to bind it with the extender.
;
; http://board.flatassembler.net/topic.php?t=7122
;
; Limitations:
; - No relocs (crappy anyway)
; - Only one "object" ( no problem, flat rules  )
;
; Size should be no problem, tested with 2 MiB, should
; support up to 2 Gib 
;

format binary as "LE"
use32
org 0

; *** Constants ***

ccstackp = 2 ; Stack size in pages ( 1 page = 4 KiB )

; *** Calculations ***

vvstackb = ccstackp shl 12                ; Pages -> Bytes
vvcodesize = llcodeend - llcode
vvcodep = ( vvcodesize + $0FFF ) shr 12 ; Bytes -> Pages
vvpagestotal = vvcodep + ccstackp
vvpagestotalali = ( vvpagestotal + 3 ) and $000FFFFC ; Align to integer multi of 4

vvcodepad = 2 ; Allign code size to integer multi of $10, and add 2 to make loader / DOS happy
vvtemp1 = vvcodesize and $0F ; Temp, find out used bytes on last 16-Bytes block
if vvtemp1 > 0
  vvcodepad = 18 - vvtemp1
end if

; *** LE / [LX] "Module Header" (0,$AC) ***

;org 0
db "LE"
db 0,0              ; Little endian, surprisingly 
db 0,0,0,0    ; "level" ... of zeroizm
db 2,0             ; 80386
db 1,0       ; "OS/2" Osama's System 
db 0,0,0,0    ; "module version"
; org $10
dd 0               ; "module type", crap
dd vvpagestotal   ; Number of pages total
dd 1,0                  ; CS:EIP object number (4 bytes) & offset (4 bytes)
; org $20
dd 2, vvstackb      ; SS:ESP object number (4 bytes) & offset (4 bytes)
dd $1000         ; Page size in bytes
dd 0            ; LX: "shift" alignement (4 -> $10 bytes) | LE: bytes on last page | crap 
; org $30
dd vvpagestotalali shl 2 , 0
; "fixup" size, chk | "size" may NEVER be 0 !!! Can be skipped in LE, but not empty
dd $30,0      ; "loader" size, chk
; org $40
dd $B0           ; Offset of the "Object table" (relative to "LE")
dd 2           ; Number of entries
dd $E0           ; LX: Offset of the "Object Page Table" | LE: Offset of object "Map" !!!
dd 0            ; Offset of ??? , "iterate" crap
; org $50
dd 0         ; Offset ressource table
dd 0        ; Number of entries
dd 0             ; Offset "resident" crap
dd 0              ; Offset of "entry" crap table 
; org $60
dd 0,0             ; "MD" offset & entries, useless junk 
dd $E0           ; Fixup offset 1, important in LX only !!!
dd $E0            ; Fixup offset 2, useless junk both LE and LX 
; org $70
dd 0,0            ; Import offset, count, both junk
dd 0,0             ; 2 more offsets, crap
; org $80
dd llcode     ; "Data pages offset" - where the code begins, relative to MZ, not "LE" !!!
        ; "SB" will care when binding ... just v. 7.1 won't - it has a BUG !!! 
dd 0,0,0      ; Some more crap
; org $90
dd 0,0,0,0    ; Useless "chk", "auto", 2 x deBUG
; org $A0
dd 0,0,0      ; Crap / "heap"

; *** Reserved / crap ($AC,4) ***

dd 0

; *** Object table entry #1 ($B0,$18 ) (main) ***

; Flags can be $2045 (R) or $2047 (R&W)

dd vvcodep shl 12 ; Size in bytes (we always align to 4 KiB)
dd 0           ; Base address won't work, let's set it to most funny value of 0
dd $2047          ; Flags: "huge 32-bit" | "preloaded" | "executable" | "writable" | "readable"
dd 1,vvcodep     ; "map" index (count from 1 ???) / entries
dd 0            ; Reserved / crap

; *** Object table entry #2 ($C8,$18 ) (stack) ***

; !!! Stack may *** NEVER *** be executable !!!

dd ccstackp shl 12    ; Size in bytes
dd 0                     ; Base address won't work
dd $2043          ; Flags: "huge 32-bit" | "preloaded" | "writable" | "readable"
dd 1+vvcodep,ccstackp ; "map" index / entries
dd 0                   ; Reserved / crap

; *** Object Page Map ($E0,n*$10 ) | Fixup 1st Table | Fixup 2nd Table ***

dd vvpagestotalali dup (0)   ; Crap, one "dd" zero needed per page

; *** Code, forget about "org", never loads correctly  ***
; "org" $F0 minimum, always $10 bytes aligned

llcode:

      call  lleipbase
lleipbase:
      pop   edx              ; Pick "return" address 
      add   edx,tx1b-lleipbase
      mov   ah,9
      int   $21              ; Call DOS "API" 
      jmp   llqq1
;----------------

tx1b: db $0D,$0A,'Hello from protected mode, using DOS/32A, coded with FASM !!!',$0D,$0A,$24

llqq1:
      mov   ax,$4C00        ; Return to DOS with error code 0
      int   $21
;--------------

llcodeend:

db vvcodepad dup (0)   ; Crap, to prevent unexpected EOF

;end.

I created the probably world's first LE executable using FASM.

The example exposes once more the superiority of linkers over FASM: my LE has 338 bytes, the matching "official" DOS/32A example compiling and linking with WATCOM has over 4 KiB, VALX produces over 8 Kib Shocked

Tested this "Hello World" and one bigger (cca 2 MiB, might upload it later when complete and mature) file, work like a charm, load as LE as well as compress using "SC" tool Smile

See also my MZ and PE examples:

http://board.flatassembler.net/topic.php?t=6735

LE comes from OS/2 .. there it got replaced by LX in 1992 (!!!) and is considered as obsolete ... but on DOS both LE and LX are acceptable.

My code is not compliant to anything (there is no "official" LE spec) except DOS/32A's loader and "SC" compressor. Also it requires position-independent-code - from my tests so far this is very easily doable and much better than linking and fixuping Laughing

So this is the easy way of coding big (USEDPMI loads into low memory only, up to cca 500 KiB) 32-bit DOS apps Smile

Description:	FASM LE example	Download
Filename:	FASLED32.ZIP
Filesize:	74.16 KB
Downloaded:	1253 Time(s)

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug

Last edited by DOS386 on 06 Aug 2007, 06:37; edited 5 times in total

29 May 2007, 06:22

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid 30 May 2007, 05:58

is LE windows-only format?

30 May 2007, 05:58

Garthower

Joined: 21 Apr 2006
Posts: 158
Location: Ukraine

Garthower 30 May 2007, 10:15

Not absolutely. It is used for DOS/32A extender, also for drivers for Windows 9x/ME.

30 May 2007, 10:15

f0dder

Joined: 19 Feb 2004
Posts: 3175
Location: Denmark

f0dder 30 May 2007, 11:45

Watcom dos-extender (dos4/gw) also used LE, iirc...

30 May 2007, 11:45

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland

Tomasz Grysztar 30 May 2007, 15:07

As I recall, LE was first introduced as an OS/2 native format.

I was trying to add the LE and LX output support quite early during the fasm development - some time between making the Win32 port and the Linux port, as I hoped to make an OS/2 port, too. This was abandoned, though.

30 May 2007, 15:07

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 31 May 2007, 04:31

From what I've read, LE was indeed developed for OS/2 (and eventually evolved into LX, possibly after MS parted ways with IBM?). NE is what Win16 used, and yes, DOS/4GW (and hence DOS/32a) uses LE also, even under DOS. I think CC386 and OpenWatcom are mostly your best bets for programming freely / openly in such formats, though.

The big problem, IMO, with OS/2 is that it ain't free or open source or popular (unlike DOS or Win32, both of which are somewhat understood in the coding world, hence FreeDOS + HXRT or WINE). DOSBox, at one time, ideally wanted to add OS/2 support. I wish they would, at least since Windows doesn't (any more??) support OS/2 binaries.

P.S. What exactly are the advantages to compiling a native OS/2 .EXE instead of just using DOS or Win16? I mean, why should people waste their effort for a separate OS/2 port (and yes, I think they probably should)? What features were just so inherently useful that warranted such?? (Never used OS/2, so I dunno.)

31 May 2007, 04:31

DOS386

Joined: 08 Dec 2006
Posts: 1905

DOS386 31 May 2007, 23:02

Quote:

LE was indeed developed for OS/2 (and eventually evolved into LX

Right

Quote:

think CC386 and OpenWatcom are mostly your best bets for programming freely / openly in such formats

WATCOM is first dead Crying or Very sad

... and then open, maybe. CC386 is promising ... but bloats the EXE's like any other 32-bit C compiler Confused

Quote:

big problem, IMO, with OS/2 is that it ain't free or open source or popular

Right ...

Quote:

exactly are the advantages to compiling a native OS/2 .EXE instead of just using DOS or Win16?

I see no benefit in OS/2 nor in Win3.xxx/Win16 ... while Win32 has __some__ thanks to HX-DOS Wink

31 May 2007, 23:02

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 04 Jun 2007, 13:54

OpenWatcom isn't dead (unless you mean commercially), but last I heard, it had no maintainer. And CC386 ain't that bloated, but yeah, it's not really an optimizing compiler. At least it's still updated! Smile

Since OS/2 was marketed at one time as "a better DOS than DOS and a better Windows than Windows", I imagine that the OS itself had some advantage. However, compiling to native OS/2 .EXE may not be that useful (dunno, really).

P.S. I have seen (as have you, probably) NE .EXEs that are dual DOS and Windows (e.g. old GNUish text utils). Also, I've seen dual .EXEs for DOS + OS/2 (e.g. older HIEW 6.11). However, both are pretty rare. Even DOS + Win32 .EXEs (e.g. G. Vollant's Extract) are quite seldomly found.

04 Jun 2007, 13:54

f0dder

Joined: 19 Feb 2004
Posts: 3175
Location: Denmark

f0dder 04 Jun 2007, 14:28

Afaik, OS/2 ran win16 apps better than win16... but it sorta lost it's edge once NT arrived. And iirc there were a few design problems wrt. messages and their queues.

Dunno about native OS/2, but it probably has some API advantages?

04 Jun 2007, 14:28

Japheth

Joined: 26 Oct 2004
Posts: 151

Japheth 04 Jun 2007, 16:54

> but last I heard, it had no maintainer.

It's no longer in the hands of SciTech, but it is still maintained, the newsgroups are active and a new release 1.7 is "about" to be supplied.

@NTOSKRNL: does the LE format have any advantages compared to PE?

04 Jun 2007, 16:54

DOS386

Joined: 08 Dec 2006
Posts: 1905

DOS386 05 Jun 2007, 01:07

> It's no longer in the hands of SciTech, but it is still maintained, the newsgroups are active and a new release 1.7 is "about" to be supplied.

We'll see the quality ... especially of the DOS target ... and host availability Wink

> does the LE format have any advantages compared to PE?

YES. Can be bound to DOS/32A:

1. Probably (once I got over all the Page Fouls my broken LE's used to produce Laughing

) the easiest way to create small and big 32-bit DOS apps in ASM

2. Small standalone EXE's (Hello World 27 KiB, PMODE would be smaller but lacks quality)

In fact I like neither LE nor PE (yeah ... there is NE also) ... for new development I consider FLAT as the best choice Wink

and I might try to code a FLAT DPMI loader with built-in HDPMI32 (should be legal ... with some minimal care Rolling Eyes

) allowing the same (compact, standalone) one day Wink

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug

05 Jun 2007, 01:07

Japheth

Joined: 26 Oct 2004
Posts: 151

Japheth 05 Jun 2007, 03:52

> We'll see the quality ... especially of the DOS target ... and host availability

Being "dead" or just having problems with the code quality due to a lack of manpower/interest is not quite the same.

05 Jun 2007, 03:52

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 25 Jul 2007, 06:55

Not trying to bump an old thread, but ...

I read that OS/2 supposedly pre-emptively multitasked vs. Win 3.x's cooperative multitasking, so that was supposedly better. Also, eCS ("new" OS/2 variant) can install / work on 64 MB machines as opposed to 512 MB (or whatever) for Win XP. But OS/2 supposedly had (has?) bad compatibility with hardware.

I think that's most people's advantage to Windows: hardware drivers and specific commercial apps that run nowhere else.

25 Jul 2007, 06:55

Dex4u

Joined: 08 Feb 2005
Posts: 1601
Location: web

Dex4u 25 Jul 2007, 15:32

NTOSKRNL_VXE wrote:

My code is not compliant to anything (there is no "official" LE spec) except DOS/32A's loader and "SC" compressor. Also it requires position-independent-code - from my tests so far this is very easily doable and much better than linking and fixuping

position-independent-code is fine if your coding small programs, but not if you need to code programs with 100's of lines of code Wink

25 Jul 2007, 15:32

f0dder

Joined: 19 Feb 2004
Posts: 3175
Location: Denmark

f0dder 25 Jul 2007, 21:46

Dex4u wrote:

NTOSKRNL_VXE wrote:
My code is not compliant to anything (there is no "official" LE spec) except DOS/32A's loader and "SC" compressor. Also it requires position-independent-code - from my tests so far this is very easily doable and much better than linking and fixuping

position-independent-code is fine if your coding small programs, but not if you need to code programs with 100's of lines of code .

It depends on how the PIC is done, and what support your language(s) have for it.

Using a register as a "load address" or "delta register" (call it what you want) is pretty elegant, load-time fixups require a relocation table and poses a couple of other problems. Of course using a full register sucks on x86 especially in 32-bit mode, because the number of registers are limited.

It'd be easy for your tools (including an assembler) to do all variable references through this register, without kludges... of course purists will frown at this, but imho it's not a bad idea (and could easily be toggleable for those who don't want it).

But again, it does require tool support to be comfortable, and it does suck a bit on x86... but of course you could always be able to push/pop the base-register if you need it temporarily for a critical innerloop/whatever.

_________________

- carpe noctem

25 Jul 2007, 21:46

DOS386

Joined: 08 Dec 2006
Posts: 1905

DOS386 26 Jul 2007, 07:14

> Also, eCS ("new" OS/2 variant) can install / work on 64 MB machines

Maybe ... but I'll stay with DOS & DexOS Wink

Dex4u wrote:

> position-independent-code is fine if your coding small programs, but not if you need to code programs with 100's of lines of code

I tested with a cca 2 MiB app (OK, most of it was multimedial data Laughing

) and maybe > 100 lines and was fine ... no > 100'000 lines test yet Wink

> load-time fixups require a relocation table and poses a couple of other problems.

YES. I dislike fixuping Sad

26 Jul 2007, 07:14

WindowsNT

Joined: 08 Jul 2008
Posts: 4
Location: Greece

WindowsNT 11 Jan 2019, 10:47

Many years since, but I 've included this (hopefully you are glad) in my Intel Article

https://www.codeproject.com/Articles/1273844/The-Intel-Assembly-Manual

11 Jan 2019, 10:47

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum