flat assembler
Message board for the users of flat assembler.

flat assembler > Main > format binary as "LE"

Author
Thread Post new topic Reply to topic
DOS386



Joined: 08 Dec 2006
Posts: 1904
Shocked World's first Shocked

Code:
;
; FASM example of creation of a linear ( exponential soon Very Happy )
; executable ("LE") for running on DOS/32A extender.
;
; Compiles directly from .ASM into .LE , no linker Very Happy
;
; 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 Very Happy )
;
; Size should be no problem, tested with 2 MiB, should
; support up to 2 Gib Wink
;

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 Very Happy
db 0,0,0,0    ; "level" ... of zeroizm
db 2,0             ; 80386
db 1,0       ; "OS/2" Osama's System Very Happy
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 Sad
; 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 Sad
; org $60
dd 0,0             ; "MD" offset & entries, useless junk Very Happy
dd $E0           ; Fixup offset 1, important in LX only !!!
dd $E0            ; Fixup offset 2, useless junk both LE and LX Wink
; 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 !!! Sad
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 Wink ***
; "org" $F0 minimum, always $10 bytes aligned

llcode:

      call  lleipbase
lleipbase:
      pop   edx              ; Pick "return" address Wink
      add   edx,tx1b-lleipbase
      mov   ah,9
      int   $21              ; Call DOS "API" Very Happy
      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: 415 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
Post 29 May 2007, 06:22
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7108
Location: Slovakia
is LE windows-only format?
Post 30 May 2007, 05:58
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Garthower



Joined: 21 Apr 2006
Posts: 158
Location: Ukraine
Not absolutely. It is used for DOS/32A extender, also for drivers for Windows 9x/ME.
Post 30 May 2007, 10:15
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
Watcom dos-extender (dos4/gw) also used LE, iirc...
Post 30 May 2007, 11:45
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7205
Location: Kraków, Poland
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.
Post 30 May 2007, 15:07
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2310
Location: Usono (aka, USA)
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.)
Post 31 May 2007, 04:31
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1904
Quote:
LE was indeed developed for OS/2 (and eventually evolved into LX


Right Very Happy

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
Post 31 May 2007, 23:02
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2310
Location: Usono (aka, USA)
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.
Post 04 Jun 2007, 13:54
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
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?
Post 04 Jun 2007, 14:28
View user's profile Send private message Visit poster's website Reply with quote
Japheth



Joined: 26 Oct 2004
Posts: 151
> 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?
Post 04 Jun 2007, 16:54
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1904
> 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
Post 05 Jun 2007, 01:07
View user's profile Send private message Reply with quote
Japheth



Joined: 26 Oct 2004
Posts: 151
> 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.
Post 05 Jun 2007, 03:52
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2310
Location: Usono (aka, USA)
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.
Post 25 Jul 2007, 06:55
View user's profile Send private message Visit poster's website Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
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 Laughing

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.
Post 25 Jul 2007, 15:32
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
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 Laughing

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.


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.

_________________
Image - carpe noctem
Post 25 Jul 2007, 21:46
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1904
> 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
Post 26 Jul 2007, 07:14
View user's profile Send private message Reply with quote
WindowsNT



Joined: 08 Jul 2008
Posts: 4
Location: Greece
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
Post 11 Jan 2019, 10:47
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< 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


Copyright © 1999-2019, Tomasz Grysztar.

Powered by rwasa.