Why development remains constant for msdos?

Is there a human being who uses msdos yet?

I see constant updating in fpc 2.7.1 for msdos, was in doubt so I'm asking the question out of curiosity.

thanks

Junior wrote

Why development remains constant for msdos?

Because somebody wants to do so. No more, no less.

hehehe, it was only a question.

Junior wrote

Is there a human being who uses msdos yet?

yes, there are still quitet many DOS systems out there... there's even freeDOS and similar FOSS(?) DOS projects... some of them are even 32bit and can use all available memory like other OSes of today ;)

Florian Kl?mpfl wrote

Am 22.09.2013 13:46, schrieb Junior: > Why development remains constant for msdos? Because somebody wants to do so. No more, no less.

As the person working on the i8086-msdos port, here's the story how it all started: I wanted to learn how FPC code generators work by porting it to a new architecture, but I didn't have any computer in my home with a CPU that isn't supported already (well, except for 6502 :) ). So porting to a new architecture would require buying some exotic hardware from eBay (say, an Itanium or SPARC64) that'll likely be already obsolete in a few years anyway. And one day it occurred to me that I could try an i8086 port. It seemed perfect to me for the following reasons:

1) while, you may consider 16-bit x86 dead, it never really died in the sense that every modern x86 processor (including 64-bit ones) supports it in real mode. In fact, unless you have an UEFI system, 16-bit code is always executed at some point during the boot process, because that's how the BIOS boots the system - it loads the first sector from the hard disk at address 0000h:7C00h and jumps to it in 16-bit real mode. In fact, modern machines are able to boot DOS and it works without issues. If it didn't, boot loaders of modern operating systems wouldn't work either. So, in 5 years, everybody will have a machine that is able to execute i8086 code (and thus, able to test and maintain the port), but that may not be the case for e.g. Itanium or SPARC64. Also, there are plenty of virtual machines available, where you can install DOS and test it. There's also DOSBox. In fact, you can run the FPC testsuite for i8086-msdos on any 32-bit or 64-bit linux _or_ windows via DOSBox.
2) I didn't need to learn an entirely new instruction set and OS API, since I'm already familiar with them, so I could focus only on the compiler itself.
3) There isn't a 16-bit x86 pascal compiler that is free/open source. Borland Pascal is proprietary and while you can download old versions for free from the Embarcadero museum site, the latest version available gratis is 5.5. You can't legally use 7.0, unless you bought it back then and even if you did, you don't have the sources to the compiler, so you can't fix bugs in it and improve it.
4) Since x86 compatibility goes all the way back to 16-bit, if FPC would support it could claim to be the first compiler which supports the full x86 range going all the way from 16-bit up to 64-bit. It's something unique and cool :)
OpenWatcom may be the only other compiler that is able to do it, since they haven't dropped 16-bit support and are supposedly working on 64-bit, but their 64-bit port is still not ready AFAIK. And of course GCC and LLVM are extremely unlikely to do such a crazy thing as a 16-bit port. :)

It all started semi-seriously, I just wanted to see how difficult it would be to do the port, but I soon reached the point of no return, where I had almost got it working and I just had to keep working on it in order to get that next feature going, etc. And also, I'm having a lot of fun, while working on it. I also bought some vintage 16-bit machines from eBay for the extra fun and motivation :)

As for people still using DOS, there's still a community of people using it for fun or for nostalgia reasons. Check out:

http://www.bttr-software.de/forum/forum.php

There's also the FreeDOS project, which was already mentioned by another poster: http://www.freedos.org/

Also note that DOS has always been supported by FPC via the go32v2 dos extender (ok, it might have been go32v1 when fpc was started), but it has always been 32-bit and thus requiring at least a 386. Only the 16-bit DOS support is new.

Nikolay

That's incredible, I knew not!

thanks

Nikolay Nikolov wrote

OpenWatcom may be the only other compiler that is able to do it, since they haven't dropped 16-bit support and are supposedly working on 64-bit, but their 64-bit port is still not ready AFAIK.

FWIW, there is an OpenWatcom fork which is under more active development than the "main" one and has 64bit support there:
http://sourceforge.net/projects/openwatcom/. I haven't tried the 64bit support myself though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130923/84b55fc0/attachment.html>

Interesting. I didn't know about it. From the features list:

"DOS version of tools now support long file names (LFN) if appropriate LFN driver is loaded by DOS"

Maybe we could use their linker for our go32v2 hosted crosscompiler to i8086.

Nikolay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130923/ec8873a0/attachment-0001.html>

yes, there are still quitet many DOS systems out there... there's even freeDOS and similar FOSS(?) DOS projects... some of them are even 32bit and can use all available memory like other OSes of today ;)

How does fpc for DOS handle TThread ?

Just curious...
-Michael

When you try to create a thread, your program terminates and writes a message that threading is not supported. Things like threadvar work in the sense that they compile and work, but since you don't have threads, they behave just like regular vars. Underneath they still generate the extra bloat needed for threadvars (e.g. calls to FPC_THREADVAR_RELOCATE, which are probably stubs and do nothing in the rtl)

Nikolay

Maybe we should adjust the compiler that it treats threadvars really like normal vars if the target does not support threading...

Regards,
Sven

Yes, that's a good idea and in fact I was planning to do it, since it'll save precious space in the i8086 small and tiny memory models (and perhaps the embedded targets also), but I still haven't done it, due to other things with higher priority.

Nikolay

BTW - i have a port of Turbovision -like library called GraphVision (with sources) - window system built entirely on graph unit. I think it is possible to create Lazarus widgetset wrapped around this DOS GUI system.
I'll ask the author - if he agrees to give it out for community.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130925/ae7fbc26/attachment-0001.html>

Nikolay Nikolov wrote

When you try to create a thread, your program terminates and writes a message that threading is not supported.

While this absolutely does make sense, one could think about alternatives.

AFAIK, (at least for some archs) there is a variant of the pthread (="POSIX thread") library, that internally does "user-land multithreading". IIRC, the original POSIX definition was done with exactly this in mind and, regarding Linux, the original Linux implementations (aka "Linux Threads") was not fully compatible with POSIX. Only some years ago, the Linux changed it's way of Kernel-based thread handling to the POSIX compatible "NPTL" implementation.

Thus it should be possible to link fpc projects to a user-land thread enabled version of pthreadlib and allow for working with TThread in DOS.

-Michael

Do you mean DOS as a (16 bit) OS, or as a DOS-Box (terminal)?

I doubt that a DOS OS supports threading at all (scheduling...). What's a thread worth when it never executes?

DoDi

The change happened at different times on different architectures. I've definitely had to write (Lazarus) code to take this into account, since the PID behaviour differed.

But since AIUI LinuxThreads generally attempted to use multiple processes, getting that to work on DOS might be a problem. It would probably be easier to start off with coroutines, and then to change them into real threads by preemption.

Hans-Peter Diettrich wrote

Michael Schnell schrieb: Do you mean DOS as a (16 bit) OS, or as a DOS-Box (terminal)?

As the thread indicates: DOS as in 16 bit DOS, runnable on an 8086 processor. Yes, the compiler could run in the DOSBox product (which emulates the environment 16 bit DOS runs under) but not in a cmd/command window/"DOS" window on e.g. x64 Windows Vista+

Oops, sorry. No idea if the compiler could run on 8086, I seem to remember Nikolay implemented a cross compiler because (I think) the compiler needed more memory than could easily be gotten from DOS... Anyway, obviously the resulting code /is/ targeted for 8086...

I've actually thought about implementing some sort of multithreading for DOS for a long time. The problems are the following:

1) DOS functions are not reetrant and are thus not safe to call from different threads. There's an undocumented InDOS flag that indicates whether a DOS function is safe to call:

http://stanislavs.org/helppc/int_21-34.html

But the RTL currently doesn't check it before every call and normally it's only used when writing TSRs.

2) In DPMI protected mode applications (such as go32v2), you cannot modify the return address from within an interrupt handler, which means you cannot implement your task scheduler as a timer interrupt handler, because you won't be able to switch to a different context from there. Doing this would require modifications to the DPMI host (cwsdpmi.exe) and will not work if another DPMI host is active (such as when running in a windows dos prompt, etc.)

3) Even if you solve 2), DPMI requires that all code and data touched from an interrupt handler to be locked, so that it cannot be swapped out. This is a tedious and error prone task to do from a high level language such as pascal. You should ensure that your entire scheduler's code and data are locked. An alternative option is to switch to a DPMI host, that doesn't support swapping (i.e. cwsdpr0.exe), but then you lose the virtual memory support (and thus the ability to run on machines that don't have enough memory).

2) and 3) do not apply to 16-bit MS-DOS.

Another option is to implement cooperative multitasking, which would require each thread to call periodically an yield function. This solves 1), 2) and 3), but threaded code written for other OSes will require modifications to run under DOS. However, that's still better than not

Hans-Peter Diettrich wrote

Do you mean DOS as a (16 bit) OS, or as a DOS-Box (terminal)?

Of course limited to a "DOS box" this would make no did not do a research on in what environments such pthreadlib could work. I suppose you need a 32 bit DOS extender.

-Michael

You do know there already is a GO32v2 compiler?

It's more complex than that: there's undocumented provision in DOS for context switching under certain well-defined conditions, and each context can invoke int 21h irrespective of other contexts' states. That sort of thing was used fairly extensively by- for example- IBM real-time control executives (RIC card etc.) but it wasn't until the 1990s that it leaked to general knowledge see Ralph Brown's list).

do is provide a per-thread entry point analogous to a unix signal. A preemption interrupt transfers control to this, and then a coroutine mechanism- outside the ISR- transfers control to the most deserving thread.

Sorry if that's a bit vague, it's been many years since I played with this. Implementation left as an exercise :-)

Whether it's really worth tackling, and whether any implementation can be really reliable, are questions to be considered.

Reinier Olislagers wrote

You do know there already is a GO32v2 compiler?

I suppose same does create 32 bit code usable in a DOS-alike environment, and thus could be a target for allowing linking to an internal-user-land-thread enabled version of pthreadlib (while I don't think anybody ever bothered to do a 16 bit version of such a library.

-Michael

Michael Schnell wrote

More than 15 Years ago I on DOS did do the first tests for my preemptive multitasking library (in C), that that finally works (up til now) in an 68K product. :-)

Real mode or DPMI? IMHO, real mode is doable, DPMI - not so much (at least not without using a certain DPMI host with special modifications).

Nikolay

More than 15 Years ago I on DOS did do the first tests for my preemptive multitasking library (in C), that that finally works (up til now) in an 68K product. :-)

-Michael

Nikolay Nikolov wrote

Real mode or DPMI? IMHO, real mode is doable, DPMI - not so much (at least not without using a certain DPMI host with special modifications).

Did DPMI even exist at this time ?

IIRC it was a native 8088 chip -> http://en.wikipedia.org/wiki/Intel_8088

-Michael

15 years ago is 1998, so yes. Maybe it was even earlier?

IIRC it was a native 8088 chip -> http://en.wikipedia.org/wiki/Intel_8088

Real mode it is, then. DPMI requires 286+ and the DOS extender that FPC uses is 386+. Borland Pascal 7 had a 16-bit (286+) DPMI dos extender. We can implement that as well, as soon as the i8086 large memory model is finished. The Open Watcom linker we're using already supports the DOS/16M extender binary format I think.

Nikolay

Nikolay Nikolov wrote

15 years ago is 1998, so yes. Maybe it was even earlier?

Probably.

In fact, 15 years ago the product using the 68K version of the library was released.

-Michael

What has this to do with Lazarus?

Mattias