flat assembler
Message board for the users of flat assembler.

Index > DOS > [ask] Death of 16-DOS MZ... and rise of PE?

Author
Thread Post new topic Reply to topic
adroit



Joined: 21 Feb 2010
Posts: 252
adroit 19 Sep 2011, 22:05
Will the 16-bit DOS MZ format die because it is not compatible with the new architecture: Windows 7? Will 32-bit DOS PE take over?

Personally, i love programming in mz format but it cant be ran on win7 without an emulator. i am working on a framework or mini-micro library for 16-bit dos, but i am not sure if i should continue coding for 16-bit dos or just upgrade to 32-bit PE?

summary:
1. which better to code for, 16-bit mz dos or 32-bit dos pe?
2. should i upgrade to 32-bit programming for the sake of advancements?
3. which format to use for the library?

_________________
meshnix
Post 19 Sep 2011, 22:05
View user's profile Send private message Reply with quote
me239



Joined: 06 Jan 2011
Posts: 200
me239 20 Sep 2011, 00:25
adroit wrote:
Will the 16-bit DOS MZ format die because it is not compatible with the new architecture: Windows 7? Will 32-bit DOS PE take over?

Personally, i love programming in mz format but it cant be ran on win7 without an emulator. i am working on a framework or mini-micro library for 16-bit dos, but i am not sure if i should continue coding for 16-bit dos or just upgrade to 32-bit PE?

summary:
1. which better to code for, 16-bit mz dos or 32-bit dos pe?
2. should i upgrade to 32-bit programming for the sake of advancements?
3. which format to use for the library?

1) I personally like 16 bit more because it's simpler (or at least seems that way to me)
2) Only if you feel you should. Remember you can always create 32 bit DOS MZ executables
3) Either. You don't need to conform to everyone else's standard. Do which ever one you like more. Remember that you ALWAYS have more control sticking to MS-DOS.
On a side note, 16 bit EXE's do work on Windows 7, just not x64 platforms.
Post 20 Sep 2011, 00:25
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 20 Sep 2011, 02:16
16-bit is so limiting.

64KB segments (ugh!). You can't store much data before having to select another segment.

Only a subset of registers can be used for addressing. No scaling for indexes.


32-bit is so liberating.

No segmentation (yay!). Unless you have some huge requirement for data then 4GB is usually plenty.

All registers can be used for addressing. Indexes can be scaled.


64-bit is so limitless.

No segment registers (double yay!). Famous quote parody: "16EB of memory should be enough for anybody."

PC can be used for data addressing. 16 general purpose registers.
Post 20 Sep 2011, 02:16
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4347
Location: Now
edfed 20 Sep 2011, 02:37
i would like a 32 bits .com codetype.

yes, i'd like it.

imagine, if it is like the 16 bits one, it means that CS=DS=SS=2^N when N=16bits
and then, it means that CS=DS=SS=2^32 when N=32bits.

then, the maximal executable size would be 4gigabytes, data, stack and code in the same segment.

the fact that it is limited to 4G don't mean it needs 4G of ram to be present.
it would be better of course, and it will be the case in some time, maybe there will be soon many more than 64 GB ram on a computer, letting the system load up to 16 verrrrrrrrrrrrry big applications.

but before this, using the paging options of X86, and something like 32bit .com, the result would be a very simple way to think about computer programming.

paging is more easy to think when there is no segmentation.

then, the segmented model would be given up, and let the place to a flat model like org 100h one.

if one day i finally code something like an os, the model would be flat 32 bits model for everything.
with up to 4g of ram for application, starting at linear 0 (physical [page 0]).

with 4Kb pages, it will let share memory zones between applications, and maximise the use of paging mechanism.
4kb page is optimal when speaking about assembly programming, because it let think about the construction of code around a multitude of various independant little applications.

giving a minimal size of 4kb memory for applications will let a system launch a lot of applications, up to one million if you have 4Gbytes of ram.

4kb is a lot of memory for many little programs, and we like a lot to write little and useless programs.

fo datas too 4kb is a lot, in text, it represent 4000 chars, enough to contain one or two pages of a document.

think light, and stop to follow windows please, ok, the world is in a strange period, google, facebook, microsoft, etc... but please, stop following the tendency, lets remember the feeling of playing poor games, or displaying poor images on poor resolution monitors.

remember the feeling of a world in a time when high technology was that:
Image
http://www1.odn.ne.jp/~caa09810/old_pc/pc_tera.htm
it isn't so far.
Post 20 Sep 2011, 02:37
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 20 Sep 2011, 02:55
edfed wrote:
imagine, if it is like the 16 bits one, it means that CS=DS=SS=2^N when N=16bits
and then, it means that CS=DS=SS=2^32 when N=32bits.

then, the maximal executable size would be 4gigabytes, data, stack and code in the same segment.

the fact that it is limited to 4G don't mean it needs 4G of ram to be present.
it would be better of course, and it will be the case in some time, maybe there will be soon many more than 64 GB ram on a computer, letting the system load up to 16 verrrrrrrrrrrrry big applications.

but before this, using the paging options of X86, and something like 32bit .com, the result would be a very simple way to think about computer programming.

paging is more easy to think when there is no segmentation.

then, the segmented model would be given up, and let the place to a flat model like org 100h one.

if one day i finally code something like an os, the model would be flat 32 bits model for everything.
with up to 4g of ram for application, starting at linear 0 (physical [page 0]).

with 4Kb pages, it will let share memory zones between applications, and maximise the use of paging mechanism.
Oh, so you mean just like most existing 32-bit OSes around now? The only difference between what you write above and what existing 32-bit OSes do is that the .com file is not practical. The ELF and PE formats are used because of the extra flexibility.
Post 20 Sep 2011, 02:55
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1903
DOS386 20 Sep 2011, 06:13
adroit wrote:
Will the 16-bit DOS MZ format die because it is not compatible with the new


I don't know.

Quote:
I love programming in mz format but it cant be ran on win7


Again, code DOS-style for DOS or Win7-style for Win7.

Quote:
working on a framework or mini-micro library for 16-bit dos


What is the lib supposed to do ?

Quote:
not sure if i should continue coding for 16-bit dos or just upgrade to 32-bit PE?


Or 64-bit PE ... do you really want to push into an oversaturated market ??? Confused

Quote:
1. which better to code for, 16-bit mz dos or 32-bit dos pe?


Note: DOS PE <> Win32 PE. It's NOT only about format. DOS PE will NOT run on Win7 either.

Quote:
2. should i upgrade to 32-bit programming for the sake of advancements?


You can brew 32-bit DOS apps. You also can brew DOS-compatible Win32-PE (see my examples). They run on DOS (using HX, needs at least 80386), Win32 and Win64, and WHINE. No high level GUI then.

Quote:
3. which format to use for the library?


Again, it's not only about format. It's about what OS you want to support.

> 32-bit is so liberating.
> No segmentation (yay!).

Complicated and poorly working PM.

> 64-bit is so limitless.
> No segment registers (double yay!).

Single NO:

> "swapgs" is the new instruction, which swaps the contents of GS register and
> the KernelGSbase model-specific register (MSR address 0C0000102h).

> Famous quote parody: "16EB of memory should be enough for anybody."

You waste only 128 Byte's of RAM just for pushing those general purpose registers (not including flags, FPU/MMX, SSE, SSE2, SSSE3, SSSSE4, ...).

> IBM PC can be used for data addressing. 16 general purpose registers

Paging is always ON Sad

Setup is extremely painful Sad

Code is heavily bloated Sad

99.99% of Intel design faults are NOT fixed.

edfed wrote

> would like a 32 bits .com codetype.
> yes, i'd like it.

You still don't realize that DOS COM is just a DOS-only 16-bit-only format. There is no most universal COM format natively running everywhere, even on 68000 Smile

PS: as you might guess, I prefer stuff that works in DOS (only or also).

_________________
Bug Nr.: 12345

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

Status: Closed: NOT a Bug
Post 20 Sep 2011, 06:13
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 20 Sep 2011, 07:01
DOS386 wrote:
> IBM PC can be used for data addressing. 16 general purpose registers
PC = Program Counter.
Post 20 Sep 2011, 07:01
View user's profile Send private message Visit poster's website Reply with quote
adroit



Joined: 21 Feb 2010
Posts: 252
adroit 20 Sep 2011, 12:32
Thanks guys for the replies Smile

--
me239
me239 wrote:
1) I personally like 16 bit more because it's simpler (or at least seems that way to me)
2) Only if you feel you should. Remember you can always create 32 bit DOS MZ executables
3) Either. You don't need to conform to everyone else's standard. Do which ever one you like more. Remember that you ALWAYS have more control sticking to MS-DOS.
On a side note, 16 bit EXE's do work on Windows 7, just not x64 platforms.
16-bit is simpler, and that's why I'd like to use it, but I think 32-bit MZ is more versatile (I think). "You don't need to conform to everyone else's standard. Do which ever one you like more. Remember that you ALWAYS have more control sticking to MS-DOS." Exactly. Smile There are many things that can be done with DOS MZ. Direct access to memory, allowing self modifiable code. I don't know if 32-bit PE can do that.


--
revolution
revolution wrote:
16-bit is so limiting.

64KB segments (ugh!). You can't store much data before having to select another segment.

Only a subset of registers can be used for addressing. No scaling for indexes.


32-bit is so liberating.

No segmentation (yay!). Unless you have some huge requirement for data then 4GB is usually plenty.

All registers can be used for addressing. Indexes can be scaled.


64-bit is so limitless.

No segment registers (double yay!). Famous quote parody: "16EB of memory should be enough for anybody."

PC can be used for data addressing. 16 general purpose registers.
Now you see my dilemma.
No segmentation is great. "No segmentation (yay!). Unless you have some huge requirement for data then 4GB is usually plenty. All registers can be used for addressing. Indexes can be scaled." Oh the freedom, but DOS386 asked a very important question that made me think a little about the format to use, but I'll get to that later.

"PC can be used for data addressing. 16 general purpose registers." How can you access PC? Is PC the came things as IP register?


--
edfed
edfed wrote:
if one day i finally code something like an os, the model would be flat 32 bits model for everything.
with up to 4g of ram for application, starting at linear 0 (physical [page 0]).

...

think light, and stop to follow windows please, ok, the world is in a strange period, google, facebook, microsoft, etc... but please, stop following the tendency, lets remember the feeling of playing poor games, or displaying poor images on poor resolution monitors.

remember the feeling of a world in a time when high technology was that:

I'd like to see an OS from you though--sounds interesting.

True. I remember when a car on Gran Turismo was about 30 pixels (or something like that). True. I like old fashion DOS games. Why? Because I know there is a possibility that I might be able to implement one. I might stick with DOS MZ.


--
DOS386
DOS386 wrote:
Again, code DOS-style for DOS or Win7-style for Win7.
Well said. It's not like common end-user will download my library to run it. It will be made for one purpose.

DOS386 wrote:
What is the lib supposed to do ?
This is the important question that DOS386 asked. What is the library suppose to do? Initially, the library use made for DOS .COM and .EXE files, to provide general functions that can be called to do a job, for example: a function to write to files; convert integers to a strings; do sorting; provide function for graphics; provide abstract data types (if possible (i am not sure)) ect. It will use the stack to store the parameters/arguments of the function and also use to for local variables. Therefore, no registers are used to pass variables. That's basically what the library is to do.

Why is this question so important? It knocked some sense into my head. If I were to use 32-bit then there would already have DLL which provide those functions and way better ones. So I guess I would have to stick with DOS MZ, not only because of that, but because I like it.

DOS386 wrote:
edfed wrote

> would like a 32 bits .com codetype.
> yes, i'd like it.

You still don't realize that DOS COM is just a DOS-only 16-bit-only format. There is no most universal COM format natively running everywhere, even on 68000 Smile
Can't one create their own format to run on an OS? Or is it that i3886 are compatible with DOS?


Last edited by adroit on 21 Sep 2011, 22:18; edited 1 time in total
Post 20 Sep 2011, 12:32
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1638
Location: Toronto, Canada
AsmGuru62 20 Sep 2011, 18:52
I was just recently working with Flat DB files - Win32 swallows the 90,000 record file in 500msec! DOS can't do that!
Post 20 Sep 2011, 18:52
View user's profile Send private message Send e-mail Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1903
DOS386 21 Sep 2011, 07:25
adroit wrote:
16-bit is simpler, and that's why I'd like to use it, but I think 32-bit MZ is more versatile (I think)


16-bit 8086 MZ:

* works on 8086
* works on 80386 & Co
* works on 64-bit CPU (in real mode)
* 64 KiB segment limit and cca 512 KiB total limit (but there is XMS)
* can NOT easily access VESA LFB
* does NOT work well in Winaube
* less bloat

32-bit DOS extended MZ:

* does NOT work on 8086
* works on 80386 & Co
* works on 64-bit CPU (start from real mode)
* NO 64 KiB segment limit and NO cca 512 KiB total limit
* can easily access VESA LFB
* does NOT work well in Winaube
* usually more bloat

Quote:
Can't one create their own format to run on an OS? Or is it that i3886 are compatible with DOS?


You can create anything. It just won't be 8086-only DOS-only 16-bit-only DOS COM.

_________________
Bug Nr.: 12345

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

Status: Closed: NOT a Bug
Post 21 Sep 2011, 07:25
View user's profile Send private message Reply with quote
adroit



Joined: 21 Feb 2010
Posts: 252
adroit 21 Sep 2011, 23:34
(Sorry about all the questions. I am just curious).

__
AsmGuru62
AsmGuru62 wrote:

I was just recently working with Flat DB files - Win32 swallows the 90,000 record file in 500msec! DOS can't do that!
That's fast! That will be my next aim: Win32. But for now, at my novice stage, DOS will do it, and plus it helps me to understand DOS formats for my imaginary operating system (lol) Smile

Is that a private project or one for public?

Quote:


__
DOS386

adroit wrote:
16-bit is simpler, and that's why I'd like to use it, but I think 32-bit MZ is more versatile (I think)



16-bit 8086 MZ:

* works on 8086
* works on 80386 & Co
* works on 64-bit CPU (in real mode)
* 64 KiB segment limit and cca 512 KiB total limit (but there is XMS)
* can NOT easily access VESA LFB
* does NOT work well in Winaube
* less bloat

32-bit DOS extended MZ:

* does NOT work on 8086
* works on 80386 & Co
* works on 64-bit CPU (start from real mode)
* NO 64 KiB segment limit and NO cca 512 KiB total limit
* can easily access VESA LFB
* does NOT work well in Winaube
* usually more bloat


adroit wrote:
Can't one create their own format to run on an OS? Or is it that i3886 are compatible with DOS?



You can create anything. It just won't be 8086-only DOS-only 16-bit-only DOS COM.
Thanks for the list of differences. These will help to make some crucial decisions.

You mention above that 32-bit DOS extented MZ doesn't work on 8086, that can't be a sacrifice that I would make (x86). Also it's not limited to just 64KB, and also it can access the VESA LFB. Does it mean that VESA can be implemented and ran on Windows? Because that would be interesting.

DOS386 wrote:

You can create anything. It just won't be 8086-only DOS-only 16-bit-only DOS COM.
Would it not be 8086-only? Those this mean that it can be ran a predecessor architecture (8085 maybe [probably extinct])?
Post 21 Sep 2011, 23:34
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1638
Location: Toronto, Canada
AsmGuru62 22 Sep 2011, 14:29
I was just playing with a Flat DB prototype I coded recently.
Just for fun to see how fast I can get. I used FILE_FLAG_NO_BUFFERING flag for CreateFile() and file (~12Mb) was loaded by sectors in .5 sec - thats cool!
Post 22 Sep 2011, 14:29
View user's profile Send private message Send e-mail Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u 22 Sep 2011, 16:29
DexOS kernel is a MZ exe and can use VESA LFB without a problem.
Post 22 Sep 2011, 16:29
View user's profile Send private message Reply with quote
adroit



Joined: 21 Feb 2010
Posts: 252
adroit 27 Sep 2011, 22:51
AsmGuru62
I am not so much of a a Win32 programmer, however, I suppose that FILE_FLAG_NO_BUFFERING flag allows you to write to the disk cache instead which allows a larger size. And yes it is very cool. I like the way you people "play", while I consider those things large large projects. I have ALOT to learn


Dex4u
Excellent! So things can be kept simple.

So thanks guys. I'll be back soon, because I am interested in learning more about MZ and PE. If you have any other info that you'd like to contribute, I'll be glad.
Post 27 Sep 2011, 22:51
View user's profile Send private message Reply with quote
freecrac



Joined: 19 Oct 2011
Posts: 117
Location: Germany Hamburg
freecrac 19 Oct 2011, 11:10
revolution wrote:
16-bit is so limiting.

64KB segments (ugh!). You can't store much data before having to select another segment.

Only a subset of registers can be used for addressing. No scaling for indexes.


32-bit is so liberating.

No segmentation (yay!). Unless you have some huge requirement for data then 4GB is usually plenty.

All registers can be used for addressing. Indexes can be scaled.

I see a little difference between the using of only 16 bit-registers and the 16 bit-mode with the RM and the PM.

So it is possible to use 32 bit-register + scaling with the 16 bit-mode(using a 386+) inside the 16 bit RM, the 16 bit PM and the 16 bit unrealmode/big real mode (thus allowing a linear access to 4 GiB of data-memory from real mode).
Because the difference between the 16 bit and the 32 bit mode(32 bit attribute ("D" bit) is set) is only how the cpu interpret opcodes with or without an adresssize/operandsize/registersize prefix and not how many ram we can access with it.
How many ram we can access is specified inside the segment-entries of the GDT/LDT and the hidden cached descriptors and if the A20 line is enabled.

We can access the VESA LFB using 32 bit register within the 16 bit PM and the 16 bit unrealmode. To switch into a VESA mode we have to use the RM, the V86 mode or the unrealmode, because this part of the VESA Bios is not written for the PM. More information about the VESA-bios we can find in the cost free public document "vbe3.pdf" from vesa.org (need register and/or login).

Dirk
Post 19 Oct 2011, 11:10
View user's profile Send private message Send e-mail Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1638
Location: Toronto, Canada
AsmGuru62 19 Oct 2011, 14:06
I remember building quite large business applications in 1990s using MS-DOS.
And we did not even use this:

http://en.wikipedia.org/wiki/DOS_extender
Post 19 Oct 2011, 14:06
View user's profile Send private message Send e-mail 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-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.