Re: [Freedos-devel] FreeDOS install
Hi, On Thu, Jun 4, 2015 at 6:56 PM, JAYDEN CHARBONNEAU jcharbonnea...@cpsge.org wrote: My main problem,Rugluxio,was that it wont boot my harddrive after I run the format /s command on it.My harddrive doesn't seem to like booting.Which is funny,because I had it working perfectly 2 months ago.(I installed linux on my laptop,then decided 4 days ago to reinstall FreeDOS to the harddrive via USB again). As mentioned, you may have to (carefully!!) run something like fdisk /mbr, if you haven't already. And of course you need to do sys c: d: /BOOTONLY (or similar) if there is no boot sector. And all of that assumes you have a valid (and active) FAT partition already. First, just make sure you're on the correct drive, and don't accidentally erase or corrupt anything! -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS install
Hi! I've tried everything.I ran format /s,I ran Fdisk,I've made the harddrive bootable.But when I go to boot into the harddrive,my laptop just restarts. There are various pretty technical reasons that could cause this: BIOS and DOS disagreeing about geometry when you run SYS or FORMAT versus when you boot, use of CHS geometry versus LBA mode, use of different BIOS drive numbers when using SYS versus when booting... The latter could even go as far as 00 (A) versus 80 (C), or it can be a smaller difference such as 80 versus 81 (different harddisk numbers). You can use SYS with the CONFIG option to patch kernels to disable LBA or to force the use of LBA and to enable or disable whether drive assignments are shown. With my sys-freedos.pl Perl script for Linux (requires NASM to be installed, sys-freedos-linux is the name of the zip download), you can and have to manipulate the geometry, drive number and whether LBA should be used. As this is not user friendly at all, I would only recommend this if your technical curiosity motivates you sufficiently to try various of the possible settings :-) Maybe somebody could provide you with a boot sector which displays the current drives and their properties, that would be nice for diagnostic checks instead of actual booting. Likewise, maybe some tool can be recommended to display a list of drives and properties at the time when you would normally run SYS, for comparison? Note that both the partition table (of both USB sticks and normal harddisks and SSD etc.) and information in the DOS boot sector of a partition can make statements about geometry and the latter also (optionally, I believe) about the expected BIOS drive number... I hope this helps with further investigations :-) Regards, Eric -- ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS install
I've tried everything.I ran format /s,I ran Fdisk,I've made the harddrive bootable.But when I go to boot into the harddrive,my laptop just restarts. On Fri, Jun 5, 2015 at 8:55 AM, Rugxulo rugx...@gmail.com wrote: Hi, On Thu, Jun 4, 2015 at 6:56 PM, JAYDEN CHARBONNEAU jcharbonnea...@cpsge.org wrote: My main problem,Rugluxio,was that it wont boot my harddrive after I run the format /s command on it.My harddrive doesn't seem to like booting.Which is funny,because I had it working perfectly 2 months ago.(I installed linux on my laptop,then decided 4 days ago to reinstall FreeDOS to the harddrive via USB again). As mentioned, you may have to (carefully!!) run something like fdisk /mbr, if you haven't already. And of course you need to do sys c: d: /BOOTONLY (or similar) if there is no boot sector. And all of that assumes you have a valid (and active) FAT partition already. First, just make sure you're on the correct drive, and don't accidentally erase or corrupt anything! -- ___ 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] FreeDOS Developer Studio
Eric, That mainly is because Apple is Apple ;-) In DOS, you get very far with a standard C library, good old OpenWatcom or DJGPP, in the latter case even similar enough to the Linux GCC and G++ C and C++ infrastructure to ease porting of things to DOS. As DOS does not provide GUI, networking or other fancy things as part of the operating system itself, you can use existing popular C and other libraries for that (Watt32, Wattcp, SDL, FLTK, ...) without being bound to a specific choice. The better libraries of course also come with sample code and documentation :-) Our distro could include some of the more popular libraries, giving people a nice starting point for their projects :-) That is the whole idea behind the FreeDOS Developer Studio. I know as well as anyone that there are multiple ways to do anything in DOS. Including some of the popular libraries with documentation and sample code either from the library itself or written by us would be great. In addition white papers or articles on best practices. When DOS was king, we had Peter Norton, Andrew Schulman, Jim Pyle, and a host of other great authors that provided information in books (some of which are out of print and most are hard to find) on how to do various things in DOS. I believe there are some very knowledgeable people on this list and we can recreate some of those resources in the form of bite sized articles. I consider you a great resource for example, but there are others on this list. Let’s use long file name support as an example. We have included in FreeDOS, LFNDOS to support the long file names. Since it is open source and we have the code, why not include LFN as a library in the developer studio then someone who is writing an application using long file names can reference that code as a library. I know they can download it themselves and include what they need, but I think that as an example would bring a huge benefit to FreeDOS especially given all the updates made. Regarding OpenWatcom, NASM, RBIL, Japheth's HX (and JWASM!), I agree that those are nice things to include :-) Some are rather large, but I have seen people make compressed basic OpenWatcom install files that fit on one floppy. It is always hard to get a good balance in what to include. FreeBasic and FPC etc. are not very small, but e.g. the set of pre-ported things for DJGPP is outright huge. You could even have a distro just for DJGPP. Since OpenWatcom is “open” I was thinking perhaps taking the source and branding it as FreeDOS C based on OpenWatcom, (to give credit) which is what Microsoft did initially with Lattice C via a licensing agreement. The same is true for Free Pascal (if we so desired) albeit with a different name since we can’t call it Free Pascal. I hope Rugxulo can help you getting that HX download uploaded to a place where it is easier to get than from the web archive. The licensing for it (as it relates to FreeDOS) has me wondering if it is even worth the effort. Based on what I read, it sounds good, but if GPL is a factor, we may need to consider something else. I wouldn’t want any hang ups to prevent this from moving forward. Note that RBIL already tells quite a bit about XMS and EMS, so having the spec as separate document is just for added detail. Yes RBIL covers EVERYTHING, but I think having the “official” specification lends more credence to the information we’re providing. If we find that it’s not as useful, it can be removed or referenced via a hyperlink. In particular, XMS is relatively easy to use even if you do not have a library for it. Using XMS or EMS with old (C) compilers can take some effort (memory models and low level stuff to get into the way, maybe) but to be honest, why take the effort for manual memory management at all? Simply use any protected mode aware compiler (DJGPP or a larger memory model in OpenWatcom) and DPMI and other DOS extender things will magically work for all your basic needs. Note that when you go that direction, it will mean that you have to avoid assumptions about direct raw memory access (screen buffers and such). If you do want that, you will have to take some explicit efforts, but there is some sample code on the web to help you out :-) Or just use one of the existing GUI toolkit libraries to do the work for you :-) I’m glad we’re finally getting along. :) I was worried for a minute that you weren’t going to like me. Have a wonderful day. Tony -- ___ 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] FreeDOS install
Perhaps.I know it booted to my harddrive two months ago.Why wouldn't it work now?Hm. On Fri, Jun 5, 2015 at 10:37 AM, Eric Auer e.a...@jpberlin.de wrote: Hi! I've tried everything.I ran format /s,I ran Fdisk,I've made the harddrive bootable.But when I go to boot into the harddrive,my laptop just restarts. There are various pretty technical reasons that could cause this: BIOS and DOS disagreeing about geometry when you run SYS or FORMAT versus when you boot, use of CHS geometry versus LBA mode, use of different BIOS drive numbers when using SYS versus when booting... The latter could even go as far as 00 (A) versus 80 (C), or it can be a smaller difference such as 80 versus 81 (different harddisk numbers). You can use SYS with the CONFIG option to patch kernels to disable LBA or to force the use of LBA and to enable or disable whether drive assignments are shown. With my sys-freedos.pl Perl script for Linux (requires NASM to be installed, sys-freedos-linux is the name of the zip download), you can and have to manipulate the geometry, drive number and whether LBA should be used. As this is not user friendly at all, I would only recommend this if your technical curiosity motivates you sufficiently to try various of the possible settings :-) Maybe somebody could provide you with a boot sector which displays the current drives and their properties, that would be nice for diagnostic checks instead of actual booting. Likewise, maybe some tool can be recommended to display a list of drives and properties at the time when you would normally run SYS, for comparison? Note that both the partition table (of both USB sticks and normal harddisks and SSD etc.) and information in the DOS boot sector of a partition can make statements about geometry and the latter also (optionally, I believe) about the expected BIOS drive number... I hope this helps with further investigations :-) Regards, 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
