OSDev.org

Schol-R-LEA wrote:Just out of curiosity, were you familiar with FreeDOS prior to this, and did you look into it at all?

I already use Freedos to run EMX 0.9d to build PDOS/386. It's only recently that I got a cross-compiler from Windows to work.

Also, as I mentioned, an Exokernel would in some ways be even simpler - it wouldn't have an OS interface at all, so the applications and shared libraries would have free run over the system. Is this closer to what you actually want, or was their some specific aspect of MS-DOS you were seeking to revive?

No, I want to start from a "known point" - what is the simplest way to port a 16-bit MSDOS program, that is allowed to use the full MSDOS API, to a 32-bit environment.

You are not alone in this group in having an interest in MS-DOS or DOS-like systems, and while I am not one of those looking for that myself, you might want to get in touch with some of those who are already here. The wiki even has a developer archetype for such developers, Lino Commando, and while the archetypes are meant in jest (for example, the one that fits me closest is Alta Lang, which I wrote myself but which several others here fit), it does show how often this idea comes up. A few I can mention include ~ (yes, his username is just a tilde, I don't know why), utkarsh, and bellezasolo.

Ok, I was hoping someone would answer my actual question on this thread. I do not have the skills to do the design properly, so instead the API needs to remain temporary while software is ported.

I had sent this to the OP by PM earlier, but they don't seem to have read it, so I might as well ask here. I wanted to avoid cluttering the thread, but in retrospect it would probably have been to ask this in public in the first place. I've deleted the PM, since it would be pointless for them to get it now.

Sorry, I didn't notice that.

Hi,

kerravon wrote:No, I want to start from a "known point" - what is the simplest way to port a 16-bit MSDOS program, that is allowed to use the full MSDOS API, to a 32-bit environment.

For porting software the API isn't important - e.g. you could do a very simple "search and replace" to change every "int 0x21" into a "call myLibrary", then have a shared library running on Linux (or DLL running on Windows or ...) that emulates the API.

The real problem is memory management, where the code will be riddled with segment register loads and assumptions about 64 KiB segment limits. The real problem is devices, where the code will assume a sound card is Creative Labs Sound Blaster and start banging away at IO ports that haven't existed for decades. The real problem is that programs will replace/hook IVT entries for many reasons and use "real mode only code" to extend or replace BIOS and/or DOS functionality.

The real problem is that even if the API is 100% identical, you're still going to have to rewrite half of the application while porting it to anything that isn't using real mode. Of course if you are rewriting half the program to fix all of the problems that prevent it from working on a "32-bit DOS", then it'd take almost no extra effort to port it to any other OS (e.g. Linux), because all of the actual portability problems have nothing to do with the API.

Sure, there's probably a few programs that were designed for some other OS (e.g. Unix) and ported to DOS that would be a lot easier to port to "32-bit DOS" because they don't do most of these things (because they were never designed for DOS in the first place). They don't count because they're not true "specifically designed for DOS" programs and could just as easily be ported to any other OS.

kerravon wrote:I do not have the skills to do the design properly, so instead the API needs to remain temporary while software is ported.

This is the reason why I'm so critical of "let's regurgitate a piece of trash" nonsense. It's always people who are trying their hardest to avoid learning skills.

If you don't have the skills to design properly, then you're normal - nobody has any skills until they start learning them. The question is, why aren't you trying to learn these skills? Do you want to be a person that lacks skills forever because you spent years writing a 32-bit DOS instead of learning; or are you planning to starting learning skills after you've wasted years for no reason?


Cheers,

Brendan

Brendan wrote:The real problem is that even if the API is 100% identical, you're still going to have to rewrite half of the application while porting it to anything that isn't using real mode.

My experience in porting micro-emacs, which does DOS calls for the MSDOS version, is that not much needed to be changed to start working on my 32-bit DOS.

If you don't have the skills to design properly, then you're normal - nobody has any skills until they start learning them. The question is, why aren't you trying to learn these skills? Do you want to be a person that lacks skills forever because you spent years writing a 32-bit DOS instead of learning; or are you planning to starting learning skills after you've wasted years for no reason?

Most of my time (decades) has been spent trying to understand the difference between MVS mainframes and PCs. I'm now happy with the status of my mainframe knowledge so I am venturing into PCs now. Now that my mainframe environment works as well as the PC, I want PDOS/386 to work as well as PDOS/3x0. That is why I eventually went with a PosAllocMem that has a LOC20 parameter, inspired by the mainframe. I'm just uncertain as to whether this mainframe-inspired call is the best possible design for what I am trying to achieve.

kerravon wrote:Most of my time (decades) has been spent trying to understand the difference between MVS mainframes and PCs. I'm now happy with the status of my mainframe knowledge so I am venturing into PCs now.

This statement raises more questions than it answers, as (to the best of my knowledge) MVS as a stand-alone OS was phased out by IBM in the late 1970s. While it remained supported for decades later (running virtualized under VM/370 and its successors), I know of no installations which were using it as a non-virtualized OS even at the time the original PC was released (you have to remember, in those old mainframe shops, it was IBM who usually had the last say on such things, not the customer, who often had no idea what the IBM-trained system admins were up to - if Big Blue said to go with a hypervisor, they did). I can only assume I am mistaken about that, but... seriously?

What is more, the wording implies that you were studying MVS systems, and doing so recently at that, rather than using them professionally, which is the only reason I can imagine anyone would want to learn about them. Have I misread this, and if not, what could possibly compel you to do something so daft?

MVS is a now fifty year old system which was notorious for its terrible engineering even in its day (like Windows XP, it was eventually patched into a semblance of stability which made it successors look worse to people who never saw how bad it was originally; though it was a lot longer process than it was for XP, which resulted in a system that was not so much a fixed version of MVS as it was a completely new OS built from patches, which emulated the original OS 's behavior and API). I can't imagine anyone seeing it - or indeed any of the OSes from that era (I'm looking at you, Mr Torvalds) - as a meaningful guide to how an OS should be designed.

Curiosity is something I can respect, but this seems about as useful vis a vis the general world of programming as learning how to write LGP-30 machine code because you liked the Story of Mel. (actually, the last example at least sounds interesting as a bit of odd, pointless, ars gratia artis retrocomputing, which neither MVS nor MS-DOS are to me). What am I missing here?

Also, I need to mention that even the 'huge' PC library was small compared to what came out of Windows, especially in terms of games. This is something Tilde keeps missing - that their nostalgia was clouding their recollection of just how small the library actually was, and how bad almost all the programs really were.

But it sounds as if you were there, too, unlike Tilde (who I am pretty sure is a bit too young to have actually used DOS in its heyday). This lack of historical perspective from someone who lived through that period is puzzling to me.

As someone who worked tech in those days, I can also tell you that most people never really used DOS itself if they could avoid it - most people got someone to put an autoexec.bat file on their floppies to start running Lotus 1-2-3 or WordPerfect or some such right away, because MS-DOS was an alien landscape to them. Startup menu programs (which were generally just the same sort of batch file) were almost universal for those who had hard drives. Even when MS-DOS was the dominant OS, most people who had PC didn't use it directly if they could help it.

Given this, using DOSBox or the equivalent is likely to be more productive and more authentic, even if you hate Windows and Linux (at least with Linux, you could run it from a shell-only system).

Hi,

kerravon wrote:

Brendan wrote:The real problem is that even if the API is 100% identical, you're still going to have to rewrite half of the application while porting it to anything that isn't using real mode.

My experience in porting micro-emacs, which does DOS calls for the MSDOS version, is that not much needed to be changed to start working on my 32-bit DOS.

Yes. Micro-emacs was originally written on Unix but was deliberately designed to be as portable as possible, and was ported to a large number of operating systems including MS-DOS. It's nothing like a typical MS-DOS application that was designed specifically for MS-DOS and has never been ported to anything else.

Basically; your experience in porting micro-emacs gives you unrealistic expectations.

kerravon wrote:

If you don't have the skills to design properly, then you're normal - nobody has any skills until they start learning them. The question is, why aren't you trying to learn these skills? Do you want to be a person that lacks skills forever because you spent years writing a 32-bit DOS instead of learning; or are you planning to starting learning skills after you've wasted years for no reason?

Most of my time (decades) has been spent trying to understand the difference between MVS mainframes and PCs. I'm now happy with the status of my mainframe knowledge so I am venturing into PCs now. Now that my mainframe environment works as well as the PC, I want PDOS/386 to work as well as PDOS/3x0. That is why I eventually went with a PosAllocMem that has a LOC20 parameter, inspired by the mainframe. I'm just uncertain as to whether this mainframe-inspired call is the best possible design for what I am trying to achieve.

Oh my. I found your project, downloaded the project's "zip" file, and...

An entire "OS" in a single source file that's several thousand lines long, being used to reduce one of the most historically significant forefathers of modern virtual memory management and multi-programming into crippled joke.

You need to be ashamed. Hitler is no longer the worst person in history.


Cheers,

Brendan

Schol-R-LEA wrote:

kerravon wrote:Most of my time (decades) has been spent trying to understand the difference between MVS mainframes and PCs. I'm now happy with the status of my mainframe knowledge so I am venturing into PCs now.

This statement raises more questions than it answers, as (to the best of my knowledge) MVS as a stand-alone OS was phased out by IBM in the late 1970s.

MVS has been renamed z/OS and it is still current and important. The inability for 32-bit registers to address 4 GiB of memory is a problem that still exists, but I now have a solution to that I am personally happy with.

What is more, the wording implies that you were studying MVS systems, and doing so recently at that, rather than using them professionally, which is the only reason I can imagine anyone would want to learn about them. Have I misread this, and if not, what could possibly compel you to do something so daft?

I wish to write C90-compliant programs that work on the major platforms, and MVS was always an exception and I wanted to understand and possibly rectify this, and I have now done both.

These were fifty year old systems which were notorious for their terrible engineering even in their day

I don't know where you got that from. MVS is a brilliant platform. Infinitely debuggable. Vendors don't just say "can't reproduce it in dev, so can't fix it".

kerravon wrote:

Schol-R-LEA wrote: These were fifty year old systems which were notorious for their terrible engineering even in their day

I don't know where you got that from. MVS is a brilliant platform. Infinitely debuggable. Vendors don't just say "can't reproduce it in dev, so can't fix it".

You're speaking as someone who had learned the system after fifty years of patches and replacements. The MVS of today - or even of 1980 - was a very different system from that of 1969 (which IIRC was when it was introduced). I have read enough about the early days of that system to get a feel for how bad it had been for the first decade of its existence.

I should also point out that it was a derivative of OS/360, remember, and Fred Brooks (the lead designer) wrote a very famous book about how disastrously the project went and how flawed that family of operating systems were initially. You might have heard of it...

More to the point, you're statement is about how IBM and their affiliates treat customer problems is not actually reflective of the operating system, just of their rock-solid tech support compared to the Deadwood recklessness of most PC software companies (including Microsoft). However, the Wild West era of PCs came about largely because of MS-DOS fostering it - IBM had no hand in how it was supported. Also, what you describe only applies to supported products - and there were never many unsupported mainframe programs, as even the programs distributed through SHARE had to be approved by IBM as meeting a standard of acceptable quality.

BTW, I added quite a bit to my earlier post - I have a bad habit of editing posts after submitting them, sorry about that - so you might want to revisit that post, assuming Brendan's ad hominem attempts at shaming haven't driven you away.

Brendan wrote:Hi,

kerravon wrote:

Brendan wrote:The real problem is that even if the API is 100% identical, you're still going to have to rewrite half of the application while porting it to anything that isn't using real mode.

My experience in porting micro-emacs, which does DOS calls for the MSDOS version, is that not much needed to be changed to start working on my 32-bit DOS.

Yes. Micro-emacs was originally written on Unix but was deliberately designed to be as portable as possible, and was ported to a large number of operating systems including MS-DOS. It's nothing like a typical MS-DOS application that was designed specifically for MS-DOS and has never been ported to anything else.

Basically; your experience in porting micro-emacs gives you unrealistic expectations.

I do not mind if it is only programs that have been written with care, like micro-emacs, that can be ported from 16-bit DOS to 32-bit DOS. Part of what I am trying to do is post-facto issuing programming guidelines to DOS programmers so that their applications, like micro-emacs, can one day be ported to 32-bit DOS. One of the things I am trying to do is understand computers well enough that if I ever have to start from scratch after a nuclear holocaust, I can give the survivors a good guide on how to get computers up and running. I would assume that segmented memory is a step that would be bypassed this time round.

An entire "OS" in a single source file that's several thousand lines long, being used to reduce one of the most historically significant forefathers of modern virtual memory management and multi-programming into crippled joke.

I'm not sure if you're talking about the S/370 version or the 80386 version, but regardless, I need to start somewhere, and with something that is within my limited capabilities. That's just what I came up with. And writing those operating systems enabled me to refine the C runtime library for MVS. I can produce a single MVS load module that works optimally on 24-bit, 31-bit and 32-bit. Previously I had separate 24-bit and 31-bit versions of the module, and 32-bit didn't exist.

Schol-R-LEA wrote:

kerravon wrote:

Schol-R-LEA wrote: These were fifty year old systems which were notorious for their terrible engineering even in their day

I don't know where you got that from. MVS is a brilliant platform. Infinitely debuggable. Vendors don't just say "can't reproduce it in dev, so can't fix it".

You're speaking as someone who had learned the system after fifty years of patches and replacements. The MVS of today - or even of 1980 - was a very different system from that of 1969 (which IIRC was when it was introduced). I have read enough about the early days of that system to get a feel for how bad it had been for the first decade of its existence.

My focus has been on ensuring that my C90-compliant programs work as well as possible on z/OS, not arguing the toss about whether the system was pretty crap 50 years ago.

BTW, I added quite a bit to my earlier post - I have a bad habit of editing posts after submitting them, sorry about that - so you might want to revisit that post,

I reread it, and didn't miss anything. I just don't have any comments about other things you said.

assuming Brendan's ad hominem attempts at shaming haven't driven you away.

I'm inoffensible.

kerravon wrote:My experience in porting micro-emacs, which does DOS calls for the MSDOS version, is that not much needed to be changed to start working on my 32-bit DOS.

Brendan wrote:Yes. Micro-emacs was originally written on Unix but was deliberately designed to be as portable as possible, and was ported to a large number of operating systems including MS-DOS. It's nothing like a typical MS-DOS application that was designed specifically for MS-DOS and has never been ported to anything else.

Basically; your experience in porting micro-emacs gives you unrealistic expectations.

I do not mind if it is only programs that have been written with care, like micro-emacs, that can be ported from 16-bit DOS to 32-bit DOS.

You're missing Brendan's point. MicroEmacs wasn't an MS-DOS program. It may have been ported to it, but the 'care' you are touting was rooted in the fact that it wasn't designed for MS-DOS and thus couldn't rely on the MS-DOS API.

kerravon wrote:Part of what I am trying to do is post-facto issuing programming guidelines to DOS programmers so that their applications, like micro-emacs, can one day be ported to 32-bit DOS.

That shouldn't be a problem, as there are no MS-DOS programmers any more, except hobbyists such as yourself and Tilde - and from what we've seen of Tilde's code (and from Brendan's comments, yours), we can safely say that such coding standards aren't likely to be applied by those who do still write DOS programs.

kerravon wrote:One of the things I am trying to do is understand computers well enough that if I ever have to start from scratch after a nuclear holocaust, I can give the survivors a good guide on how to get computers up and running. I would assume that segmented memory is a step that would be bypassed this time round.

Has anyone ever explained the concept of an electromagnetic pulse to you? If such a war happens, there won't be any usable consumer electronics; they would all be fried. To run MS-DOS after a nuclear war, you'd have to first reinvent IC fabrication, and do so without even 1940s-era computing hardware to do the design work on. You would have to bootstrap several generations' worth of computer hardware design, while also trying to survive in the irradiated hell you are in.

kerravon wrote:

Brendan wrote: An entire "OS" in a single source file that's several thousand lines long, being used to reduce one of the most historically significant forefathers of modern virtual memory management and multi-programming into crippled joke.

I'm not sure if you're talking about the S/370 version or the 80386 version, but regardless, I need to start somewhere, and with something that is within my limited capabilities. That's just what I came up with. And writing those operating systems enabled me to refine the C runtime library for MVS. I can produce a single MVS load module that works optimally on 24-bit, 31-bit and 32-bit. Previously I had separate 24-bit and 31-bit versions of the module, and 32-bit didn't exist.

Brendan's point is that this is poor design, and unnecessarily poor design at that - from his description, you haven't done anything to separate the source code into modules, which is somewhere around 'write comments' and 'avoid one letter variable names' in the checklist of 'how to write maintainable programs'. This is the sort of thing that makes a program unreadable and unmaintainable, and I can assure you that the mainframe programs you praised earlier weren't written as a single big pile o' source in a single source file.

Linking of separate program modules is so fundamental that it was being used in the 1940s, at a time when hand-assembled machine code was the order of the day (indeed, my understanding is that the term 'compiler' originally referred to a type of linkage editor which would compile and collate a list of existing machine code modules to be included in the punch card deck to be run; the modern usage came because several early high-level languages such as Atlas Autocode were basically linker scripts for such a beast). Anyone who writes a C program longer than 300 or so lines of code without separating the code across multiple files is someone who doesn't know what they are doing.

Schol-R-LEA wrote: You're missing Brendan's point. MicroEmacs wasn't an MS-DOS program. It may have been ported to it, but the 'care' you are touting was rooted in the fact that it wasn't designed for MS-DOS and thus couldn't rely on the MS-DOS API.

The MSDOS version does rely on the MSDOS API. It also (one flavor anyway) relies on being able to directly manipulate screen memory at 0xb8000.

kerravon wrote:Part of what I am trying to do is post-facto issuing programming guidelines to DOS programmers so that their applications, like micro-emacs, can one day be ported to 32-bit DOS.

That shouldn't be a problem, as there are no MS-DOS programmers any more, except hobbyists such as yourself and Tilde - and from what we've seen of Tilde's code (and from Brendan's comments, yours), we can safely say that such coding standards aren't likely to be applied by those who do still write DOS programs.

I'm also not concerned if no-one follows my coding standards. I just want to be happy with them myself and follow them myself.

Has anyone ever explained the concept of an electromagnetic pulse to you? If such a war happens, there won't be any usable consumer electronics; they would all be fried. To run MS-DOS after a nuclear war, you'd have to first reinvent IC fabrication, and do so without even 1940s-era computing hardware to do the design work on. You would have to bootstrap several generations' worth of computer hardware design, while also trying to survive in the irradiated hell you are in.

Yes, I want to be able to write all that down on paper, from my head. As much as possible, anyway.

Brendan's point is that this is poor design, and unnecessarily poor design - from his description, you haven't done anything to separate the source code into modules, which is somewhere around 'write comments' and 'avoid one letter variable names' in the checklist of 'how to write maintainable programs'. This is the sort of thing that makes a program unreadable and unmaintainable,

It makes it conceptually simple, which is what I am going for at the moment. I am not trying to win Miss America with PDOS, but I'd like the 32-bit API to win Miss America, if Miss America was judged by someone familiar with and happy with the 16-bit API and doesn't want to see it changed unnecessarily. PDOS can be changed or rewritten at any time. The API will get stuck when too much software gets ported. So that is why my question is about the perfect 32-bit MSDOS API, not the perfect PDOS.

kerravon wrote:

Schol-R-LEA wrote: Brendan's point is that this is poor design, and unnecessarily poor design - from his description, you haven't done anything to separate the source code into modules, which is somewhere around 'write comments' and 'avoid one letter variable names' in the checklist of 'how to write maintainable programs'. This is the sort of thing that makes a program unreadable and unmaintainable,

It makes it conceptually simple, which is what I am going for at the moment.

facepalm No, it doesn't. It only looks like it does. Any experienced programmer could tell you that having a single source file is less understandable than breaking the source into multiple files. Even - or maybe especially - in the early stages of development.

Which makes me wonder about just how much programming you've actually done...

Schol-R-LEA wrote:

kerravon wrote:

Schol-R-LEA wrote: Brendan's point is that this is poor design, and unnecessarily poor design - from his description, you haven't done anything to separate the source code into modules, which is somewhere around 'write comments' and 'avoid one letter variable names' in the checklist of 'how to write maintainable programs'. This is the sort of thing that makes a program unreadable and unmaintainable,

It makes it conceptually simple, which is what I am going for at the moment.

facepalm No, it doesn't. It only looks like it does.

And that is exactly what I'm after at this stage!

Any experienced programmer could tell you that having a single source file is less understandable than breaking the source into multiple files. Even - or maybe especially - in the early stages of development.

I am not disagreeing with you that that's what should be done if you want a maintainable product for people to work on. But at the moment I am only wanting to get it to the point where I can get some concepts from it. The main concept I'm interested in at the moment is a 32-bit API. The number of source files in PDOS, or a clone of PDOS/Freedos32 etc, is not relevant to that question.

Which makes me wonder about just how much programming you've actually done...

Although I've worked as a software engineer for 30 years, I've normally been in roles such as support where I have to debug other people's code rather than write large quantities of code myself. I mentioned the 24/31/32 issue before. That's about 50 lines of code developed after the full 3 decades of trying to understand MVS concepts and why the 24/31/32 thing exists in the first place.

kerravon wrote:

Schol-R-LEA wrote:

kerravon wrote: Which makes me wonder about just how much programming you've actually done...

Although I've worked as a software engineer for 30 years, I've normally been in roles such as support where I have to debug other people's code rather than write large quantities of code myself. I mentioned the 24/31/32 issue before. That's about 50 lines of code developed after the full 3 decades of trying to understand MVS concepts and why the 24/31/32 thing exists in the first place.

OK, fair enough; I've been in the industry about the same amount of time, and have spent most of it on some of the most poorly considered projects imaginable (which is frustrating, but lucrative, sad to say). Most of that was in maintaining existing code, too, so I understand that part as well.