flat assembler
Message board for the users of flat assembler.
Index
> DOS > [ask] Death of 16-DOS MZ... and rise of PE? |
Author |
|
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? 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. |
|||
20 Sep 2011, 00:25 |
|
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. |
|||
20 Sep 2011, 02:16 |
|
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: http://www1.odn.ne.jp/~caa09810/old_pc/pc_tera.htm it isn't so far. |
|||
20 Sep 2011, 02:37 |
|
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 |
|||
20 Sep 2011, 02:55 |
|
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 ??? 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 Setup is extremely painful Code is heavily bloated 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 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 |
|||
20 Sep 2011, 06:13 |
|
revolution 20 Sep 2011, 07:01
DOS386 wrote: > IBM PC can be used for data addressing. 16 general purpose registers |
|||
20 Sep 2011, 07:01 |
|
adroit 20 Sep 2011, 12:32
Thanks guys for the replies
-- me239 me239 wrote: 1) I personally like 16 bit more because it's simpler (or at least seems that way to me) -- revolution revolution wrote: 16-bit is so limiting. 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. 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. DOS386 wrote: What is the lib supposed 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 Last edited by adroit on 21 Sep 2011, 22:18; edited 1 time in total |
|||
20 Sep 2011, 12:32 |
|
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!
|
|||
20 Sep 2011, 18:52 |
|
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 |
|||
21 Sep 2011, 07:25 |
|
adroit 21 Sep 2011, 23:34
(Sorry about all the questions. I am just curious).
__ AsmGuru62 AsmGuru62 wrote:
Is that a private project or one for public? Quote:
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:
|
|||
21 Sep 2011, 23:34 |
|
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! |
|||
22 Sep 2011, 14:29 |
|
Dex4u 22 Sep 2011, 16:29
DexOS kernel is a MZ exe and can use VESA LFB without a problem.
|
|||
22 Sep 2011, 16:29 |
|
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. |
|||
27 Sep 2011, 22:51 |
|
freecrac 19 Oct 2011, 11:10
revolution wrote: 16-bit is so limiting. 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 |
|||
19 Oct 2011, 11:10 |
|
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 |
|||
19 Oct 2011, 14:06 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.