New release

[andrewbird]

Hi all, Some things that spring to mind now there's a new release. 1/ I think the repo should be tagged (v5.02 would be my choice, but I'm sure there are others.) 2/ The readme.md needs updating 3/ I'm not sure how painful it would be to drop the v501 suffix from the repo name, but I'd like to see it gone. 4/ If people want to put their feature suggestions on the wiki wish list it probably needs to be writable.

[the-grue]

Hi @andrewbird! These are some good points. I don't have an answer for 1 as I am not familiar with tagging.

2 I'll leave for Roeland as that is the landing page/face for his repo. 3 can be done easily enough under the settings tab in the repository. Easy as that may be, I know I have put links to the repository around the web, so all of those would need to be updated plus most of the press articles about this being open-sourced include the URL to this repo. It might be better to archive this repo and then create a new one we can work off of or rename this one and create a new one with the current name with a pointer. (If that makes sense) 4 can be done, but it is either world writable or contributor writable. I often wish we didn't have to open an "issue" to have a discussion/debate on here.

[andrewbird]

3/ Regarding the rename, it seems all is not lost see https://github.blog/2013-05-16-repository-redirects-are-here/ . I just tried this and it works, my repo has been renamed for a while and I just accessed it by its old name and it works. See https://github.com/andrewbird/pcmos386v501/tree/travis-ci . 4/ Yes but I don't want to open a can of worms, apparently I can clone the wiki and submit a pull request if I wish to add anything.

[andrewbird]

Nope, although I can clone the wiki, there's nowhere for me to push to. It seems it's intended that collaborators would push back to the main wiki directly. Oh well.

So a few items you could add for me onto the Wish List, are

• [ ] Radical clean up of duplicate files
• [ ] Single directory for kernel, so no more mos5src, jim etc
• [ ] Removal of path entries, file specs and directories containing drive letters
• [ ] Replacement Make, I tried Gnu and whilst it works well, it's very slow in comparison
• [ ] Travis-ci integration for automatic build test on every push or PR, I have this working except that DOS build failures aren't being propagated at the moment. See https://travis-ci.com/andrewbird/pcmos386

[the-grue]

Thanks for the starter wish-list @andrewbird . I have added these to the wiki.

I did some re-ordering of stuff in my MOS86 repo with plans of trying to start porting stuff to more modern tools but got sidetracked on another project.

@galazwoj has done cleanup and a lot of changes in his repo as well here.

[andrewbird]

Yes your MOS86 repo looks like it does a lot of the source code cleanup i desire. I see you've stripped out the build tools from the source, of course that'll kill automated builds like travis-ci unless I can grab an unpacked copy of those from somewhere to load to the pristine VM each time a build is done.

How are you finding Borland's make tool in comparison to the current?

1. Does it allow a change to directory before starting a build? For instance the current does this;

   cd kernel
   make -f makefile.mak all
   cd ..

   whereas Gnu Make will allow

   gmake -C kernel -f makefile.mak all

   and at finish the current directory is restored, even on error

2. Proper handling of dollar sign $ in rules, allows to get rid of all the file renaming nonsense?

3. Macros for filename generation / modification?

[the-grue]

I just made a copy of the repo and started to clean up and structure things. I don't believe I have actually changed much, if anything. It was a starting point for some work I had planned to get to at some point. Now, if the project sees some momentum, I'll re-allocate some of my time to it. 🙂

[roelandjansen]

the make thing might be interesting. On the other hand -- we change single files it should not rebuild everything.

Also, what are the compile times we're speaking of? Last time I compiled it using the default tooling etc, was when a 386 was still a hot cpu.

[roelandjansen]

@galazwoj

could make a few PRs to sync the stuff; preventing double work.

I am open for most if not all suggestions. It's in git so every single state is still available. (And - I still have the tapes)

[andrewbird]

@roelandjansen I propose we use makefile to clean and build rather than batch files, I don't expect a single file change to cause a full rebuild. With the existing tools and on my fairly old machine (2.4 Ghz) the full kernel build takes 12 secs under dosemu+freedos and linux. I seem to remember that switching to GNU make would double that.

[andrewbird]

I also think the periscope debugging files can be dispensed with, or at least made optional.

[the-grue]

I also think the periscope debugging files can be dispensed with, or at least made optional.

This could certainly be a priority. I don't know of anyone that has a periscope kit.

I propose we use makefile to clean and build rather than batch files, I don't expect a single file change to cause a full rebuild.

I could get behind this as well. Does GNU make run under DOS/MOS?

[andrewbird]

gnu make runs under DOS but does require DPMI server, so that's either built-in like on Windows, dosemu, etc or the CWSDPMI TSR for those systems lacking it:

[stsp]

I seem to remember that switching to GNU make would double that.

Have you tried speed 0, changing CPU backends and all that? I do not suppose GNU make is slow but maybe dosemu is.

[andrewbird]

No I didn't try any of that, but two very similar builds produced these results Old make, dosemu2, freedos 1.20, 12 secs Gnu make, dosemu2, freedos 1.20, 24 secs That speed difference doesn't matter to me, but it may to others?

@the-grue which directory/script is your v5.02 using for kernel build? I'll switch my travis-ci test branch to use that, then convert it to gnu make and we can see for sure.

[stsp]

dosemu changes speed depending on the program it runs, unless you ask him to not do that. It could decide to run gnu make at a slow speed, so try speed 0.

[andrewbird]

Will try speed 0 tomorrow, but I have noticed that del of a single file is very slow. The old makefile wasn't doing the delete, so there's a difference to start with.

[the-grue]

@the-grue which directory/script is your v5.02 using for kernel build? I'll switch my travis-ci test branch to use that, then convert it to gnu make and we can see for sure.

I use MAKEALL.BAT which calls batch files and/or makefiles under the various directories. Main code for kernel, utilities, drivers is latest. It expects some parameters to build the Borland C stuff. I made it so it will build under MOS and I think DOS works as well but I haven't built the entire code base in awhile.

CLEANALL.BAT and CLEANDIS.BAT are like "make clean" and "make distclean" respectively. These could go away if we had a proper make process.

[the-grue]

gnu make runs under DOS but does require DPMI server, so that's either built-in like on Windows, dosemu, etc or the CWSDPMI TSR for those systems lacking it:

Has anyone put any time into looking at the unfinished DPMI code in the MOS repo?

[roelandjansen]

I also think the periscope debugging files can be dispensed with, or at least made optional.

we could move them to a different place; as long as the commit message is sane, we can find back where they went.

[roelandjansen]

gnu make runs under DOS but does require DPMI server, so that's either built-in like on Windows, dosemu, etc or the CWSDPMI TSR for those systems lacking it:

Has anyone put any time into looking at the unfinished DPMI code in the MOS repo?

I vaguely recall that Steve was working during that time; hence the different directories where different code may reside.

I once tried to read the 286/386 code and at the point where protected mode et al came by I stopped reading. Maybe some day...

[stsp]

What's the reason of having the built-in DPMI in mos? That would be emulator-unfriendly. Currently DPMI is provided either by the emulator itself (dosemu), or cwsdpmi can be loaded (qemu). Why changing that? Of course it will likely be optional so people can be able to still switch it off, but why to introduce something that everyone should turn off?

[roelandjansen]

without googling at all -- it woudl enable PC-MOS/386 allow programs to run that required DPMI and my guess is that vmware can handle that (e.g. run an enabled DPMI host).

My vm's all run under vmware, not quemu etc.

[HStewartGitHome]

I am curious about DPMI. Is something added or was it included in source. While I at Software Link, I did work on _DPMI.ASM or $DPMI.SYS and the intention was to get Windows 3.1 to work on PC-MOS. But I found it that Windows would not allowed another DPMI driver work with and I got a message on CompuServe that only people that would allow it was Bill Gates or Steve - this was because of Microsoft struggles with OS/2 at that time.

I did notice a _DPMI.INC in the source but I don't believe it was mine.

I did make a trip to Intel and at asking them about Virtualizing the 386 and the guy from P5 (Pentium) team stated it that they planning on it in a processor. I am not sure which processor works but I did load a up an release image of PC-MOS/386 in VMWare and it did work years later.

I believe this support is in hardware.

[stsp]

$DPMI.SYS and the intention was to get Windows 3.1 to work on PC-MOS.

You mean, with the multitasking still in PC-MOS, even when windows is running? Its a big challenge. :) But the opposite direction, GEMMIS/emm386 - is not much easier, unfortunately...

Virtualizing the 386 and the guy from P5 (Pentium) team stated it that they planning on it in a processor.

I think they meant PVI - an early (P5) and quite broken virtualization extension.

VMWare and it did work years later.

And that was VTx. :) Intel failed to fix their virtualization extensions (even though it was quite simple!), and instead just added the full-blown nested execution framework, stolen (or maybe licensed?) from AMD mostly.

In fact, you may find the "run.sh" script in the current MOS's source tree. Its a light-weight way of running MOS directly out of the build tree, w/o creating any images, w/o any fancy virtualization extensions etc. The only limitation is that $386.sys memory manager will not be loaded, but otherwise it works perfectly.

[stsp]

... and with "run.sh" you get DPMI from host. But how does this go along with MOS's multitasking, is a question - likely, no multitasking in that case. :)

[HStewartGitHome]

Yes DPMI was a huge challenge, it hard to remember - but all I can remember is something was blocking for me from even started working - I was trying to make PC-MOS a DPMI client for Windows 3.1 386 mode and Windows did not allow it.

All I know with recent processors in at least the last couple of year, PC-MOS with 386 driver can run on Virtual Machine image.

[stsp]

PC-MOS as a dpmi client or a server? The thing is, windows 3.1 can work as a regular DPMI client. You just need to provide some dpmi extensions and emulate a few VXDs to get it to work that way. Its quite hard but possible. As for MOS being the client - why?

[HStewartGitHome]

PC-MOS as a dpmi client or a server? The thing is, windows 3.1 can work as a regular DPMI client. You just need to provide some dpmi extensions and emulate a few VXDs to get it to work that way. Its quite hard but possible. As for MOS being the client - why?

It not MOS as client but MOS as server.

Well it almost 30 years since I work on this code and you are right, the problem is with Windows 3.1 being a client to PC-MOS as a server. Windows 3.1 did not allowed it because of IBM's OS/2 for Windows.

I did work with VXD's in my research, but not sure if DPMI part can be replace.

One other cool thing that I never truly explore more but did have it working partially was making Windows 3.1 multiuser. This was done with VXD and communicate to multi-user hardware.

[stsp]

Windows 3.1 did not allowed it because of IBM's OS/2 for Windows.

You mean some legal issues? Well, OS/2 have patched the windows kernel to make it more DPMI-compatible. If there were any legal issues around that, I wonder if they ever applied to the unpatched windows-3.1.

I did work with VXD's in my research

Was it in C or in assembler? The good C-coded VXDs would be quite handy even nowadays. :) In particular the SHELL VXD that liverages a DOS prompt in win31 would be cool to look into.

but not sure if DPMI part can be replace.

It can - even without the OS/2 patches. But there is an additional complication that the unpatched windows kernel would write to LDT directly, and would do lsl to see the LDT size. These 2 things must be carefully considered when implementing the windows-compatible DPMI. Even though the direct LDT writes are very visible, the lsl part is "a secret", even to IBM devs, so they had to replace that part in OS/2 with the proper DPMI-compatible code. I believe the lsl trick was first discovered by the hdpmi author, and after that, running windows as a ring-3 DPMI client became much easier than before. I believe such knowledge was not available when you tried the same thing, so it was very difficult to confine windows to the multitasking environment back then.

Another complication is the need of a full DOS/bios API exposed to protected mode, but this is what most DPMI servers have to do anyway. Most sources in the internet call such thing a "True DPMI" and even claim the existence of some highly secret "True DPMI spec". But even if such spec ever existed, it wasn't very valuable, as it could just be a list of the DOS/bios calls that needed a bounce buffers to work from PM.

One other cool thing that I never truly explore more but did have it working partially was making Windows 3.1 multiuser.

You mean, the separate GUI session per user? But is this possible? How have you done that? There is (was) a dvx project: http://toastytech.com/guis/dvx3.html which allows to render the windows GUI on clien't X server. With that capability I could imaging the win31 multiuser environment, but its not there, and yet you managed to do that? How? :)

[HStewartGitHome]

Yes Microsoft had a Legal issue with IBM, not related to Software Link.

Maybe DPMI can be replace - but at time, I did not think of that.

Well there was two situations with multiuser Windows 3.1 (1 was easier than the other)

1. Showing DOS windows in separate terminal, if I remember was pretty simple - I had VXD output the video to Multi-User hardware

2. Showing actual Windows Application was sort of possible, if I remember I had issues with focus.

I stop the project because some personal reasons. But didn't matter much because I believe in was in earlier 90's