Re: [Freedos-devel] 32-bit FreeDOS
Before you get too involved with a 32 bit DOS-like operating system can you update us on your progress with FreeDOS 1.2? I thought you were working on that too. On Jun 17, 2015 11:07 AM, Mercury Thirteen mercury0x0...@gmail.com wrote: I think there's been sufficient time for everyone who is interested to reply. Beginning Monday, talks will begin on a 32-bit DOS kernel. On Mon, Jun 8, 2015 at 9:25 PM, Antony Gordon cuzint...@gmail.com wrote: Hi, I'd suggest using 0xC3 0x00 as a magic number for any non-8086 executable. Or, for preference, using a 4-byte magic number: 0xC3 0x00 0x00 followed by a byte giving the supported CPU architecture. Then the logic in the loader would be: Here’s an easier solution. Follow the pattern Microsoft set with PE files. PE files BTW is the executable format for Windows EXE files. Visit this link - http://en.wikibooks.org/wiki/X86_Disassembly/Windows_Executable_Files#MS-DOS_COM_Files i think it might be a little simpler this way. -- John Elliott -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Indeed, the package compilation has been available for two weeks now. You can find it here http://mercurycoding.com/FreeDOS/FreeDOS-1.2.zip. I posted it to get everyone's feedback, so take a look and see if you find anything which should be removed or added. I'm fairly certain I didn't yet catch all the non-open source packages for removal, so comments on that will be particularly useful. An updated version of this compilation (Now, with fewer rogue packages! :-D ) will be available by the end of the month. On Wed, Jun 17, 2015 at 10:00 PM, Michael Brutman mbbrut...@brutman.com wrote: Before you get too involved with a 32 bit DOS-like operating system can you update us on your progress with FreeDOS 1.2? I thought you were working on that too. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Hi snip Do ZM EXEs actually exist? Yes. Any 16-bit MS-DOS target compiler generates MZ executables. FreeDOS is full of them. I've also been curious as to what the format is for .TOS binaries (since GEMDOS has such a similar API to MS-DOS). Grab one and run it through a hex editor. The API has no bearing on the executable file format. In addition, Atari computers were using Motorola processors and not Intel processors with a segmented memory model. -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net mailto:Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Hi, See my other email. In DOS, MZ=ZM, I guess Microsoft changed course at some point. They are typically called MZ executables. On Jun 8, 2015, at 8:55 PM, Steve Nickolas usots...@buric.co wrote: On Mon, 8 Jun 2015, Antony Gordon wrote: Hi snip Do ZM EXEs actually exist? Yes. Any 16-bit MS-DOS target compiler generates MZ executables. FreeDOS is full of them. I said ZM, not MZ. -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
On Mon, 8 Jun 2015, Antony Gordon wrote: Hi, See my other email. In DOS, MZ=ZM, I guess Microsoft changed course at some point. They are typically called MZ executables. I was specifically referring to the specific magic number that would show up as ZM in a text editor. All the files I've seen have the number in the opposite order such that the magic number appears as MZ. -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
And I said MJ for Michael Jordan not Michael Jackson. On 09/06/2015 10:51 am, Steve Nickolas usots...@buric.co wrote: On Mon, 8 Jun 2015, Antony Gordon wrote: Hi snip Do ZM EXEs actually exist? Yes. Any 16-bit MS-DOS target compiler generates MZ executables. FreeDOS is full of them. I said ZM, not MZ. -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Hi, It’s all semantics. Most signatures are MZ, but some old linkers (not sure if they are even in use) used ZM according to RBIL Values for the executable types understood by various environments: MZ old-style DOS executable (see #01594 http://www.delorie.com/djgpp/doc/rbinter/it/94/15.html) ZM used by some very early DOS linkers, and still supported as an alternate to the MZ signature by MS-DOS, PC DOS, PTS-DOS, and S/DOS -T On Jun 8, 2015, at 9:16 PM, Steve Nickolas usots...@buric.co wrote: On Mon, 8 Jun 2015, Antony Gordon wrote: Hi, See my other email. In DOS, MZ=ZM, I guess Microsoft changed course at some point. They are typically called MZ executables. I was specifically referring to the specific magic number that would show up as ZM in a text editor. All the files I've seen have the number in the opposite order such that the magic number appears as MZ. -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Hi
snip
I'd suggest using 0xC3 0x00 as a magic number for any non-8086 executable.
Or, for preference, using a 4-byte magic number: 0xC3 0x00 0x00 followed by
a byte giving the supported CPU architecture. Then the logic in the loader
would be:
0xC3 0x00 0x00 suitable architecture - run as native EXE
0xC3 0x00 0x00 unsuitable architecture - return an error
0x4D 0x5A (or 0x5A 0x4D) - run in emulator as x86 EXE
anything else- run in emulator as x86 COM
The only problem I see is that to make an executable file that DOS recognizes
according to the API, it has to follow this structure (in C for clarity)
struct EXE {
unsigned short signature; /* == 0x5a4D */
unsigned short bytes_in_last_block;
unsigned short blocks_in_file;
unsigned short num_relocs;
unsigned short header_paragraphs;
unsigned short min_extra_paragraphs;
unsigned short max_extra_paragraphs;
unsigned short ss;
unsigned short sp;
unsigned short checksum;
unsigned short ip;
unsigned short cs;
unsigned short reloc_table_offset;
unsigned short overlay_number;
};
struct EXE_RELOC {
unsigned short offset;
unsigned short segment;
};
To maintain compatibility with MS-DOS and FreeDOS, we are constrained by the
loader. The signature has to be first. Here are some additional signatures
that can appear in a DOS .EXE file
Values for the executable types understood by various environments:
MZ old-style DOS executable (see #01594
http://www.delorie.com/djgpp/doc/rbinter/it/94/15.html)
ZM used by some very early DOS linkers, and still supported as an
alternate to the MZ signature by MS-DOS, PC DOS, PTS-DOS, and S/DOS
NE Windows or OS/2 1.x segmented (new) executable (see #01596
http://www.delorie.com/djgpp/doc/rbinter/it/96/15.html)
LE Windows virtual device driver (VxD) linear executable (see #01609
http://www.delorie.com/djgpp/doc/rbinter/it/09/16.html)
LX variant of LE used in OS/2 2.x (see #01609
http://www.delorie.com/djgpp/doc/rbinter/it/09/16.html)
W3 Windows WIN386.EXE file; a collection of LE files
W4 Windows95 VMM32.VXD file
PE Win32 (Windows NT and Win32s) portable executable based on Unix COFF
DL HP 100LX/200LX system manager compliant executable (.EXM)
MP old PharLap .EXP (see #01619
http://www.delorie.com/djgpp/doc/rbinter/it/19/16.html)
P2 PharLap 286 .EXP (see #01620
http://www.delorie.com/djgpp/doc/rbinter/it/20/16.html)
P3 PharLap 386 .EXP (see #01620
http://www.delorie.com/djgpp/doc/rbinter/it/20/16.html)
Retrieved from http://www.delorie.com/djgpp/doc/rbinter/it/93/15.html
http://www.delorie.com/djgpp/doc/rbinter/it/93/15.html
Obviously we can add to the loader code in FreeDOS so it can recognize a
FreeDOS non x86 architecture EXE file, or we can extend after offset 0x1C with
architectural information as the EXE header is 512 bytes IIRC. This extension
can be back ported to the 16-bit version, so at the very least it can say “This
program requires FreeDOS 32” or something to that effect similar in function to
the Windows PE executables.
The reason for using 0xC3 0x00 as the magic number is that no useful
DOS COM file will start with those bytes (0xC3 is x86 for RET). The extended
sequence 0xC3 0x00 0x00 also rules out CP/M-80 COM files, which might start
with 0xC3 but won't follow that with two zeroes.
--
John Elliott
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
On Mon, 8 Jun 2015, Antony Gordon wrote: Hi, It’s all semantics. Most signatures are MZ, but some old linkers (not sure if they are even in use) used ZM according to RBIL Values for the executable types understood by various environments: MZ old-style DOS executable (see #01594 http://www.delorie.com/djgpp/doc/rbinter/it/94/15.html) ZM used by some very early DOS linkers, and still supported as an alternate to the MZ signature by MS-DOS, PC DOS, PTS-DOS, and S/DOS Right, that's what I was referring to. I've never seen the latter. -uso.-- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
On Tue, 9 Jun 2015, John Elliott wrote: If you can mark the EXEs as something other than MZ, you could perhaps make a TSR loader stub that loads an x86 emulator on demand to run EXE files. COM... I think you're gonna be stuck with using only an EXE format because trying to detect a COM file by architecture is fraught with peril. I'd suggest using 0xC3 0x00 as a magic number for any non-8086 executable. Or, for preference, using a 4-byte magic number: 0xC3 0x00 0x00 followed by a byte giving the supported CPU architecture. Then the logic in the loader would be: 0xC3 0x00 0x00 suitable architecture - run as native EXE 0xC3 0x00 0x00 unsuitable architecture - return an error 0x4D 0x5A (or 0x5A 0x4D) - run in emulator as x86 EXE anything else- run in emulator as x86 COM The reason for using 0xC3 0x00 as the magic number is that no useful DOS COM file will start with those bytes (0xC3 is x86 for RET). The extended sequence 0xC3 0x00 0x00 also rules out CP/M-80 COM files, which might start with 0xC3 but won't follow that with two zeroes. Do ZM EXEs actually exist? I've also been curious as to what the format is for .TOS binaries (since GEMDOS has such a similar API to MS-DOS). -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
On Mon, 8 Jun 2015, Antony Gordon wrote: Hi snip Do ZM EXEs actually exist? Yes. Any 16-bit MS-DOS target compiler generates MZ executables. FreeDOS is full of them. I said ZM, not MZ. -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Hi, On Fri, Jun 5, 2015 at 5:10 PM, Steve Nickolas usots...@buric.co wrote: A port of DOS to ARM would not be bound to any existing API and would not need to be compatible with any existing DOS implementations, while still being a port of DOS. I know this might be stating the obvious, but you don't need a full port to ARM. Just emulate it. https://www.raspberrypi.org/8086tiny-free-pc-xt-emulator/ -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Hi, On Jun 5, 2015, at 6:10 PM, Steve Nickolas usots...@buric.co wrote: A port of DOS to ARM would not be bound to any existing API and would not need to be compatible with any existing DOS implementations, while still being a port of DOS. That’s technically incorrect. The reason that Linux (and UNIX) work on different architectures is that the API is the same, but the low level interface to the hardware is the difference. Since there is no BIOS to speak of on other processors, nor a concept of real and protected mode, a lot will have to go into the kernel, basically making a hardware abstraction layer that emulates the BIOS, that can process a DOS executable for Intel processors and make determinations on whether it is a 16-bit application or a 32-bit application and run it accordingly. If you don’t keep the basic DOS API (via Int 21h) then it’s technically not DOS, but another operating system. Microsoft attempted (for the x86 version) to keep a compatibility layer in the OS so that you could run DOS applications, even though these applications were written for a single task, 16-bit real mode OS that allowed direct hardware access, which unfortunately can cause issues in a 32-bit protected mode environment. Fortunately, the benefit in our favor is some of this work has already been done. There is an open source BIOS implementation that can be grafted in to FreeDOS, it’s just a matter of figuring out which one to use and how to implement it. -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
A port of DOS to ARM would not be bound to any existing API and would not need to be compatible with any existing DOS implementations, while still being a port of DOS. -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
I agree, a 32-bit kernel would open up worlds of possibilities for the DOS platform. Also, just to clarify, I wasn't asking anyone's permission, just probing to see what kind of interest there is out there. I used to follow DOSCore and Aura closely back in the day when I was working (off and on, but mostly off) on my own GUI for DOS. Just to keep an eye on what the competition was doing lol I remember back then you guys making some impressive strides in the GUI department. But seriously, though, once I gauge the interest here, I'll set up some kind of separate chat (a GroupMe or a simple multi-target email) to take things to the next step. Chelson, I think your input would be valuable in such a project. On Fri, Jun 5, 2015 at 5:39 PM, Chelson Aitcheson chelson.aitche...@gmail.com wrote: To see it on the arm architecture I think would be a good long term goal for a 32 bit kernel. Raspberry pi and other small arm boards are cheap and affordable and would breathe life into the dos platform. You don't need the freedos community approval or help as such for a project. Just do it. It doesn't have to be tied into fd directly but I believe it's the future of dos while others can play in the 16 bit world and their archaic xt's I have all ready been criticised and labeled a mobile game app developer which I'm not but I will help as I have plans to move doscore and aura gui into its own system as freedos is no longer viable as it lacks 32 bit kernels. On 06/06/2015 6:50 am, Mercury Thirteen mercury0x0...@gmail.com wrote: I am considering starting a test project to determine the feasibility of implementing a 32-bit FreeDOS kernel. If I decide to do so, who else is interested in contributing? Said contributors could assist in coding, help with testing, establish and evolve standards for the project, create documentation and many other things. I am not saying we are going to reinvent the DOS platform or alter the course of space and time, but merely take a short ride down the *what-would've-happened-if-Microsoft-hadn't-ditched-DOS-for-Windows?* road. We will realistically determine the difficulty involved in such a project without branching off into *why the %@*# would you do something like that?* or *ARRRGH this is **pointless and you all are fools!* territory, then weigh that difficulty against our combined talents and proceed accordingly based on our findings. We who are interested in this venture will move all discussion of the project and any associated topics to a separate independent group discussion to avoid further irritating those stuck in 1987 cluttering this forum. FreeDOS will remain 16-bit for the foreseeable future and FreeDOS-32 development seems stalled indefinitely. As often as discussion on a 32-bit DOS is stifled, the topic still resurfaces again and again - suggesting to me there is genuine interest in it. So I pose the question: who would like to investigate this becoming a reality? Anyone who is interested can email me directly at *mercury0x0...@gmail.com mercury0x0...@gmail.com*. On Mon, Jun 1, 2015 at 3:28 PM, Mercury Thirteen mercury0x0...@gmail.com wrote: On Mon, Jun 1, 2015 at 3:16 PM, Chelson Aitcheson chelson.aitche...@gmail.com wrote: Haha I got laughed at and criticized for these ideas. +1 Just make it don't worry about the community. +10 -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
I am considering starting a test project to determine the feasibility of implementing a 32-bit FreeDOS kernel. If I decide to do so, who else is interested in contributing? Said contributors could assist in coding, help with testing, establish and evolve standards for the project, create documentation and many other things. I am not saying we are going to reinvent the DOS platform or alter the course of space and time, but merely take a short ride down the *what-would've-happened-if-Microsoft-hadn't-ditched-DOS-for-Windows?* road. We will realistically determine the difficulty involved in such a project without branching off into *why the %@*# would you do something like that?* or *ARRRGH this is **pointless and you all are fools!* territory, then weigh that difficulty against our combined talents and proceed accordingly based on our findings. We who are interested in this venture will move all discussion of the project and any associated topics to a separate independent group discussion to avoid further irritating those stuck in 1987 cluttering this forum. FreeDOS will remain 16-bit for the foreseeable future and FreeDOS-32 development seems stalled indefinitely. As often as discussion on a 32-bit DOS is stifled, the topic still resurfaces again and again - suggesting to me there is genuine interest in it. So I pose the question: who would like to investigate this becoming a reality? Anyone who is interested can email me directly at *mercury0x0...@gmail.com mercury0x0...@gmail.com*. On Mon, Jun 1, 2015 at 3:28 PM, Mercury Thirteen mercury0x0...@gmail.com wrote: On Mon, Jun 1, 2015 at 3:16 PM, Chelson Aitcheson chelson.aitche...@gmail.com wrote: Haha I got laughed at and criticized for these ideas. +1 Just make it don't worry about the community. +10 -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
To see it on the arm architecture I think would be a good long term goal for a 32 bit kernel. Raspberry pi and other small arm boards are cheap and affordable and would breathe life into the dos platform. You don't need the freedos community approval or help as such for a project. Just do it. It doesn't have to be tied into fd directly but I believe it's the future of dos while others can play in the 16 bit world and their archaic xt's I have all ready been criticised and labeled a mobile game app developer which I'm not but I will help as I have plans to move doscore and aura gui into its own system as freedos is no longer viable as it lacks 32 bit kernels. On 06/06/2015 6:50 am, Mercury Thirteen mercury0x0...@gmail.com wrote: I am considering starting a test project to determine the feasibility of implementing a 32-bit FreeDOS kernel. If I decide to do so, who else is interested in contributing? Said contributors could assist in coding, help with testing, establish and evolve standards for the project, create documentation and many other things. I am not saying we are going to reinvent the DOS platform or alter the course of space and time, but merely take a short ride down the *what-would've-happened-if-Microsoft-hadn't-ditched-DOS-for-Windows?* road. We will realistically determine the difficulty involved in such a project without branching off into *why the %@*# would you do something like that?* or *ARRRGH this is **pointless and you all are fools!* territory, then weigh that difficulty against our combined talents and proceed accordingly based on our findings. We who are interested in this venture will move all discussion of the project and any associated topics to a separate independent group discussion to avoid further irritating those stuck in 1987 cluttering this forum. FreeDOS will remain 16-bit for the foreseeable future and FreeDOS-32 development seems stalled indefinitely. As often as discussion on a 32-bit DOS is stifled, the topic still resurfaces again and again - suggesting to me there is genuine interest in it. So I pose the question: who would like to investigate this becoming a reality? Anyone who is interested can email me directly at *mercury0x0...@gmail.com mercury0x0...@gmail.com*. On Mon, Jun 1, 2015 at 3:28 PM, Mercury Thirteen mercury0x0...@gmail.com wrote: On Mon, Jun 1, 2015 at 3:16 PM, Chelson Aitcheson chelson.aitche...@gmail.com wrote: Haha I got laughed at and criticized for these ideas. +1 Just make it don't worry about the community. +10 -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Low end *nix apps could be ported in place of over dos apps hell we could just make a Linux distro and slap a freedos sticker on it lol. Problem is there are two arguments here.. why and why not. If you build it they will come. If you don't then be happy carrying your xt's on your back. On 06/06/2015 8:19 am, Eric Auer e.a...@jpberlin.de wrote: Hi! A port of DOS to ARM would not be bound to any existing API and would not need to be compatible with any existing DOS implementations, while still being a port of DOS. Well we already HAD a port to another CPU in the early times of FreeDOS: After all, it acts a bit like a library with an API on one side and invocations of the BIOS on another side. I have no clue what sort of BIOS you can expect from common ARM computers and whether they have a BIOS at all - probably no, just a boot loader and lots of information for making your own drivers? In any case, the main problem is: Which apps will run on your ported DOS? With the other port, the answer was very few and you had to port them from open source DOS apps yourself, but at least porting was easy for apps which avoided direct calls to the BIOS and direct hardware access. If you port to ARM, you will probably have to compete with Linux because Linux already runs on ARM and many apps have already been ported to various ARM versions of Linux. The advantage of DOS, as usual, will be a low memory and disk footprint, while it will lack built-in network, multi-threading, multi-tasking and memory management support. Only for some of those, library solutions for DOS are available (in particular the first and last item on the list) but those libraries are very specific to PC hardware and will be quite hard to port to DOS. If you want built-in support, you still have to provide the function in your ARM-DOS in some other way. There also are a number of hobby operating system where people thought well, I could make an OS from scratch, then it will have all the API that I want without all the overhead of any larger OS, plus I like challenges. Almost all such OS have exciting but one-person histories and barely any apps for them. Still, they probably are worth the excitement for the author. Cheers, Eric -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Doesn't matter, Mac os power pc applications dont work on new Mac os but it's still the same os. (rosetta comparability layer aside) I see this as more of a chance for a new generation of dos. Freedos 1.x has accomplished the needs for the existing replacement or clone requirements of a dos with enhancements and still caters to the needs of its users. Yes it's lots of work to port stuff and to add compatibility layers etc.. but where is your sense of adventure? Yeah merc I see doscore on arm in a few years. On 06/06/2015 8:05 am, Steve Nickolas usots...@buric.co wrote: A port of DOS to ARM would not be bound to any existing API and would not need to be compatible with any existing DOS implementations, while still being a port of DOS. -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
On Sat, 6 Jun 2015, Chelson Aitcheson wrote: Doesn't matter, Mac os power pc applications dont work on new Mac os but it's still the same os. (rosetta comparability layer aside) I see this as more of a chance for a new generation of dos. Freedos 1.x has accomplished the needs for the existing replacement or clone requirements of a dos with enhancements and still caters to the needs of its users. Yes it's lots of work to port stuff and to add compatibility layers etc.. but where is your sense of adventure? Yeah merc I see doscore on arm in a few years. If you can mark the EXEs as something other than MZ, you could perhaps make a TSR loader stub that loads an x86 emulator on demand to run EXE files. COM... I think you're gonna be stuck with using only an EXE format because trying to detect a COM file by architecture is fraught with peril. -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Nothing is impossible if it was the case we would all still be using reel to reel and tape decks lol. Lots of ideas and spit balling here but hey why not write it up and if people wana contribute then they will if not keep using old trusty xt On 06/06/2015 8:39 am, Steve Nickolas usots...@buric.co wrote: On Sat, 6 Jun 2015, Chelson Aitcheson wrote: Doesn't matter, Mac os power pc applications dont work on new Mac os but it's still the same os. (rosetta comparability layer aside) I see this as more of a chance for a new generation of dos. Freedos 1.x has accomplished the needs for the existing replacement or clone requirements of a dos with enhancements and still caters to the needs of its users. Yes it's lots of work to port stuff and to add compatibility layers etc.. but where is your sense of adventure? Yeah merc I see doscore on arm in a few years. If you can mark the EXEs as something other than MZ, you could perhaps make a TSR loader stub that loads an x86 emulator on demand to run EXE files. COM... I think you're gonna be stuck with using only an EXE format because trying to detect a COM file by architecture is fraught with peril. -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Hey, On Jun 5, 2015, at 6:49 PM, Chelson Aitcheson chelson.aitche...@gmail.com wrote: Nothing is impossible if it was the case we would all still be using reel to reel and tape decks lol. Lots of ideas and spit balling here but hey why not write it up and if people wana contribute then they will if not keep using old trusty xt Two thumbs up On 06/06/2015 8:39 am, Steve Nickolas usots...@buric.co mailto:usots...@buric.co wrote: On Sat, 6 Jun 2015, Chelson Aitcheson wrote: Doesn't matter, Mac os power pc applications dont work on new Mac os but it's still the same os. (rosetta comparability layer aside) I see this as more of a chance for a new generation of dos. Freedos 1.x has accomplished the needs for the existing replacement or clone requirements of a dos with enhancements and still caters to the needs of its users. Yes it's lots of work to port stuff and to add compatibility layers etc.. but where is your sense of adventure? Yeah merc I see doscore on arm in a few years. If you can mark the EXEs as something other than MZ, you could perhaps make a TSR loader stub that loads an x86 emulator on demand to run EXE files. COM... I think you're gonna be stuck with using only an EXE format because trying to detect a COM file by architecture is fraught with peril. -uso. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net mailto:Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Eric, It’s involved, but so was writing an MS-DOS clone almost 17 years ago that is able to run 98% of all DOS software natively factoring in the quirks and undocumented and partially documented structures that had to be clean room implemented to avoid infringement. You and I were around for the beginnings of FreeDOS (when Pat was involved) and it was looking shaky then. Now FreeDOS in places were there was nothing to fit the bill, such as BIOS update disks, disk recovery tools, and emergency boot disks. What I am advocating is a next level inclusion. Version 1.2 of FreeDOS is what, pushing out things that don’t use the GPL license and/or is free but the source code is no where to be found. The idea I have isn’t to create DOS windows in Windows but rather to build, using the Windows kernel which we can pull portions from Wine and/or ReactOS, load Windows drivers, and create a hardware compatibility layer whereby you can map an onboard sound card to the Sound Blaster settings, i.e., SET BLASTER=A220 I5 D1 T3 P330 H6 E620. USB game controllers can be mapped to the game port, USB printers to the parallel port, etc. I’m not interested incorporating the GUI portion of Windows and given the open source nature of some of the other projects, I think having access to incorporate these pieces into a FreeDOS 32 project would be ideal. On May 31, 2015, at 7:08 AM, Eric Auer e.a...@jpberlin.de wrote: Hi Antony, if the goal is only to use Windows driver, then writing a clone of Windows is a high price. Plus it already has been paid, by the ReactOS project. Note that DOS windows in Windows often do not gain from Windows drivers: For example if your soundcard comes with a Windows driver, your DOS games still can not use that, even in Windows. The exception would be dosemu and dosbox in Linux and, only the latter, in Windows: Those simulate a PC with DOS compatible hardware. They are not just DOS windows. So regarding the balance between gain and effort, the big question is: For WHICH (categories of) pieces of Windows hardware do you want better DOS support? You already say that mouse, keyboard and storage are not enough, so what else? You mention VMware, Parallels and VirtualBox: Those all simulate complete PC hardware, VM aware client drivers there are just to add features, such as the host / client drive sharing for which at least some VMware DOS driver already has been written afaik :-) I remember that the joystick category already is known to DOS USB drivers: The problem probably is that many games do NOT use the BIOS calls to query joystick status. Instead, they directly access the joystick port hardware, but that expects non-USB. Again, full hardware simulations can give your DOS game access to non-DOS sound and joystick, but DOS windows in Windows are not enough for that... And a full hardware simulation is not what you are looking for, apparently: You only want DOS which somehow at the same time is almost Windows, so it can use Windows drivers. To make that really work, you would end up having a lot of Windows plus some PC hardware simulator, which is much more than DOS. For thinking about how small a system could be to combine DOS and sufficient magic to support those pieces of Windows hardware you are intersted in, the main question is: WHICH Windows hardware driver categories are you interested in? Regards, Eric PS: Your intuition that using Windows drivers and not Linux drivers for DOS probably comes from DOS and Windows being from the same company. Yet BOTH modern driver ecosystems are totally DOS unrelated. There IS some DOS software with Linux sound drivers. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Haha I got laughed at and criticized for these ideas. Just make it don't worry about the community. On 29/05/2015 6:47 am, Antony Gordon cuzint...@gmail.com wrote: I was re-reading some emails and I think I have an idea of how this would work. The goal is existing compatibility so that older DOS applications will run. Obviously, moving to 32-bit will eliminate most of the older processors, HOWEVER. by implementing a Windows 9x like model and build a 32-bit kernel to supplant the 16-bit kernel, we can then spawn 16-bit VM under a 32-bit kernel to run each 16-bit application, as well as develop 32-bit applications. The important pieces I believe that need to be figured out is the VMM (Virtual Machine Manager) and the DOS Extender. I only suggest Windows 9x because it was still able to utilize real mode DOS drivers. Thoughts? -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
On Mon, Jun 1, 2015 at 3:16 PM, Chelson Aitcheson chelson.aitche...@gmail.com wrote: Haha I got laughed at and criticized for these ideas. +1 Just make it don't worry about the community. +10 -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Hi Antony, if the goal is only to use Windows driver, then writing a clone of Windows is a high price. Plus it already has been paid, by the ReactOS project. Note that DOS windows in Windows often do not gain from Windows drivers: For example if your soundcard comes with a Windows driver, your DOS games still can not use that, even in Windows. The exception would be dosemu and dosbox in Linux and, only the latter, in Windows: Those simulate a PC with DOS compatible hardware. They are not just DOS windows. So regarding the balance between gain and effort, the big question is: For WHICH (categories of) pieces of Windows hardware do you want better DOS support? You already say that mouse, keyboard and storage are not enough, so what else? You mention VMware, Parallels and VirtualBox: Those all simulate complete PC hardware, VM aware client drivers there are just to add features, such as the host / client drive sharing for which at least some VMware DOS driver already has been written afaik :-) I remember that the joystick category already is known to DOS USB drivers: The problem probably is that many games do NOT use the BIOS calls to query joystick status. Instead, they directly access the joystick port hardware, but that expects non-USB. Again, full hardware simulations can give your DOS game access to non-DOS sound and joystick, but DOS windows in Windows are not enough for that... And a full hardware simulation is not what you are looking for, apparently: You only want DOS which somehow at the same time is almost Windows, so it can use Windows drivers. To make that really work, you would end up having a lot of Windows plus some PC hardware simulator, which is much more than DOS. For thinking about how small a system could be to combine DOS and sufficient magic to support those pieces of Windows hardware you are intersted in, the main question is: WHICH Windows hardware driver categories are you interested in? Regards, Eric PS: Your intuition that using Windows drivers and not Linux drivers for DOS probably comes from DOS and Windows being from the same company. Yet BOTH modern driver ecosystems are totally DOS unrelated. There IS some DOS software with Linux sound drivers. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Eric, It’s simple. Every piece of computer hardware comes with a Windows driver. Depending on the age of the device, you may have the older Windows drivers, or the newer Windows Driver Model driver. The reality is that to the major manufacturers of hardware, DOS is dead. No one is using a 16-bit OS, especially DOS, excluding our demographic, or as an “emergency boot disk. The bare minimum is 32-bit and now the transition is to 64-bit operating systems. DOS is so “dead” that VMWare, Parallels, and VirtualBox (even though the latter is aware of FreeDOS/MS-DOS usage) do not provide integration services or support for DOS and Windows 3.x USB support in DOS is limited to hard drives only, perhaps USB keyboards and mice as they can emulate their PS/2 counterparts. What about USB game controllers, if you weren’t fortunate enough to buy a game controller that runs off the game port of your sound card, you’re definitely not getting it to run on FreeDOS. Which means you have to play your favorite video games using the keyboard. It’s true, you can install Linux or another OS, install the emulator of your choice, connect your game controller and have it emulate as a game port controller in FreeDOS, but what if you only want FreeDOS on your machine? If we are able to graft the Windows API into FreeDOS (as FreeDOS 32) then we have access to thousands of drivers. If Windows is just so bad, then I guess we’re left to contemplate a way to graft the Linux driver model onto FreeDOS. Somehow, I think it would be much easier to do Windows. Hope this helps, On May 29, 2015, at 11:31 AM, Eric Auer e.a...@jpberlin.de wrote: Hi Anthony, please explain in which way Windows WITHOUT a GUI would be something that we want to add to FreeDOS: There already are really good, free and open DPMI based DOS extenders for DOS. FreeDOS itself is not running in protected mode, but every EMM386 style software must use protected mode (not to be confused with EMS hardware solutions for old computers) and Windows in 386 enhanced mode is not compatible with normal EMM386. Instead, it uses an exotic interface called GEMMIS to REPLACE EMM386 on the fly. This only works with non-free versions, for example Microsoft EMM386. The solution is to use either the Microsoft version or simply not use EMM386. In some cases, HIMEM and similar drivers can cause similar problems, but again, you can use the Microsoft drivers :-) Microsoft mainly patches DOS when it tries to put it into a protected mode bubble to be able to run DOS windows in a Windows session. In standard mode, Windows is more like a normal program for DOS, which makes things easier :-) As described earlier in this thread, you do have to edit your Windows config AND you have to use special versions of the FreeDOS kernel to support that bubble wrapping or patching of FreeDOS for 386enh Windows compatibility. If Windows can not figure out how to patch DOS, it will give a similar error message to the already protected mode one. Microsoft demonstrated a means of providing multitasking and 32-bit functionality on top of a 16-bit OS through the development of Windows 3.x and Windows 9x. If we are able to build a 32-bit subsystem that can utilize the device drivers and other existing components of the 32-bit Microsoft subsystem (Win32s or Windows 9x) then FreeDOS gains a 32-bit option that provides the backwards compatibility that is needed to meet spec. Everything that you mention in the previous paragraph is useful only for graphical Windows software: To summarize, you really should try Linux with Wine, or ReactOS for it. Regards, Eric PS: Even running only multiple DOS Windows in Windows is already something that does need the GUI of Windows, too. But you can work with DOS task swappers, as TriDOS :-) They swap between different (full screen) DOS sessions. This is not related to how many bits your Windows has. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Hello all, I can do the development. I have time and like programming (i have an own OS bird os...yes i like birds). If that was the question. But my question is, why should you switch tot 32-bit? It have a lot features But MS-DOS is and was 16-bit. If we switch to 32-bit do you get Windows rather then the original 16-bit MS-DOS. Greetings, Maarten Op 28 mei 2015 23:38 schreef Georg Potthast mail...@georgpotthast.de: My thought is: who shall do the development? There is no one around that would spend the time to develop this. - Original Message - From: Antony Gordon cuzint...@gmail.com To: Technical discussion and questions for FreeDOS developers. freedos-devel@lists.sourceforge.net Sent: Thursday, May 28, 2015 10:47 PM Subject: [Freedos-devel] 32-bit FreeDOS I was re-reading some emails and I think I have an idea of how this would work. The goal is existing compatibility so that older DOS applications will run. Obviously, moving to 32-bit will eliminate most of the older processors, HOWEVER. by implementing a Windows 9x like model and build a 32-bit kernel to supplant the 16-bit kernel, we can then spawn 16-bit VM under a 32-bit kernel to run each 16-bit application, as well as develop 32-bit applications. The important pieces I believe that need to be figured out is the VMM (Virtual Machine Manager) and the DOS Extender. I only suggest Windows 9x because it was still able to utilize real mode DOS drivers. Thoughts? -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Eric, I only mentioned the Windows portion because it would tie in compatibility on the Microsoft side of things for classic software, not necessarily to re-invent Windows 3.x or Windows 9x. I'll try to elaborate more. If you strip the GUI from MS Windows, you have 3 important parts that run to implement 32-bit protected mode. KRNL386, DOSX (the DOS Extender) and a virtual machine manager. If we were able to recreate those three components and build them in such a way that they are compatible with Windows virtual device drivers, we'd have a 32-bit extension to FreeDOS that we could use At the core of it's existence, The portions of the Windows 3.x subsystem that tie into DOS in 386 Enhanced mode consists of a DPMI server and a virtual machine manager of sorts. Microsoft patches certain aspects of DOS when Windows runs. In 1993, we were at best guessing (unless you had an OEM NDA) what was going on and depending on Andrew Schulmann et. al. to provide insight. Now, that we can clearly see what was done (more or less), we can implement a similar concept, but a different way. FreeDOS presently appears to run in protected mode (I found that out trying to run Windows in enhanced mode). The error message that Windows gave was that the processor was already in protected mode. Microsoft demonstrated a means of providing multitasking and 32-bit functionality on top of a 16-bit OS through the development of Windows 3.x and Windows 9x. If we are able to build a 32-bit subsystem that can utilize the device drivers and other existing components of the 32-bit Microsoft subsystem (Win32s or Windows 9x) then FreeDOS gains a 32-bit option that provides the backwards compatibility that is needed to meet spec. If, by doing that, running Windows applications becomes a possibility, that is only a side benefit. The other alternative is to find a way to implement the DOS API completely in a 32-bit address space, which alienates the older applications. On Thu, May 28, 2015 at 8:55 PM, Eric Auer e.a...@jpberlin.de wrote: Hi :-) 1. Start FreeDOS (16-bit mode) 2. Start FreeDOS-32 via a separate executable (it would only be installed if it detected a 32-bit capable processor), perhaps call it FD32. It would switch to protected mode and spawn a protected mode shell. http://freedos-32.sourceforge.net/ already exists. No news since 2011. FD32 runs more parts in 32-bit, but the advantages compared to using a classic DOS together with a DPMI compatible DOS extender are minimal. The other possibility During the install, determine if the computer can support 32-bit instruction set If so, install FreeDOS and install the FreeDOS 32-bit components (provide an option to only run the 16-bit OS) FreeDOS 32 starts automatically by running the initial 16-bit environment, then spawning the 32-bit environment to take over. We once pondered this as part of the ISO boot process. But because it is almost impossible to boot from CD on 8086 or 286 computers, we dropped the idea. Instead, just take a floppy with a special 16 bit, 8086 compatible version of DOS if you have such old hardware. The ISO simply assumes that you have 386 or newer hardware anyway. Interestingly, 8086 or PC-XT compatible FreeDOS floppy distros are actively discussed here and even updated at this very moment :-) All existing drivers developed for FD16 would work. If we use the Windows SDK to clean build the 32-bit environment, then perhaps we can use Win9x drivers (if they are even still available). You cannot use Win9x drivers for DOS software. Also, you cannot use Windows for Workgroups 3.11 in 386 enhanced mode and expect it to behave well: It will use built-in 32 bit disk and FAT drivers which do not work well at all with modern things like FAT32, LBA, SATA. You can disable those drivers, but running WfW 3.11 in that mode is like running Win9x in safe mode: A lot of comfort gets lost. If you want to enjoy Windows 3 in FreeDOS, use Windows 3.0 or 3.1 and use standard mode, not WfW 3.11 - even 386enh mode of 3.0 / 3.1 is very fragile as all your drivers have to cooperate and let Windows take over as the boss of your protected mode infrastructure, locking the DOS kernel into a vm86 bubble with a task switching wrapper around it. FreeDOS tries to support that in newer kernels, but this stays really hard to do well because basically Microsoft Windows is only skilled in making bubbles around Microsoft DOS, so we can only try to be very similar in the parts to which the 386enh bubble sticks. Otherwise, we’d have to clean room Win NT to implement a 32-bit OS and ReactOS is still in alpha... If you want to use 32 bit Windows programs (beyond Win32s for 3.x), you do not have the option to use DOS for that. You must use either ReactOS or Linux with Wine or a closed source OS like OS/2 or actual Microsoft Windows. In some cases, Japheth's HX / HXRT for DOS will be able to run really lightweight Windows
Re: [Freedos-devel] 32-bit FreeDOS
Hi Anthony, please explain in which way Windows WITHOUT a GUI would be something that we want to add to FreeDOS: There already are really good, free and open DPMI based DOS extenders for DOS. FreeDOS itself is not running in protected mode, but every EMM386 style software must use protected mode (not to be confused with EMS hardware solutions for old computers) and Windows in 386 enhanced mode is not compatible with normal EMM386. Instead, it uses an exotic interface called GEMMIS to REPLACE EMM386 on the fly. This only works with non-free versions, for example Microsoft EMM386. The solution is to use either the Microsoft version or simply not use EMM386. In some cases, HIMEM and similar drivers can cause similar problems, but again, you can use the Microsoft drivers :-) Microsoft mainly patches DOS when it tries to put it into a protected mode bubble to be able to run DOS windows in a Windows session. In standard mode, Windows is more like a normal program for DOS, which makes things easier :-) As described earlier in this thread, you do have to edit your Windows config AND you have to use special versions of the FreeDOS kernel to support that bubble wrapping or patching of FreeDOS for 386enh Windows compatibility. If Windows can not figure out how to patch DOS, it will give a similar error message to the already protected mode one. Microsoft demonstrated a means of providing multitasking and 32-bit functionality on top of a 16-bit OS through the development of Windows 3.x and Windows 9x. If we are able to build a 32-bit subsystem that can utilize the device drivers and other existing components of the 32-bit Microsoft subsystem (Win32s or Windows 9x) then FreeDOS gains a 32-bit option that provides the backwards compatibility that is needed to meet spec. Everything that you mention in the previous paragraph is useful only for graphical Windows software: To summarize, you really should try Linux with Wine, or ReactOS for it. Regards, Eric PS: Even running only multiple DOS Windows in Windows is already something that does need the GUI of Windows, too. But you can work with DOS task swappers, as TriDOS :-) They swap between different (full screen) DOS sessions. This is not related to how many bits your Windows has. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
My thought is: who shall do the development? There is no one around that would spend the time to develop this. - Original Message - From: Antony Gordon cuzint...@gmail.com To: Technical discussion and questions for FreeDOS developers. freedos-devel@lists.sourceforge.net Sent: Thursday, May 28, 2015 10:47 PM Subject: [Freedos-devel] 32-bit FreeDOS I was re-reading some emails and I think I have an idea of how this would work. The goal is existing compatibility so that older DOS applications will run. Obviously, moving to 32-bit will eliminate most of the older processors, HOWEVER. by implementing a Windows 9x like model and build a 32-bit kernel to supplant the 16-bit kernel, we can then spawn 16-bit VM under a 32-bit kernel to run each 16-bit application, as well as develop 32-bit applications. The important pieces I believe that need to be figured out is the VMM (Virtual Machine Manager) and the DOS Extender. I only suggest Windows 9x because it was still able to utilize real mode DOS drivers. Thoughts? -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Here’s one possibility: 1. Start FreeDOS (16-bit mode) 2. Start FreeDOS-32 via a separate executable (it would only be installed if it detected a 32-bit capable processor), perhaps call it FD32. It would switch to protected mode and spawn a protected mode shell. The other possibility During the install, determine if the computer can support 32-bit instruction set If so, install FreeDOS and install the FreeDOS 32-bit components (provide an option to only run the 16-bit OS) FreeDOS 32 starts automatically by running the initial 16-bit environment, then spawning the 32-bit environment to take over. All existing drivers developed for FD16 would work. If we use the Windows SDK to clean build the 32-bit environment, then perhaps we can use Win9x drivers (if they are even still available). Otherwise, we’d have to clean room Win NT to implement a 32-bit OS and ReactOS is still in alpha... On May 28, 2015, at 4:58 PM, Mercury Thirteen mercury0x0...@gmail.com wrote: Agreed, that was my exact line of thinking. However, the folks here seem to have come to the conclusion that FreeDOS will not evolve into the 32-bit realm. On Thu, May 28, 2015 at 4:47 PM, Antony Gordon cuzint...@gmail.com mailto:cuzint...@gmail.com wrote: I was re-reading some emails and I think I have an idea of how this would work. The goal is existing compatibility so that older DOS applications will run. Obviously, moving to 32-bit will eliminate most of the older processors, HOWEVER. by implementing a Windows 9x like model and build a 32-bit kernel to supplant the 16-bit kernel, we can then spawn 16-bit VM under a 32-bit kernel to run each 16-bit application, as well as develop 32-bit applications. The important pieces I believe that need to be figured out is the VMM (Virtual Machine Manager) and the DOS Extender. I only suggest Windows 9x because it was still able to utilize real mode DOS drivers. Thoughts? -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net mailto:Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
On Thu, 28 May 2015, Antony Gordon wrote: Here’s one possibility: 1. Start FreeDOS (16-bit mode) 2. Start FreeDOS-32 via a separate executable (it would only be installed if it detected a 32-bit capable processor), perhaps call it FD32. It would switch to protected mode and spawn a protected mode shell. The other possibility During the install, determine if the computer can support 32-bit instruction set If so, install FreeDOS and install the FreeDOS 32-bit components (provide an option to only run the 16-bit OS) FreeDOS 32 starts automatically by running the initial 16-bit environment, then spawning the 32-bit environment to take over. All existing drivers developed for FD16 would work. If we use the Windows SDK to clean build the 32-bit environment, then perhaps we can use Win9x drivers (if they are even still available). Otherwise, we’d have to clean room Win NT to implement a 32-bit OS and ReactOS is still in alpha... Now THAT is starting to sound like an idea. -uso.-- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Agreed, that was my exact line of thinking. However, the folks here seem to have come to the conclusion that FreeDOS will not evolve into the 32-bit realm. On Thu, May 28, 2015 at 4:47 PM, Antony Gordon cuzint...@gmail.com wrote: I was re-reading some emails and I think I have an idea of how this would work. The goal is existing compatibility so that older DOS applications will run. Obviously, moving to 32-bit will eliminate most of the older processors, HOWEVER. by implementing a Windows 9x like model and build a 32-bit kernel to supplant the 16-bit kernel, we can then spawn 16-bit VM under a 32-bit kernel to run each 16-bit application, as well as develop 32-bit applications. The important pieces I believe that need to be figured out is the VMM (Virtual Machine Manager) and the DOS Extender. I only suggest Windows 9x because it was still able to utilize real mode DOS drivers. Thoughts? -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
Hi :-) 1. Start FreeDOS (16-bit mode) 2. Start FreeDOS-32 via a separate executable (it would only be installed if it detected a 32-bit capable processor), perhaps call it FD32. It would switch to protected mode and spawn a protected mode shell. http://freedos-32.sourceforge.net/ already exists. No news since 2011. FD32 runs more parts in 32-bit, but the advantages compared to using a classic DOS together with a DPMI compatible DOS extender are minimal. The other possibility During the install, determine if the computer can support 32-bit instruction set If so, install FreeDOS and install the FreeDOS 32-bit components (provide an option to only run the 16-bit OS) FreeDOS 32 starts automatically by running the initial 16-bit environment, then spawning the 32-bit environment to take over. We once pondered this as part of the ISO boot process. But because it is almost impossible to boot from CD on 8086 or 286 computers, we dropped the idea. Instead, just take a floppy with a special 16 bit, 8086 compatible version of DOS if you have such old hardware. The ISO simply assumes that you have 386 or newer hardware anyway. Interestingly, 8086 or PC-XT compatible FreeDOS floppy distros are actively discussed here and even updated at this very moment :-) All existing drivers developed for FD16 would work. If we use the Windows SDK to clean build the 32-bit environment, then perhaps we can use Win9x drivers (if they are even still available). You cannot use Win9x drivers for DOS software. Also, you cannot use Windows for Workgroups 3.11 in 386 enhanced mode and expect it to behave well: It will use built-in 32 bit disk and FAT drivers which do not work well at all with modern things like FAT32, LBA, SATA. You can disable those drivers, but running WfW 3.11 in that mode is like running Win9x in safe mode: A lot of comfort gets lost. If you want to enjoy Windows 3 in FreeDOS, use Windows 3.0 or 3.1 and use standard mode, not WfW 3.11 - even 386enh mode of 3.0 / 3.1 is very fragile as all your drivers have to cooperate and let Windows take over as the boss of your protected mode infrastructure, locking the DOS kernel into a vm86 bubble with a task switching wrapper around it. FreeDOS tries to support that in newer kernels, but this stays really hard to do well because basically Microsoft Windows is only skilled in making bubbles around Microsoft DOS, so we can only try to be very similar in the parts to which the 386enh bubble sticks. Otherwise, we’d have to clean room Win NT to implement a 32-bit OS and ReactOS is still in alpha... If you want to use 32 bit Windows programs (beyond Win32s for 3.x), you do not have the option to use DOS for that. You must use either ReactOS or Linux with Wine or a closed source OS like OS/2 or actual Microsoft Windows. In some cases, Japheth's HX / HXRT for DOS will be able to run really lightweight Windows programs in DOS, of course only one at a time and only in full screen mode. However, the folks here seem to have come to the conclusion that FreeDOS will not evolve into the 32-bit realm. DOS extenders already have allowed DOS programs to live happily in the 32-bit realm since the 1990s :-) Next question is what about the 64-bit realm? Answer is that DOS extenders for that are at an extremely experimental stage and almost no programs use those yet. But at least you can enjoy all your 1990 DOS games and similar and they can enjoy using between 2 GB and 4 GB of those 64 Gigabytes of RAM that your newest game PC has ;-) Of course the games still only use one of your 16 CPU cores, but hey, they were made for 0.1 GHz! Cheers, Eric :-) The goal is existing compatibility so that older DOS applications will run. Obviously, moving to 32-bit will eliminate most of the older processors, HOWEVER. by implementing a Windows 9x like model and build a 32-bit kernel to supplant the 16-bit kernel, we can then spawn 16-bit VM under a 32-bit kernel to run each 16-bit application, as well as develop 32-bit applications. The important pieces I believe that need to be figured out is the VMM (Virtual Machine Manager) and the DOS Extender. I only suggest Windows 9x because it was still able to utilize real mode DOS drivers. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit FreeDOS
On Friday, May 29, 2015, Eric Auer wrote: FD32 runs more parts in 32-bit, but the advantages compared to using a classic DOS together with a DPMI compatible DOS extender are minimal. Exactly. -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
