Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
How is using the Virtual 8086 mode any different than what OS/2 2.x provided? It too ran 16 bit DOS and DOS applications in Virtual 8086 mode, making OS/2 serve as the supervisor layer. The advantage would be that you would be able to run several DOS programs on a single machine at once. Each DOS machine in basically its own isolated sandbox, which is what the Virtual 8086 mode does. And for that you'd have to implement something that serves as a supervisor - a full OS that manages the memory, CPU, and I/O devices and arbitrates between the different Virtual DOS Machines. Am I interpreting what I am reading correctly? If you want to run multiple virtual DOS machines at the same time use an existing solution that already has the Virtual 8086 mode, or even an entire virtual machine. I really can't see the advantage that you would be getting by reinventing a very big, heavy, and complex wheel. It is not as trivial task. The part about a kernel sensing the hardware it is on and being able to decide to boot in classic 16 bit mode or go full 32 bit and behave as a supervisor is technically feasible. But I don't think it's going to fit on a floppy disk. There is a reason why Ferrari's are not used for freight shipments and freight trains do not have race tracks. One size fits all is extremely naive. Just out of curiosity, who is signing up to work on a 32 bit FreeDOS derivative, whether for the $2500 Kickstarter or just for the technical challenge? Who out there with the skills to do this kind of work is actually standing up to do the work? -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New software!
Thank you! lol
I'll have to give that all a look over. :)
On Fri, Jan 2, 2015 at 6:07 PM, Rugxulo wrote:
> Hi,
>
> This might be longer than necessary, but I figured I may as well dump
> it all on ya, just to be complete!
>
> On Fri, Jan 2, 2015 at 4:09 PM, Mercury Thirteen
> wrote:
> >
> > Thanks for the links, I appreciate that but I know... pretty much
> nothing of
> > Pascal lol
>
> My only experience has been with the "easy" HLL (portable) stuff. Over
> the past few years, I tried to learn some (but not all) of the various
> Pascal-y languages and dialects. So I spent a fair bit of time toying
> with various compilers.
>
> Here's some links to tutorials, if you think that'll help, if you
> think FPC is more feasible than using OpenWatcom/C (presumably for the
> much better string support):
>
> * http://www.taoyue.com/tutorials/pascal
> * http://www.oocities.org/siliconvalley/park/3230/pas/pasles00.html
> * http://www.standardpascal.com/
> * http://en.wikipedia.org/wiki/Comparison_of_Pascal_and_C
> * http://edn.embarcadero.com/article/images/20803/TP_55_OOP_Guide.pdf
> * http://www.delphibasics.co.uk/
>
> So I'm not much help on the systems-level stuff. Plus, since most
> existing legacy TP code is compiler specific (inline asm/BASM), you
> almost definitely can't recompile Paku Paku or FD KEYB (or presumably
> CompInfo or Which or whatever) with ppcross8086.exe without heavy
> changes. (But I doubt it's impossibly hard. Inline asm is supported
> but a bit differently.)
>
> In fact, due to platform limitations, getting it to work under HX was
> a feat in itself (kludge.pas needed for compiling with smartlinking),
> so even that isn't 100% automatic. I would've (obviously?) preferred
> to have a go32-v2 (32-bit DOS) hosted version of the
> "i8086/msdos"-targeted compiler, but the very few people from FPC who
> hang out on BTTR's forum didn't even pretend to care. So I don't know
> what tests (if any) they run on the snapshots. Maybe not even tetris
> and samegame, and those were the only two official examples that I
> know were tested once before.
>
> Granted, it *does* work quite a lot, even now. But nobody had time,
> skill, energy, or interest to perfect it (yet, if ever). But doing it
> all myself sounded impossibly hard (esp. these days, too tired), so
> I've not even pretended to hack / rebuild FPC directly.
>
> I only mention it because it is quite a nice compiler and has had some
> decent work done on it in recent years (and was April 2014 SourceForge
> Project of the Month). It's certainly better than GCC or even FBC,
> esp. for 16-bit support (obviously).
>
> P.S. Do read their wiki, if actually interested. In particular, it
> does support LFNs and multiple memory models. Actually, there's only
> one "compiler" .EXE, but the separate .ZIPs have different runtimes /
> libs (since the bigger ones are of more experimental quality, plus
> probably to keep .ZIP size down).
>
> > I think I just need to clean up my code and things should be fine.
> Actually,
> > I can't even say "my code". The directory traversal routine (which is the
> > root of the problem) was part of an old public domain program I found
> years
> > ago.
> >
> > I'll get it working eventually. :)
>
> writeln('Good luck!');
>
>
> --
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
So, to summarize what I'm hearing, FreeDOS 2.0 could be made to detect the CPU on which its running and branch accordingly. If it was a 386 or better, we enter protected mode and use a V86 monitor to spawn multiple 16-bit app spaces using the chip's built-in virtualization hardware. If it's a 286 or lower, we stay in real mode and operate normally. Either way we obtain maximum speed, efficiency and power and maintain *100%* hardware and software compatibility. The user doesn't have to worry about anything or do any kind of customization, as the kernel itself would decide how to act appropriate in the proper situation. Another thing to think of, *if* this route would be taken, is that we may be the only group who could pull it off. The FreeDOS-32 project has been going for how long now? And without a single release to show for it? Meanwhile you guys here created a fully functional, bug free DOS replacement / enhancement. Amazing. I agree with Mike here - I foresee *zero* programmers stepping forth to fill this niche. Hey, if they pull it off, more power to them! I wish them no ill will. But being realistic about it... I don't see it going anywhere. Heck, I've been registered on Freelancer for awhile now. I'll take the $2500 and do it myself if they're that serious about it! lol :P On Sat, Jan 3, 2015 at 3:15 PM, Aitor Santamaría wrote: > Hello, > > 2015-01-03 19:14 GMT+01:00 Travis Siegel : > >> >> On Jan 1, 2015, at 3:46 AM, Mercury Thirteen wrote: >> >> > I too would love to see a fully modern DOS. >> >> As would I, and I believe everything mentioned in the email would be >> perfect for a 32-bit dos. I believe it can be done, and the whole give >> each program it's own virtual 86 machine is one I've wondered about for >> quite sometime. It shouldn't be difficult, and actually, I read somewhere >> that the initial version of windows did this, but of course, I can't >> confirm that, since the only version of windows 1.0 I ever had was on an xt >> where such a scheme wouldn't have worked anyhow, not to mention, I haven't >> a clue where that machine wound up at. :) >> Otherwise, each program being spawned in it's own virtual 86 machine, and >> leaving things in protected mode as much as possible makes perfect sense to >> me, and it was what I'd figured would happen to dos eventually, but it >> never did. >> > > It actually did! > This is exactly what I was trying to explain, this is the way Microsoft > took, as this is what VMM32.VXD=DOS386.EXE does (a much overpowered > EMM386.EXE). > But Microsoft didn't sell this piece of software with MS-DOS, but with > MS-Windows. > > Cheers, > Aitor > > > > > > >> >> -- >> Dive into the World of Parallel Programming! The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, is >> your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. Take a >> look and join the conversation now. http://goparallel.sourceforge.net >> ___ >> Freedos-devel mailing list >> Freedos-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freedos-devel >> > > > > -- > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > > -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Kickstarter project for FreeDOS 2.0
Hi, On Sat, Jan 3, 2015 at 11:48 AM, Travis Siegel wrote: > > Actually, opendos version 7.01 (or caldera dos depending on when you > purchased it) > did have multitasking, and it worked fairly well. The problem was, setting > it up and > getting it to run properly was a bear. I did finally accomplish it, but it > was a tough nut > to crack, and I didn't use it long, due to other issues with hardware, but it > went far > beyond msdos 5.0 task switching, and actually allowed full-blown multitasking. OpenDOS 7.01 wasn't very "open". It was short-lived, born and died in 1997. It didn't even have all the Novell fixes (AFAIK). It was non-commercial only. I had thought it was kernel and shell only, not sure. I don't think they released much more than that. (See Udo Kuhnt's EDR-DOS if curious.) DR-DOS 7.03 (from 1998) is still the latest version being sold (by a different company, since they've changed hands a lot over the years). FYI, it normally identified itself as IBM PC-DOS 6, for compatibility reasons. I'm not sure when the various multitasking parts came into play. I think DR-DOS 6 had some very limited support, but it wasn't until Novell DOS 7 that full pre-emptive multitasking came along. You could do task switching on a 286, but 386 was needed for the pre-emptive stuff. It was a very good DOS, more or less, but multitasking was not for me. I only tried it a few times. It wasn't what I'd call interesting enough. (Almost no developers ever targeted their API.) I don't think it ever allowed me to do much compiling with DJGPP in the background. That was almost the only use case I could think of. Of course, I was only using it on my (old, half-dead) P166 with 32 MB of RAM (with some eaten up by NWCACHE and TDSK), but it was still (by design) limited to like 64 MB per task, no matter what HIMEM you used. IIRC, there were hidden bits (VXDs?) inside its EMM386, which also relied on its internal DPMI server (now 32-bit since 7.02 or such). All I remember is that something in TDE's (new) keyboard driver conflicted, so I always had to temporarily disable DPMI when editing. Other than that, there wasn't much (major) improvement or advantage to using DR-DOS at all, compared to the various alternatives. It might've been better than MS-DOS, but not by too much. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Good Reading Materials
Hi, On Sat, Jan 3, 2015 at 10:18 AM, Jim Hall wrote: > > Yes, these are off-limits. > > If you download and study the MS-DOS source code, you should not contribute > code to FreeDOS afterwards. We want to avoid any suggestion that FreeDOS has > been "tainted" by this proprietary code. In fairness, (no offense, Jim!), there aren't many DOS kernel hackers in the world. So nobody is at much risk. (The closest I came in recent years to any kernel hacking was to patch / build that tiny fix for ye olde "Online Bible", which isn't saying much.) > Note that Microsoft released the > source code to an early MS-DOS (version 1, I think?) in March, 2014. But we > have consistently asked that FreeDOS developers should not download this. 1.1 and 2.0 were both released, IIRC, non-commercial only. Totally irrelevant and useless. I don't know a single reason why anybody would want to look at them (very ancient, less functionality, worse license). Do they literally do anything that FreeDOS doesn't?? Anybody know?? (Boot / run in 64 kb of RAM and from 160 kb floppy, perhaps?) > Also, DR-DOS was released as OpenDOS at one point, as Ralf says. IIRC, 1997 was the rise and fall of the "open" (DR-)DOS. AFAIK, it didn't even have all the fixes from Novell. > OpenDOS used a very strange license that basically said "you may look, but do > not > touch." You were allowed to study the source code to OpenDOS, but could not > use it in other projects, and could not modify the source code to fix bugs > or make it do something else. For this reason, OpenDOS is not really "open > source software," and I ask that FreeDOS developers do not download and > study the OpenDOS source code. I never looked at it. But I'm not a kernel hacker anyways. IIRC, they only opened the shell and kernel, nothing else. EDR-DOS of course was Udo Kuhnt's work, and he added a lot, but it was still "non-commercial only", so it's of no use at all to the free/libre crowd (indeed, not "open source" nor "free software"). I hope Udo is doing well these days. > DR-DOS has not released any source code under the name "DR-DOS." So if > anyone finds source code to DR-DOS, you should assume this is illegally > leaked and not look at it. They haven't had a proper release / update since 1998, so I don't think much else is going to happen there. Somebody still sells it, though. It was a good DOS back in the day, and it might have a few (very) minor advantages, but overall I don't see any huge need to use it (personally, even though I own it!) unless super curious or some such. Who knows, maybe somebody else has a better use case for it (and it is targeted at embedded systems these days). -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Good Reading Materials
Hi, On Sat, Jan 3, 2015 at 10:41 AM, Andy Stamp wrote: > > My wording of that was poor. I was confident that reading leaked DOS source > was bad, I wanted to make sure that the IBM XT reference manual (containing > the 5150 ROM BIOS listing) and Undocumented DOS were okay. That old BIOS is probably 100% useless on semi-modern hardware anyways. Besides, we're not reimplimenting the BIOS, so it's moot. (You should probably avoid it if you want to work on SeaBIOS or CoreBoot or whatever, as they presumably prefer "clean room" reverse engineering, similar to how others cloned the IBM BIOS back in the day.) _Undocumented DOS_ is probably fine, but I'm not a lawyer. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Trying to get TVision to work on OW
Hi, On Sat, Jan 3, 2015 at 4:38 PM, Jim Hall wrote: > > Has anyone out there gotten TVision to work using OpenWatcom C? > > http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/tvision/ > > > I haven't used TVision before, but I thought it would be good to use these > libraries in the updated installer. I'm having a lot of problems getting it > to compile. Before I got too far into the weeds, I figured I'd check if > someone else already has this working. > > > I'm using tv210s.zip Just FYI, I've never used TVision either nor studied its use. But I do know a bare minimum about its software ports (maybe). Sorry, but I heavily doubt that it would work with OpenWatcom. Most people don't use anything but GCC, usually only on Linux or FreeBSD. OW 1.8 did heavily improve C++ support, but I have no idea if that is anywhere near good enough for something like this. And you'd still have to work around the obligatory Autotools. Yeah, I'm sure you know all that. So don't get your hopes up too high for that. EDIT: A very naive Google search shows this old news: "(2005-09-19) Open Watcom support added: Now you can compile Turbo Vision using the Open Watcom. It compiles to a DLL. Lothar helped to make it possible." (I also found a a different post on a different website by him saying "DOS is supported too, but I haven't tested that.") IIRC, there were two TVision ports: one BSD-licensed, one GPL-licensed. I think the latter is what you're referring to here. http://www.sigala.it/sergio/tvision/ http://tvision.sourceforge.net/ IIRC, this was used (and still) by SETedit (and thus long-dead RHIDE). Okay, so his SETedit SourceForge page doesn't show any activity since 2012, but that's still fairly recent. (Though he seemingly abandoned the DJGPP port a long time ago [2004?], sigh.) http://setedit.sourceforge.net/ Only the C++ version of TVision was open-sourced. The Pascal one remained proprietary, so FPC and pals had to port / rewrite most of it themselves (FreeVision). http://wiki.freepascal.org/Free_Vision BTW, I think Jim Michaels (who frequents on freedos-* lists) has done some fiddling with TVision recently, so you may want to email him directly. P.S. You might do better with TxWin (LGPL, C), which does explicitly support DOS via OW: http://trac.netlabs.org/txwin/ Argh, his download link is broken. You might have to email him directly (although I also seem to have a local .ZIP copy here if desperate). -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Trying to get TVision to work on OW
Has anyone out there gotten TVision to work using OpenWatcom C? http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/tvision/ I haven't used TVision before, but I thought it would be good to use these libraries in the updated installer. I'm having a lot of problems getting it to compile. Before I got too far into the weeds, I figured I'd check if someone else already has this working. I'm using tv210s.zip -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
Hello, 2015-01-03 19:14 GMT+01:00 Travis Siegel : > > On Jan 1, 2015, at 3:46 AM, Mercury Thirteen wrote: > > > I too would love to see a fully modern DOS. > > As would I, and I believe everything mentioned in the email would be > perfect for a 32-bit dos. I believe it can be done, and the whole give > each program it's own virtual 86 machine is one I've wondered about for > quite sometime. It shouldn't be difficult, and actually, I read somewhere > that the initial version of windows did this, but of course, I can't > confirm that, since the only version of windows 1.0 I ever had was on an xt > where such a scheme wouldn't have worked anyhow, not to mention, I haven't > a clue where that machine wound up at. :) > Otherwise, each program being spawned in it's own virtual 86 machine, and > leaving things in protected mode as much as possible makes perfect sense to > me, and it was what I'd figured would happen to dos eventually, but it > never did. > It actually did! This is exactly what I was trying to explain, this is the way Microsoft took, as this is what VMM32.VXD=DOS386.EXE does (a much overpowered EMM386.EXE). But Microsoft didn't sell this piece of software with MS-DOS, but with MS-Windows. Cheers, Aitor > > -- > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Kickstarter project for FreeDOS 2.0
Hello, 2015-01-03 19:00 GMT+01:00 Mercury Thirteen : > As far as I have seen, DOS allocates one Program Segment Prefix and runs > an app in that segment. When you exit the program, it clears that app out > then loads the next one you run in the same segment. I don't think it would > be that hard to make it allocate an additional PSP every time a new app is > launched. Of course you have the whole hardware sharing issue, also, but > there should be some way to mitigate this issue too. Maybe an internal flag > which signifies that a certain program is using a specific resource, so > FreeDOS knows to make the other app wait until the first is finished before > allowing the request? That may cut down on the majority of conflicts. > Under 32-bit protected mode and VMM32, I/O Access and interrupts can be controled and hooked. This is exactly that the VxD does: it catches all these calls, and cares that there are no conflicts (for example, the VCOMD presumably controlls the COM port calls and interrupts among the different VM's, VKD for the keyboard, and so on). The DOS running in each VM runs without caring or noticing that is living inside a VM, so needs not even to be touched. > > Memory protection should be fairly easy to implement also, as all the > kernel would have to do is make a note of which process ID requested which > block of RAM and disallow writing into blocks owned by other processes. > This should be switchable, also, in case the user is depending on software > which *must* write into the far reaches of RAM. > Same as above. Aitor -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
Old hardware has 16 bit registers. Requiring opcodes that only 386+ systems have an using the extra registers, or assuming that registers contain 32 bits means that no 8088 class or 80286 class system will run. That is a big conflict. On Sat, Jan 3, 2015 at 10:35 AM, Travis Siegel wrote: > > On Jan 2, 2015, at 6:29 PM, Michael Brutman wrote: > > People are free to fork off and make a new project based on FreeDOS. No > > problem there. But once you break compatibility with existing > > applications, you lose a lot of your potential user base. And as soon as > > you go to 32 bits, you lose all of the early hardware. > > I'm puzzled at this. > Why does going to 32-bit mean all old hardware will be broken? > Why does it mean old 16-bit programs won't work? > Neither one of these issues are a problem if the 32-bit is handled > properly. There's no reason it can't be done. I mean, look at linux. > It's a 32-bit os, but it has been successfully compiled and run on xt class > machines. > 32-bit os does not mean no 16-bit apps, it simply means special handling > is due such apps. > 32-bit os doesn't mean no old hardware, it simply means drivers need to do > something to make the translation. > That's all. > I see no conflict. > > > > -- > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
On Sat, 3 Jan 2015, Travis Siegel wrote: > > On Jan 2, 2015, at 6:29 PM, Michael Brutman wrote: >> People are free to fork off and make a new project based on FreeDOS. No >> problem there. But once you break compatibility with existing >> applications, you lose a lot of your potential user base. And as soon as >> you go to 32 bits, you lose all of the early hardware. > > I'm puzzled at this. > Why does going to 32-bit mean all old hardware will be broken? Because old hardware exists, like my 5160, that runs DOS and is still 16-bit? Obviously you can't run a 32-bit OS on a 5160, but DOS will run just fine. All of that would be broken by moving to 32-bit. > 32-bit os doesn't mean no old hardware, it simply means drivers need to > do something to make the translation. ...And how do you expect to run this OS on a 5160? Or an AT? Systems that run DOS just fine now? You knock out probably half the audience for FreeDOS by eliminating pre-386. -uso. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
On Sat, Jan 3, 2015 at 1:33 PM, Mercury Thirteen wrote: > > We in this discussion aren't the first people to question how to > successfully meld the worlds of 32- and 16-bit code while having speed, > flexibility and compatibility. This became an issue way back in the days of > the 386, and so some smart folks have already not only already considered > the problem, but designed the solution and implemented it - right into the > Intel processor! We just have to know its intricacies and use them to our > advantage. The code of the open source DOS/32A extender and the OSDev.org > website would be great starting points for anyone who wanted to undertake > such an endeavor. > ...however, don't misconstrue my comments to mean that I'm insisting FreeDOS become 32-bit. This project is awesome as it is and you guys have already taken it way beyond Microsoft ever did, showing it the love it always deserved. Either way we go will be fine with me. :) -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
On Jan 2, 2015, at 6:29 PM, Michael Brutman wrote: > People are free to fork off and make a new project based on FreeDOS. No > problem there. But once you break compatibility with existing > applications, you lose a lot of your potential user base. And as soon as > you go to 32 bits, you lose all of the early hardware. I'm puzzled at this. Why does going to 32-bit mean all old hardware will be broken? Why does it mean old 16-bit programs won't work? Neither one of these issues are a problem if the 32-bit is handled properly. There's no reason it can't be done. I mean, look at linux. It's a 32-bit os, but it has been successfully compiled and run on xt class machines. 32-bit os does not mean no 16-bit apps, it simply means special handling is due such apps. 32-bit os doesn't mean no old hardware, it simply means drivers need to do something to make the translation. That's all. I see no conflict. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
On Sat, Jan 3, 2015 at 1:23 PM, Travis Siegel wrote: > > I think primarily, your summary hit the nail on the head, with the caveat > that if a 32-bit dos could be built that still maintained the backward > compatibility for those programs that needed it, it would *not* be a bad > thing, in fact, it'd be embraced wholeheartedly. Of course, the chances of > that are slim, but if it could be pulled off, freedos would do something no > other dos has ever managed, and that would sure be a boon. > > +1 We in this discussion aren't the first people to question how to successfully meld the worlds of 32- and 16-bit code while having speed, flexibility and compatibility. This became an issue way back in the days of the 386, and so some smart folks have already not only already considered the problem, but designed the solution and implemented it - right into the Intel processor! We just have to know its intricacies and use them to our advantage. The code of the open source DOS/32A extender and the OSDev.org website would be great starting points for anyone who wanted to undertake such an endeavor. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
On Jan 1, 2015, at 10:44 PM, Dave Pratt wrote: > Are there other benefits you see to the 32 bit DOS? A 32-bit dos would break the 640K barrier permanently for one thing. For another, multitasking would not only be possible, it would probably become the norm. I know I'm not the only one who would love to have an os that's dos compatible, has loads of memory, and could switch tasks, and still do so in less than 5 megabytes of space. (ok, probably more like 20-50 megabytes of space when all is said and done, but still) ... -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
Yes, that's exactly what I meant in my emails. Microsoft would've eventually (in my educated guesses, at least) made MS-DOS enter protected mode as early as possible (as any modern OS does) then spawned multiple apps in their own memory areas using VM86. This would basically make the kernel the V86 monitor program which managed hardware and such for the VM86 applications. It would've been super fast with protected memory and preemptive multitasking thrown in almost for free, as a gift from the x86 processor. And, since the traditional applications would be running on real hardware and not in some kind of emulator, we would still be staying true to the classic DOS platform while being suddenly able to run all kinds of binaries - e.g. MZ, NZ, LE and LX programs. Such a DOS would be quite an experience to run! :) On Sat, Jan 3, 2015 at 1:14 PM, Travis Siegel wrote: > > On Jan 1, 2015, at 3:46 AM, Mercury Thirteen wrote: > > > I too would love to see a fully modern DOS. > > As would I, and I believe everything mentioned in the email would be > perfect for a 32-bit dos. I believe it can be done, and the whole give > each program it's own virtual 86 machine is one I've wondered about for > quite sometime. It shouldn't be difficult, and actually, I read somewhere > that the initial version of windows did this, but of course, I can't > confirm that, since the only version of windows 1.0 I ever had was on an xt > where such a scheme wouldn't have worked anyhow, not to mention, I haven't > a clue where that machine wound up at. :) > Otherwise, each program being spawned in it's own virtual 86 machine, and > leaving things in protected mode as much as possible makes perfect sense to > me, and it was what I'd figured would happen to dos eventually, but it > never did. > > > > -- > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
On Jan 1, 2015, at 8:31 PM, Jim Hall wrote: > It seems clear a consensus is appearing, but I'll give folks another few > days to chime in. That will give me time to continue on website cleanup > things, anyway. :-) I think primarily, your summary hit the nail on the head, with the caveat that if a 32-bit dos could be built that still maintained the backward compatibility for those programs that needed it, it would *not* be a bad thing, in fact, it'd be embraced wholeheartedly. Of course, the chances of that are slim, but if it could be pulled off, freedos would do something no other dos has ever managed, and that would sure be a boon. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
On Jan 1, 2015, at 3:46 AM, Mercury Thirteen wrote: > I too would love to see a fully modern DOS. As would I, and I believe everything mentioned in the email would be perfect for a 32-bit dos. I believe it can be done, and the whole give each program it's own virtual 86 machine is one I've wondered about for quite sometime. It shouldn't be difficult, and actually, I read somewhere that the initial version of windows did this, but of course, I can't confirm that, since the only version of windows 1.0 I ever had was on an xt where such a scheme wouldn't have worked anyhow, not to mention, I haven't a clue where that machine wound up at. :) Otherwise, each program being spawned in it's own virtual 86 machine, and leaving things in protected mode as much as possible makes perfect sense to me, and it was what I'd figured would happen to dos eventually, but it never did. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Kickstarter project for FreeDOS 2.0
As far as I have seen, DOS allocates one Program Segment Prefix and runs an app in that segment. When you exit the program, it clears that app out then loads the next one you run in the same segment. I don't think it would be that hard to make it allocate an additional PSP every time a new app is launched. Of course you have the whole hardware sharing issue, also, but there should be some way to mitigate this issue too. Maybe an internal flag which signifies that a certain program is using a specific resource, so FreeDOS knows to make the other app wait until the first is finished before allowing the request? That may cut down on the majority of conflicts. Memory protection should be fairly easy to implement also, as all the kernel would have to do is make a note of which process ID requested which block of RAM and disallow writing into blocks owned by other processes. This should be switchable, also, in case the user is depending on software which *must* write into the far reaches of RAM. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Kickstarter project for FreeDOS 2.0
Actually, opendos version 7.01 (or caldera dos depending on when you purchased it) did have multitasking, and it worked fairly well. The problem was, setting it up and getting it to run properly was a bear. I did finally accomplish it, but it was a tough nut to crack, and I didn't use it long, due to other issues with hardware, but it went far beyond msdos 5.0 task switching, and actually allowed full-blown multitasking. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Kickstarter project for FreeDOS 2.0
Actually, if it could be rolled in, I believe the vmix32 project would be an excellent 32-bit dos multitasking solution. I ran vmix when it was version 2.67, and it not only worked, (in my case) it worked too well. I had multiple programs running, and because of the method vmix used to virtualize the output, and the fact that I use a screen reader because of being visually impaired, vmix programs were multitasking, and all programs (not just the front most one) were speaking simultaneously. That is the only reason I stopped using it. If the screen output had been virtualized better (I.E. not being sent through the dos bios routines when it wasn't the foremost program) I'd probably still be using it today. It was an excellent solution, and now that it's opensource (though nowhere near as functional as that 2.67 release was) it might be a good starting point for a 32-bit dos that is 100% dos compatible. I'm not convinced the current opensource version of vmix can do the job, but if the older 2.67 code could be brought into the open, then there might be something to base a whole compatible 32-bit system on right there. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Good Reading Materials
My wording of that was poor. I was confident that reading leaked DOS source was bad, I wanted to make sure that the IBM XT reference manual (containing the 5150 ROM BIOS listing) and Undocumented DOS were okay. On Sat, Jan 3, 2015 at 11:18 AM, Jim Hall wrote: > > >> > Obviously reading leak MS/DR-DOS source code is bad, but I want to >> > make sure. >> > >> Those are of course off-limits. (Well, a bit questionable in case of >> DR-DOS, I don't know what exactly the license said when it was briefly >> available as OpenDOS) >> >> > Yes, these are off-limits. > > If you download and study the MS-DOS source code, you should not > contribute code to FreeDOS afterwards. We want to avoid any suggestion that > FreeDOS has been "tainted" by this proprietary code. Note that Microsoft > released the source code to an early MS-DOS (version 1, I think?) in March, > 2014. But we have consistently asked that FreeDOS developers should not > download this. > > Also, DR-DOS was released as OpenDOS at one point, as Ralf says. OpenDOS > used a very strange license that basically said "you may look, but do not > touch." You were allowed to study the source code to OpenDOS, but could not > use it in other projects, and could not modify the source code to fix bugs > or make it do something else. For this reason, OpenDOS is not really "open > source software," and I ask that FreeDOS developers do not download and > study the OpenDOS source code. > > DR-DOS has not released any source code under the name "DR-DOS." So if > anyone finds source code to DR-DOS, you should assume this is illegally > leaked and not look at it. > > > Jim > > > -- > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > > -- --Andy -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
On Sat, 3 Jan 2015, Thomas Mueller wrote: > I thought of that, a 32-bit version of FreeDOS could take ideas/features > from OS/2 and eComStation. > > I saw OS/2 as like a much-enhanced 32-bit DOS. Yeah. And if I were to try to create a 32-bit DOS, it might be something like OS/2 without Presentation Manager (think, a 32-bit OS/2 1.0). -uso. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion
from Sparky4: > I think the FreeDOS 2.0 version should be a updated 16 bit kernel that can > run in real mode by default > and the freedos-32 stuff should merge with OSFree I thought of that, a 32-bit version of FreeDOS could take ideas/features from OS/2 and eComStation. I saw OS/2 as like a much-enhanced 32-bit DOS. On osfree.org, it looks like progress is minimal, like watching grass grow at the South Pole. I ran OS/2 from v1.3, the last 16-bit version, to Warp 4 with fixpack 12 when during the single-digit days of April 2001, following a crash/freeze, CHKDSK, running automatically, ran amok and trashed the hard-drive data. I was never again able to boot OS/2 even with the installation floppies. Since then, Linux, FreeBSD and NetBSD have, as far as I can see, greatly overtaken eComStation in hardware support and functionality. Even if FreeDOS-32 and OSFree could join forces, there would be a lot of catching up to do. Tom -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Good Reading Materials
> > Obviously reading leak MS/DR-DOS source code is bad, but I want to > > make sure. > > > Those are of course off-limits. (Well, a bit questionable in case of > DR-DOS, I don't know what exactly the license said when it was briefly > available as OpenDOS) > > Yes, these are off-limits. If you download and study the MS-DOS source code, you should not contribute code to FreeDOS afterwards. We want to avoid any suggestion that FreeDOS has been "tainted" by this proprietary code. Note that Microsoft released the source code to an early MS-DOS (version 1, I think?) in March, 2014. But we have consistently asked that FreeDOS developers should not download this. Also, DR-DOS was released as OpenDOS at one point, as Ralf says. OpenDOS used a very strange license that basically said "you may look, but do not touch." You were allowed to study the source code to OpenDOS, but could not use it in other projects, and could not modify the source code to fix bugs or make it do something else. For this reason, OpenDOS is not really "open source software," and I ask that FreeDOS developers do not download and study the OpenDOS source code. DR-DOS has not released any source code under the name "DR-DOS." So if anyone finds source code to DR-DOS, you should assume this is illegally leaked and not look at it. Jim -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
