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