Questions

[ghost]

Not much activity lately it seems. Maybe people got discouraged by the dependency on old tools. I think porting it to a modern environment is too much work, which will never happen. So people lose interest. That's not a problem for me, I boot real DOS, and have many old tools.

Borland C++ 3.1 is available at WinWorld: https://winworldpc.com/product/borland-c/30

But why is it needed? When I tried makemos.bat, it did not work. So I renamed BIN to to BINMOS, and used only that in my PATH. Then it did something, though I'm not sure what yet, so I looked in BINMOS and I see a make.exe which reports as ndmake 4.51. What? That's some obscure stuff, it took a while to find on google. And in BINMOS I see cl.exe which claims to be Microsoft C 5.1. And in LIBS, those look like Microsoft C libraries, not Borland.

Huh? What's up with that?

DOS muiltitasking is interesting to me, but it will take years to dissect this project and understand it. Any answers from old timers, are appreciated. I was around back in the day, but I was busy with other things.

[stsp]

There is a build.sh script in SOURCES/src that builds it for you. All build tools are already in "BIN", you don't need BC or any internet search. If it is still too difficult to build, there are another DOSes around, those that are built with gcc, clang etc.

[the-grue]

The Borland toolchain only appears to be required to build some of the stuff outside of the main kernel and tools. I believe, from looking at the code and addressing some Borland related issues, it is used to compile ulib.lib, export.exe, import.exe, hdsetup.exe, and install.exe.

For the record, makemos.bat DOES NOT build everything. It does selective builds, ignoring ulib, cutils, export, import, sn, unterm, vgna, and vna let alone the other source directories (jim/mossrc1/mossrc2). I am working to resolve this as time permits (read when I get tired of trying to track down the 2012 bug).

I have also noticed that the kernel and mos5src build makefiles expect ndmake as the make instead of Borland make, so having BIN in the path prior to the Borland stuff makes sense unless you want to use the fully qualified path every time you call make.

Glad to hear you are using real DOS as a build platform. I have been using a combination of DosBox on Linux, MOS and MSDOS on VirtualBox, MOS and MSDOS on a laptop/desktop, and Windows 98 on a laptop. I am not very familiar with how to configure MOS, so I have had many issues with it I am hoping to get around when/if someone can come up with some documentation scans. For example, running the Borland toolchain hangs a lot, but according to posts elsewhere it is possible to build all the code from MOS itself. I am probably just missing some configuration incantation...

As far as discouragement, I believe the 8/1/2012 bug is probably keeping most people away. Rooting that out is turning into a huge undertaking. I believe once we have a way past that, we can start working towards a project folks will want to contribute time/effort to. I have seen this before on the Minix project, when you hit a particularly hard bug, you lose a lot of interest until it gets fixed.

I actually like using the old tools alongside the new tools. DosBox is great for this, as you can edit files in Linux (or whatever) and have many windows open at the same time working on stuff and then kick off a build from within DosBox and see what happens, then back to your main OS for more coding.

[the-grue]

Oh, and there is a Turbo Pascal 7.0 requirement to rebuild help.exe. Of course, it is way at the bottom of makeutil.mak and isn't included in the build currently.

The Microsoft C compiler is used through the build process in various places, fortunately its requisite files seem to be intact in the /bin, /include, and /lib directories.

[ghost]

There is a build.sh script in SOURCES/src that builds it for you.

I'm not using DOSEMU.

All build tools are already in "BIN", you don't need BC or any internet search. If it is still too difficult to build, there are another DOSes around, those that are built with gcc, clang etc.

So you would rather send me away, than bother with the question. I get it.

[stsp]

There are other answers in this thread, choose whatever you like. There are other DOSes around, chose whatever you like. One of your questions was why makemos.bat doesn't work, and the script I pointed to, is one of many possibilities to use makemos.bat, and a simplest one. Choose whatever you like.

[ghost]

The Borland toolchain only appears to be required to build some of the stuff outside of the main kernel and tools. I believe, from looking at the code and addressing some Borland related issues, it is used to compile ulib.lib, export.exe, import.exe, hdsetup.exe, and install.exe.

OK. Then the makemos.bat file is misleading with BORLANDC at the front of the path. It overrides the make.exe in BIN, which is a different, NDMAKE as you said. And DOS5.0 seems to have no use unless you use real DOS 5.0, with its directory named the same.

For the record, makemos.bat DOES NOT build everything. It does selective builds, ignoring ulib, cutils, export, import, sn, unterm, vgna, and vna let alone the other source directories (jim/mossrc1/mossrc2). I am working to resolve this as time permits (read when I get tired of trying to track down the 2012 bug).

I have also noticed that the kernel and mos5src build makefiles expect ndmake as the make instead of Borland make, so having BIN in the path prior to the Borland stuff makes sense unless you want to use the fully qualified path every time you call make.

Glad to hear you are using real DOS as a build platform. I have been using a combination of DosBox on Linux, MOS and MSDOS on VirtualBox, MOS and MSDOS on a laptop/desktop, and Windows 98 on a laptop. I am not very familiar with how to configure MOS, so I have had many issues with it I am hoping to get around when/if someone can come up with some documentation scans. For example, running the Borland toolchain hangs a lot, but according to posts elsewhere it is possible to build all the code from MOS itself. I am probably just missing some configuration incantation...

My computers are old, but I have more than one, so it's easy to switch between them when real DOS is required.

As far as discouragement, I believe the 8/1/2012 bug is probably keeping most people away. Rooting that out is turning into a huge undertaking. I believe once we have a way past that, we can start working towards a project folks will want to contribute time/effort to. I have seen this before on the Minix project, when you hit a particularly hard bug, you lose a lot of interest until it gets fixed.

It's not obvious from the source, huh. Bummer.

Thanks for some answers. I don't need this project for commercial purposes, it's educational. I may have more questions. People bothered by them, please ignore, and keep the attitude to yourself.

[ghost]

There are other DOSes around, chose whatever you like.

I did not ask how to choose a DOS. Why answer a question not asked.

One of your questions was why makemos.bat doesn't work, and the script I pointed to, is one of many possibilities to use makemos.bat, and a simplest one.

build.sh runs MAKEMOS.BAT, which has the problem of overriding ndmake in BIN, with Borland make. Am I wrong?

[andrewbird]

It's not obvious from the source, huh. Bummer.

There are lots of non-obvious things in the tree, for example duplicate files and directories(three or four copies of some), MS compiler bits and pieces spread around /BIN /INCLUDE etc. I have local branches where I've tried to clean things up 3 times and failed them all.

build.sh runs MAKEMOS.BAT, which has the problem of overriding ndmake in BIN, with Borland make. Am I wrong?

I think you are correct, but if the Borland stuff isn't installed it won't matter.

[ghost]

build.sh runs MAKEMOS.BAT, which has the problem of overriding ndmake in BIN, with Borland make. Am I wrong?

I think you are correct, but if the Borland stuff isn't installed it won't matter.

Must be why it works for Stas and not me.

[stsp]

build.sh runs MAKEMOS.BAT, which has the problem of overriding ndmake in BIN, with Borland make. Am I wrong?

I think MAKEMOS.BAT is made with an assumption that MOS is on C:. It adds C:\BIN and C:\BORLANDC into PATH, and both dirs are in MOS source tree. In this case C:\BORLANDC doesn't override anything, because in MOS tree it doesn't contain anything. But build.sh doesn't take this into account, it does things differently: dosemu -td -E MAKEMOS.BAT -U 2 'path=%D\bin;%O' What it does is to prepend MOS's BIN dir into the PATH, in which case it takes a priority.

Must be why it works for Stas and not me.

Sorry, you haven't tried. Why to assert something you haven't tried.

[ghost]

Sorry, you haven't tried. Why to assert something you haven't tried.

As I said, I don't use DOSEMU. And I will not install it, to have the same environment as you.

Before running MAKEMOS.BAT, I altered it to use my Borland directory, which has a different name than the default. So in my case, Borland make failed. How would I know that the empty Borland directory in the MOS tree makes it work for you, until you explained it?

THANKS FOR YOUR ANSWER! STAS!

[stsp]

How would I know that the empty Borland directory in the MOS tree makes it work for you, until you explained it?

That was not an explanation, just an assumption at how could this work for MAKEMOS.BAT writers. The explanation was about build.sh, and unfortunately a wrong one... I indeed have not considered the case you specified, so while build.sh is preparing the PATH correctly, MAKEMOS.BAT does this:

path=c:\dos5.0;c:\borlandc;c:\lib;c:\bin;%PATH%

So the path prepared by build.sh gets appended to the end. :( I'll prepare the fix that makes the PATH prepended, and removes BORLANDC from it.

[stsp]

I added the PR to fix both problems. Please see if it is what you are looking for.

[ghost]

I added the PR to fix both problems. Please see if it is what you are looking for.

OK, but why have

c:\dos5.0 c:\lib

in the PATH, I don't see them in the root of MOS project or src tree. I like to remove extra junk whenever possible. If not possible, please explain.

[stsp]

I think (but not quite sure) that these 2 point to the pre-built components of MOS. The problem was that initially the PATH was completely overwritten. I added %PATH% part to it for build.sh, but it wasn't there before. This is why they needed to set path to pre-built MOS. But when the old path is preserved, this is indeed no longer needed. Will update.

[stsp]

New patch is uploaded.

[ghost]

New patch is uploaded.

I don't use DOSEMU, so build.sh does not affect me, but it looks like 'path=%D\bin;%O' will duplicate C:\BIN in the path when MAKEMOS.BAT is called. Or is that another BIN, unrelated to MOS?

[stsp]

This script maps MOS to another drive, so this path will not start from C, but usually from G. This is why I was under the impression the previous PATH is irrelevant. If not for the fact that I was appending my path to the end.

[ghost]

I trimmed MAKEMOS.BAT down to just the kernel, and got that to build. I see a lot of ASM code to study. I'm not sure what the next step should be. Without manuals to explain capabilities and usage, it seems intimidating. Is there a mailing list or newsgroup for general discussion and questions?

[stsp]

See #27

[the-grue]

Hi @src153! Is your ask specific to MOS or Assembly Language/MASM in general? As @stsp mentioned, #27 is where we are trying to track down documentation specific to MOS. You can find MASM/Assembly Language specific documentation on the Internet Archive. Just search for MASM or Microsoft Macro Assembler and you should find lots of resources.

A good document is Tischer's System Programming or PC Intern, which you should be able to find in PDF format on the internet or in hardcopy from the usual used book resellers. Systems Programming is up through DOS 4 and PC Intern, which is basically the same book, starts with DOS 5 and onwards.

There is a TON of assembly language code in the kernel as well as drivers and utilities. Hence the difficulty in tracking down the 2012 bug.

[ghost]

I have Tischer's book, and many others, more than I will ever have time to read. The truth of any project is in the source code, and given 100 years, I could probably understand PC-MOS. But time is short, Christ is coming, and PC-MOS manuals would speed things up.

As for the Ebay V4 manuals, something is better than nothing, but I don't have $49 to throw at it. If you do, more power to you.

[stsp]

It is very unlikely that PC-MOS manuals will speed up the assembly studying, if this is what your goal is. In fact it would be good if someone just sets up a wiki with a good description of this project, how its different from other DOSes, what features does it offer and what limitations, why and who should take the time to look into it, what compatibility level is there for 16bit and 32bit DOS progs, can it run win3.1, what NICs are supported, etc etc. What is the point of manuals, what will they give? Will they provide an answers to these questions? I think not, but I may be wrong.

[the-grue]

While I agree that the manuals may not help speed up assembly studying, they should provide information relative to APIs/Functions that may be present in MOS but not in other DOS.

Without someone with deep knowledge in the product or a really good memory from when it was mainstream, it will be difficult for folks to answer the questions you outline without manuals or at least some form of documentation.

How can you say whether or not it runs Windows 3.1? Or if it supports NICs? What APIs are available and if they went off standard anywhere. Do you know the exact lines of code to put in config.sys and autoexec.bat to allow for use of memory above 1M by a single user program? If so, please share it, but I bet it is clearly defined in the documentation! The idea of a Wiki is good, but where will the answers to the questions you pose come from? Since day 1, this project has had only 4 contributors. I believe that if we can give folks something more to read than the source code, they may be willing to get in and play around with it more than "let's see if I can get it to boot and write a blog about it".

From the bits I have found online, The Software Link had a lot of documentation for users, programmers, and field technicians. I think it is worthwhile to try to track this information down and share it along with the source code.

Call me old-school, but I feel this is a worthy quest and will improve the chances of success for the project.

[ghost]

I don't have money to spend on manuals, but if someone else does, why discourage them. When I say "more power to you" I mean the traditional sense of encouragement, not the ridiculous urban dictionary sarcastic definition.

If you want to set up a wiki, go for it.

If you are smarter and faster than me to read and understand ASM, go for it. When I meet someone smarter and faster than me, I get out of their way, and let them work.

I'm not a scientist, but I love scientists. They are the intellectual laborers of the world.

[stsp]

While I agree that the manuals may not help speed up assembly studying, they should provide information relative to APIs/Functions that may be present in MOS but not in other DOS.

IMHO this is of a very small interest, as I don't suppose someone will write new progs for MOS these days. From my POV people can only be interested by the ability of running old progs, and if MOS has a multitasker - then run old progs in parallel. :)

The idea of a Wiki is good, but where will the answers to the questions you pose come from?

These questions are quite simple, and my assumption is that documentation won't address them. Of course it will tell you how to write an optimal config.sys with a lot of mem, but it won't tell you how many DOS games can you run. Documentation can help you to make a "production" setup or a developer setup to use MOS API, but I just don't think this is what is needed now.

Call me old-school, but I feel this is a worthy quest and will improve the chances of success for the project.

The most important thing is that the goals of this project are not written. You can't have any success without knowing the goals. I don't mean the goals of MOS itself, but rather the goals of this particular project. What do you want at the end? Some DOS with manuals about "production" setup? Some DOS for running old games? Some DOS for people to study asm? IMHO this is a bit more important than the docs which may end up being irrelevant.

I don't have money to spend on manuals, but if someone else does, why discourage them.

Not to discourage, just trying to understand the point. To me this project does not yet have defined its set of goals, and as such, I see no use (yet!) in the paid manuals. If it is only for those people who used it in the past, then its another story, but to attract new people the goals (and then also features specific to these goals) needs to be defined. I myself was in search of a new DOS when this project appeared. W/o the defined set of goals, I only contributed a few patches and stopped, as I don't know where this all will go next. I knew what DOS I was looking for, but didn't know if the goals of this project do match what I need. Manuals, be they ready in time, would give me zero clue anyway. Only current project owners know where they want to drive this project.

[ghost]

My initial questions are answered, so I can close this soon.

I would like to have a place for discussion and general questions. I favor newsgroups over mailing lists, I still use USENET with a free account at Eternal September. I don't suppose there is an active group for PC-MOS? If not, maybe someone could inquire about creating one.

[stsp]

I am not from MOS project owners, but IMHO github is fine for discussions, why to have something else?

[ghost]

Stas, I don't favor written goals, a project can mean different things to different people. I just want to play and learn. Maybe someone else has legacy clients and wants it for commercial purposes. Why discourage anyone by narrowing the goals in writing?

As for discussion, github issues seems like the place for bugs, not chatter. USENET is better suited to chatter.

[the-grue]

Maybe Roeland would champion a Google Group or similar?

I agree the issues section of Github isn't the place for debates/discussions unless they are kept on-topic and related to an actual issue.

[ghost]

I myself was in search of a new DOS when this project appeared. W/o the defined set of goals, I only contributed a few patches and stopped, as I don't know where this all will go next. I knew what DOS I was looking for, but didn't know if the goals of this project do match what I need.

What do you need? May as well tell us, since you brought it up.

Only current project owners know where they want to drive this project.

Maybe they are like me, and don't have a goal. Maybe they just want to see what happens. If it does not meet your needs, you can always fork it, and then define your own goals for your own project. Why limit the owner's project with your narrow goals?

[ghost]

Maybe Roeland would champion a Google Group or similar?

Please not a google group. Google mirrors real newsgroups, so google users can get them, but let's go directly to the source, USENET. Free servers like Eternal September do a better job of filtering SPAM.

[ghost]

I feel this is a worthy quest and will improve the chances of success for the project.

Just publishing the source code was a success. Now I have a .ZIP file of it, and you can't have it back! HAHAHA

[the-grue]

Just a bunch of bits. It was out of date/out of sync the second you zipped it up as long as others are still working on it. :)

[ghost]

I believe that if we can give folks something more to read than the source code, they may be willing to get in and play around with it more than "let's see if I can get it to boot and write a blog about it".

The more information the better. People can read what they please.

Just a bunch of bits. It was out of date/out of sync the second you zipped it up as long as others are still working on it. :)

Yeah but I got the good stuff before they mess it up, heh.

[sub205]

I believe that if we can give folks something more to read than the source code, they may be willing to get in and play around with it more than "let's see if I can get it to boot and write a blog about it".

You are damn right. I'm following this project from the beginning. Despite being unable to compile it with the tools (ok, didn't check the last weeks, will do after this discussion!) some manual would be rather helpful. Ok, nice, there is an OS that pretends to be multi tasking, has this and that feature, this is multiple times more complicated to get into when virtually nobody has any knowledge about it.

We all know DOS and the classic derivates, can work with DOSBOX, PC-DOS, DR-DOS etc. because all are similar and have kind of the same functions and design. But with PC-MOS there has to be many additional stuff, commands, configuration options etc for the enhanced features it offers.

Maybe we can even do some tutorials (wiki-style and youtube), a list what runs, what runs not, some tipps & tricks etc.

You can try & find out, but many times you misunderstand some fundamental concepts of a software, when no one is there to tell you some basics. Then it takes much more effort to get the wrong "ways of doing something" out of your head and think new.

Also, some cheat sheets come in handy. Hotkeys, Commands etc.

[ghost]

In my USENET newsgroup list there is no pc-mos. Creating one in the alt. heirarchy should be doable, I suggest alt.comp.os.pc-mos.

USENET news clients are speedy. They offer quick reading, quoting, and replying. It's old school, some young folk don't even know what it is. But once you learn it, there's nothing better for conversation, IMO.

So if there is a will, I think we can find a way.

[ghost]

I looked at the Ebay PC-MOS sale. The disks say 4.1 PL5. Featurewise, that's probably close to 5.x. It won't hurt to know version history, sometimes old ones are less buggy. If I had the extra cash, I would buy it.

[ghost]

IMO, #13 "Port build to newer tools" is no help in understanding the code base, it would only add confusion on top of ignorance. Personally I am not distressed by using legacy non-free tools, but if you are, waiting until the code base is well dissected and understood before any attempt is made to port the code, will save you much grief.

[ghost]

If you want to Go Fund Me for the Ebay sale, I will pledge $5. If a few more people chip in, that would help cover the cost of 4.x manuals.

[the-grue]

I bought the software/manual. Should be here next week. e-bay offered $5 off, so how could I resist?!?! Seriously, I was worried it would disappear...

[ghost]

You should worry. I was searching around for an extra $50. But I would not steal it out from under you. I don't have a scanner, and I don't live in a city where I could pay someone else to scan it. If I had bought it, I would have to type the important parts into a Wiki.

[ghost]

If I had to formulate project goals, as Stas suggests, mine would be:

a) fix bugs and deliver the same user experience as the original commercial product b) keep the legacy build chain, don't port to GPL tools (IOW, leave well enough alone) c) the code is free, we know that, don't clutter it up with annoying GPL notices d) dissect and analyze the code base to understand and document it e) improve kernel speed, make it smaller, and minimize use of DOS conventional memory f) study other multitasking DOS projects for ideas to improve PC-MOS architecture (Ctask for instance)

Items e) and beyond may exceed the reach of current human lifespan, but why not dream

my 2 cents

[the-grue]

I'm kind of focusing on a, b, and d at the moment.