Re: [Freedos-devel] TDSK related issues.
Hi Rugxulo, thanks, noticed kernel 2040 is listed on Ibiblio now as well. http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/2040/ would you be able and willing to copy the kernel's changelog as it's in CVS/SVN right now, to above directory? DOS386 and/or Christian Masloch ... http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/history.txt Thank you, that is more search engine friendly than having to browse the www CVS/SVN page on sourceforge. However, you still need to use a search engine to find the history.txt, maybe we could have a link on a more prominent place on freedos.org or on the wiki :-) Eric -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] TDSK related issues.
Op 3-8-2011 3:58, Rugxulo schreef: Well, I half expected you to e-mail me back already! Gosh I'm impatient. ;-) Anyways, I went ahead and just uploaded history.txt (why not?), so there. ;-) http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/history.txt (Note that I didn't put it in /2040/ because it's quite long and apparently goes all the way back to the beginning!) I'm at GMT+1 in the Netherlands, sleep well :p -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New FreeDOS 1.1 test ISO (#3) released
I did a test of this CD too. First I would suggest to make an El-Torito hard disk instead of using ISOLinux. DOS I feel should boot directly and not by booting a version of Linux first. I did my LifeCDs with FreeDOS just as an El-Torito hard disk with 10MB. Then I have to mention that I cannot read the menu within 5 seconds and decide what to select. After 5 seconds the menu will run automatically into the install FreeDOS on hard disk branch. And then wait forever to select the language. Therefore I would suggest to have no menu selection to be run automatically. Today, most people may use the CD to boot FreeDOS on a Windows7 PC and they do not want to install FreeDOS on the NTFS disk. When I select Use FreeDOS as LiveCD system.. and have a Flash disk inserted, the El-Torito Bootable CD-Rom driver results in the error: JemmEX: exception 0D occured. When I have no Flash disk inserted it boots ok and the prompt is on drive F: However, when I enter keyb gr I get the error: JemmEX: exception 06 occured. Further drive F: is called FD11Setup. Drive A: is FDOS11Setup. Now, when I load DOSUSB and then devload usbdisk.sys the block device driver usbdisk.sys will get the drive letter F: from FreeDOS. Apparently it does not supply the next drive letter which would be G:. I can then access the flash disk as F:, but FD11Setup is gone. The next menu option (Boot into LiveCD system) will display the message SHSUCDX could not detect any drives. When I enter keyb gr it returns bad command or file name The next menu option (Load liveCD system without drivers) will boot ok with the same flash disk inserted and the command prompt will show G: If I then enter keyb gr to get German keyboard support the keyboard driver will crash with illegal opcode. When I enter menu as instructed, FreeDOS returns bad command or file name - so it does not find the menu command. By the way this option selects option 5 on the next menu which does not show that as a valid (or documented) option. Georg -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New FreeDOS 1.1 test ISO (#3) released
... Now, when I load DOSUSB and then devload usbdisk.sys the block device driver usbdisk.sys will get the drive letter F: from FreeDOS. Apparently it does not supply the next drive letter which would be G:. I can then access the flash disk as F:, but FD11Setup is gone. If you use DEVLOAD to load your block device driver, then obviously it is DEVLOAD which assigns the drive, not DOS. And DEVLOAD's ignorance of non-block device CDS entries is a bug already discussed elsewhere. Wait for the DEVLOAD developers to release a version (3.24?) with that bug fixed. Alternatively, implement a proper regular executable (as opposed to device driver) and modify the CDS and (E)DPBs and device chain yourself as necessary. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New FreeDOS 1.1 test ISO (#3) released
Hi Georg, I did a test of this CD too. First I would suggest to make an El-Torito hard disk instead of using ISOLinux. DOS I feel should boot directly and not by booting a version of Linux first. Isolinux is not Linux. Isolinux is a boot menu which, among other things, has the ability to boot Linux. There is no Linux in there. Then I have to mention that I cannot read the menu within 5 seconds and decide what to select. After 5 seconds the menu will run automatically into the install FreeDOS on hard disk branch. That indeed is a risky default after such a short waiting time. And then wait forever to select the language. Therefore I would suggest to have no menu selection to be run automatically. Today, most people may use the CD to boot FreeDOS on a Windows7 PC and they do not want to install FreeDOS on the NTFS disk. I agree. When I select Use FreeDOS as LiveCD system.. and have a Flash disk inserted, the El-Torito Bootable CD-Rom driver results in the error: JemmEX: exception 0D occured. That is the good old general protection fault (GPF) that you also know from Windows. Maybe it would be better to have NO *emm* style driver loaded by default, as those tend to be hard for one size fits all configurations. Modern BIOSes and other hardware and firmware fail to announce reserved areas properly, *emm* enables UMBs, conflict, bang. When I have no Flash disk inserted it boots ok and the prompt is on drive F: However, when I enter keyb gr I get the error: JemmEX: exception 06 occured. So maybe some on-demand BIOS module for USB flash storage is one of those UMB conflict cases? But something else goes wrong with the keyb driver as well - again, please try if skipping JEMMEX solves both :-) Note that your BIOS typically decides about modules only at boot time. Further drive F: is called FD11Setup. Drive A: is FDOS11Setup. Now, when Eric -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New FreeDOS 1.1 test ISO (#3) released
On Aug 3, 2011 5:27 PM, c...@bttr-software.de wrote: ... Now, when I load DOSUSB and then devload usbdisk.sys the block device driver usbdisk.sys will get the drive letter F: from FreeDOS. Apparently it does not supply the next drive letter which would be G:. I can then access the flash disk as F:, but FD11Setup is gone. If you use DEVLOAD to load your block device driver, then obviously it is DEVLOAD which assigns the drive, not DOS. And DEVLOAD's ignorance of non-block device CDS entries is a bug already discussed elsewhere. Wait for the DEVLOAD developers to release a version (3.24?) with that bug fixed. Alternatively, implement a proper regular executable (as opposed to device driver) and modify the CDS and (E)DPBs and device chain yourself as necessary. -- 3.23 should be the next version unless I missed one. Anyway if Eric doesn't do it first I am working on updating devload to take used cds entries into consideration. I hope to have a test version by this weekend, my current code isn't ready for others yet. Jeremy -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New FreeDOS 1.1 test ISO (#3) released
Op 3-8-2011 23:05, Georg Potthast schreef:
I did a test of this CD too. First I would suggest to make an El-Torito hard
disk instead of using ISOLinux. DOS I feel should boot directly and not by
booting a version of Linux first. I did my LifeCDs with FreeDOS just as an
El-Torito hard disk with 10MB.
Hi Georg, thanks for your feedback, much appreciated.
You mean ELTORITO harddisk emulation instead of floppy emulation or
non-emulation mode? That could work, though your use case (your own
written shareware USB drivers) assumes a much more modern machine than
many situations FreeDOS could be used for.
Is there any driver for read-mounting harddisk images (maybe SHSUFDRV)
in a situation where you boot from a separate bootdisk, access the CD
and mount this (single-partition) harddisk image?
Then I have to mention that I cannot read the menu within 5 seconds and
decide what to select. After 5 seconds the menu will run automatically into
the install FreeDOS on hard disk branch. And then wait forever to select the
language. Therefore I would suggest to have no menu selection to be run
automatically. Today, most people may use the CD to boot FreeDOS on a
Windows7 PC and they do not want to install FreeDOS on the NTFS disk.
The idea is people select what to do in the Isolinux menu, thus skipping
any CONFIG.SYS menu. However there should be a short timeout to select
alternative options in case JEMM and the computer don't like eachother
very much.
When I select Use FreeDOS as LiveCD system.. and have a Flash disk
inserted, the El-Torito Bootable CD-Rom driver results in the error:
JemmEX: exception 0D occured.
That's new to me, I might be able to test this sometime. Also I should
upload the ISO-inside-ISO so inner ISO is loaded to system memory then
mounted by ELTORITO.SYS.
When I have no Flash disk inserted it boots ok and the prompt is on drive F:
However, when I enter keyb gr I get the error: JemmEX: exception 06
occured.
Yes KEYB or its keyboard layout files are a bit buggy, I've received
suggestions to use some older layout files, not tested that out.
Further drive F: is called FD11Setup. Drive A: is FDOS11Setup. Now, when
I load DOSUSB and then devload usbdisk.sys the block device driver
usbdisk.sys will get the drive letter F: from FreeDOS. Apparently it does
not supply the next drive letter which would be G:. I can then access the
flash disk as F:, but FD11Setup is gone.
Yes I've experienced this issue as well. A workaround is loading
SHSUFDRV (SHSUFDRV /F:F:\ISOLINUX\FDBOOT.IMG) then load your drivers.
Another workaround is unloading SHSUCDX temporary (which is rather messy
if doing so from the CD's driveletter..). A proper solution is getting
DEVLOAD fixed.
As for your drivers, I'm rather curious. Suppose I boot an USB flash
disk (2.0 interface, 2.0 port), and crappy BIOS is happy to stick to 1.1
speed. The flash disk gets assigned C:.
Next, I'd load your drivers, which
1) disable all BIOS legacy USB emulation (bye keyboard, mouse..)
2) Make contents of C: disappear below my feet and scripts can't continue.
How's this situation solved?
The next menu option (Boot into LiveCD system) will display the message
SHSUCDX could not detect any drives. When I enter keyb gr it returns
bad command or file name
If no CD found then no KEYB found either as it's not in the floppy part
but just on data part of CD.
The next menu option (Load liveCD system without drivers) will boot ok
with the same flash disk inserted and the command prompt will show G:
If I then enter keyb gr to get German keyboard support the keyboard driver
will crash with illegal opcode.
Same KEYB issue, but it's intriguing that in this case everything loads
properly, while JEMM refuses (you could try JEMMEX LOAD from commandline
and see if errors encountered)
When I enter menu as instructed, FreeDOS returns bad command or file
name - so it does not find the menu command.
Hm MENU should be an ALIAS to the \SETUP.BAT , type ALIAS. I'll check if
this still works as intended.
By the way this option selects option 5 on the next menu which does not show
that as a valid (or documented) option.
Maybe ISOLINUX.CFG has a {FD=5?SOMETHING} string, or FDCONFIG.SYS. I'm
not sure anymore.
Anyway, I like the ISOLINUX menu solution as it allows to select/run
FDISK pretty fast without going through the mess of CD drivers.
Another big benefit is freeing the CD drive, as well as having writeable
space on A:.
Your harddisk image suggestion is an interesting option, I'll look into
it through both direct emulation and through isolinux/memdisk emulation.
ofcourse it will show up as C:, pushing real harddisk back to D:.
http://bootcd.narod.ru/images_e.htm also shows some interesting floppy
images (thus not ruining harddisk driveletter).
--
BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend
Re: [Freedos-devel] BWBASIC 2.50 .EXE for FreeDOS (was: Re: EXE2BIN)
On Wed, 3 Aug 2011, Rugxulo wrote: BTW, Steve, didn't you write your own BASIC somewhere? It was (is?) on SourceForge, but I never tried it. I started to. zD and I couldn't figure out how we were going to handle variables, so it didn't get off the ground. Wouldn't have been very GW-compatible anyway, which would be key to a BASIC interpreter running on DOS :P -uso. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] {Spam?} Re: New FreeDOS 1.1 test ISO (#3) released
Op 3-8-2011 23:41, Bernd Blaauw schreef: As for your drivers, I'm rather curious. Suppose I boot an USB flash disk (2.0 interface, 2.0 port), and crappy BIOS is happy to stick to 1.1 speed. The flash disk gets assigned C:. Next, I'd load your drivers, which 1) disable all BIOS legacy USB emulation (bye keyboard, mouse..) 2) Make contents of C: disappear below my feet and scripts can't continue. How's this situation solved? Just wanted to add to the above by saying it would be awesome if a semi-full USB stack would exist. Basicly: recognise USB equipment whenever not booting from it. So a simple old floppy or IDE/SATA CD drive granting access to everything. That means: * general USB driver * mass storage controller driver, preferably offering ASPI as well * disk driver, preferably offering ASPI as well (and int13?), for harddisks and USB flash storage. * floppy driver for USB floppies * CD-driver (chaining into ASPI I guess, just like SCSI CD drives did in the past for SCSI controllers). Again ASPI would be nice, enabling CD writing (though flash disks seem easier nowadays!) * Driver for Keyboard (after all you're killing BIOS legacy emulation due to loading your driver) * Driver for Mouse (same). Installing FreeDOS from USB disk, or installing from CD onto USB disk, would be awesome. After all, computers are turning into single-disk fully NTFS-partitioned systems. As an alternative I could try loading SHSURDRV. A 3GB RAMDISK acting as drive C: should work fine. I'd wish C: wouldn't be assigned to USB drives anyway, but guess DOS is depending on BIOS USB harddisk emulation anyway so we're out of luck. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New FreeDOS 1.1 test ISO (#3) released
Op 3-8-2011 23:05, Georg Potthast schreef: I did a test of this CD too. First I would suggest to make an El-Torito hard disk instead of using ISOLinux. DOS I feel should boot directly and not by booting a version of Linux first. I did my LifeCDs with FreeDOS just as an El-Torito hard disk with 10MB. I wonder if IsoHybrid disks would work. Those are loadable (by MEMDISK) as either ISO or Harddisk image. Not sure if CD drivers, ISO mounters etc will like this either. I should probably make a very flexible FreeDOS CD update batchfile right? * single layer ( 1 ISO) or shell (ISO inside Isolinux) * direct emulation - floppy image (read-only thus, CDROM required as long as emulated A:) - HDD image (same, but then C:) * non-emulation mode - grub - isolinux - nothing (smallest) - custom (memtest+, iPXE) - memdisk (ramdisk) - floppy - HDD - ISO - Isohybrid Deciding what should serve as floppy image source is interesting as well. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New FreeDOS 1.1 test ISO (#3) released
That is the good old general protection fault (GPF) that you also know from Windows. Maybe it would be better to have NO *emm* style driver loaded by default, as those tend to be hard for one size fits all configurations. Modern BIOSes and other hardware and firmware fail to announce reserved areas properly, *emm* enables UMBs, conflict, bang. ... So maybe some on-demand BIOS module for USB flash storage is one of those UMB conflict cases? But something else goes wrong with the keyb driver as well - again, please try if skipping JEMMEX solves both :-) Note that your BIOS typically decides about modules only at boot time. This doesn't sound like the EMM is at fault here; it just happens to catch GPF and UD exceptions to display a more informative message. Try using an alternative keyboard layout mapper. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New FreeDOS 1.1 test ISO (#3) released
3.23 should be the next version unless I missed one. Right. Messed that one up. I hope to have a test version by this weekend, my current code isn't ready for others yet. Looking forward to that. Regards, Christian -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New FreeDOS 1.1 test ISO (#3) released
earlier in the thread, people said it is hard to find out which drive letters are used in a fool-proof way... Where? In any case, it shouldn't be too hard. There might be some difficult corner cases, but there's implementations of CDS scanning available which do work well enough, for example, SHSUCDX's. Regards, Christian -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New FreeDOS 1.1 test ISO (#3) released
Op 4-8-2011 0:46, c...@bttr-software.de schreef: In any case, it shouldn't be too hard. There might be some difficult corner cases, but there's implementations of CDS scanning available which do work well enough, for example, SHSUCDX's. Nice challenge to test against SHSUCDX, MSCDEX, SUBST and possibly MS-CLIENT (NDIS/SMB TCP/IP stack). Blockdevices seem to have a \NUL device associated for each drive. Maybe TRUENAME would be of any use. Interesting to compare TRUENAME X: between SHSUCDX and MSCDEX :) -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] {Spam?} Re: New FreeDOS 1.1 test ISO (#3)released
Just wanted to add to the above by saying it would be awesome if a semi-full USB stack would exist. Basicly: recognise USB equipment whenever not booting from it. The problem generally preventing drivers from doing that is that, first, taking over the controllers disables any BIOS compatibility handlers, and second, you can't even reliable find out which devices are/were handled by these BIOS USB handlers because no BIOS interfaces for that are known/exist. I'd wish C: wouldn't be assigned to USB drives anyway, but guess DOS is depending on BIOS USB harddisk emulation anyway so we're out of luck. It's trivial to change DOS drive assignments in software (and there's already utilities available to do just that), and even Int13 unit numbers can be adjusted or exchanged by installing a resident handler. Rambling ahead. So a program could be written which would determine what drive DOS was booted from, and which would then make that drive disappear (or move it elsewhere). Afterwards, it could move all following drives down to fill the gap. For example, if it detected DOS was booted from drive C, it could move that drive elsewhere and then move drive D (if it exists) to drive C, E to D, and so on. Similarly, if DOS was booted from drive A, then it could move the drive currently accessed as B to A. A similar method could be utilized to change the Int13 disk unit assignment. This program could then be utilized in CONFIG.SYS or AUTOEXEC.BAT of a file system booted off a USB drive or as image from a CD, to correct the drive letter and disk unit assignments. In the case the USB drive or whatever wasn't booted from (but still is made to appear as unit 80h / drive C because of how the BIOS handles it) then the program would need to detect such drives somehow, or be instructed by the user on which drives to move. Regards, Christian -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] {Spam?} Re: New FreeDOS 1.1 test ISO (#3)released
Op 4-8-2011 1:00, c...@bttr-software.de schreef: So a program could be written which would determine what drive DOS was booted from, and which would then make that drive disappear (or move it elsewhere). Afterwards, it could move all following drives down to fill the gap. For example, if it detected DOS was booted from drive C, it could move that drive elsewhere and then move drive D (if it exists) to drive C, E to D, and so on. Similarly, if DOS was booted from drive A, then it could move the drive currently accessed as B to A. A similar method could be utilized to change the Int13 disk unit assignment. This program could then be utilized in CONFIG.SYS or AUTOEXEC.BAT of a file system booted off a USB drive or as image from a CD, to correct the drive letter and disk unit assignments. In the case the USB drive or whatever wasn't booted from (but still is made to appear as unit 80h / drive C because of how the BIOS handles it) then the program would need to detect such drives somehow, or be instructed by the user on which drives to move. http://www.bttr-software.de/products/drvexch/ I guess, written by you or one of the other BTTR regulars? :) I think it has a safeguard against C: though due to often-valid assumption that people actually boot from C: Perhaps Robert Riebisch knows more about the program as he hosts it. Couldn't find a specific author. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New FreeDOS 1.1 test ISO (#3) released
Blockdevices seem to have a \NUL device associated for each drive. I think it's a shortcoming of the redirector interface or implementation if/when/that character devices do not show up in redirected directories. Function 2F.1223 appears to be intended to allow the redirector to detect character device names, to handle them in the same way the block device file system handler does. Maybe TRUENAME would be of any use. Interesting to compare TRUENAME X: between SHSUCDX and MSCDEX :) I don't see how fiddling with character device names or TRUENAME (21.60) would be of any use here. Just loop through the CDS entries and check the flags and such. I think that's what SHSUCDX does to allocate drives, too. Regards, Christian -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] {Spam?} Re: New FreeDOS 1.1 test ISO(#3)released
http://www.bttr-software.de/products/drvexch/ I guess, written by you or one of the other BTTR regulars? :) I think it has a safeguard against C: though due to often-valid assumption that people actually boot from C: Perhaps Robert Riebisch knows more about the program as he hosts it. Couldn't find a specific author. Yes and no. It's from us, yeah. You're also right in that the specific author apparently isn't obviously stated in the documentation. In any case, open up the source code and the copyright statement shows it's from Michal. But then again, I could have told you it's not from me, because the latest version is from long before I ever heard of the project ;-) I can't find anything about such an alleged safeguard. Skimming the documentation and source code did not reveal it either. However, I'm not particularly familiar with the source code and don't regularly use DRVEXCH. In any case, DRVEXCH provides the basic operation of swapping DPBs and CDS entries, but it doesn't affect Int13 unit numbers in any way. (It is also controlled entirely by user instructions, instead of automatic detection/guessing.) There's an interesting point to be made here: DRVEXCH can't affect non-block-device (that is, redirector) CDS entries. This is the case because at least some redirectors do not use data inside the CDS entries to detect their drives; instead, they save the DOS drive number of their drives in their internal data and compare that against the drive number accessed by DOS. So while exchanging redirector CDS entries using (a modified) DRVEXCH would make DOS detect which drives are to be redirected correctly, the redirector could fail to properly detect the exchanged drives. At least SHSUCDX works in this way, and it is reasonable to expect that other redirectors do as well. I don't know whether any redirector (the original Microsoft network clients or MSCDEX?) implement drive dispatching in such a way that they do not store any DOS drive numbers in their internal data, which would be necessary to make them work with (a modified) DRVEXCH flawlessly. It might indeed even be impossible to implement redirectors in that way. DRVEXCH works well with DOS-provided CDS entries referencing DOS-provided DPBs, but it might make other block device drivers behave funny, such as Bret's USBDRIVE. If USBDRIVE internally stores DOS drive numbers (which I think it did when I reviewed it last), then basically the same problem as for the redirectors applies. In this case, it would be less critical though, because simply accessing the drives should still work (because the same block device driver and block device unit are used by DOS's file system driver). However, whenever USBDRIVE tries to access its CDS entries or DPBs, it might work with the wrong ones, and therefore, for example, fail to remove its CDS entries from the system. For both redirectors and other software keeping track of DOS drive numbers internally, the workaround is to never change these DOS drive numbers with DRVEXCH. Instead, use DRVEXCH to move away the regular DOS drives, then instruct that particular redirector/other software to install or move its drives to the freed drives. Regards, Christian -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] BWBASIC 2.50 .EXE for FreeDOS (was: Re: EXE2BIN)
At 01:59 PM 8/3/2011, Rugxulo wrote: Hi, On Tue, Jul 26, 2011 at 11:36 PM, Ralf A. Quint free...@gmx.net wrote: At 08:10 PM 7/26/2011, Steve Nickolas wrote: On Tue, 26 Jul 2011, Ralf A. Quint wrote: I would not call BWBASIC weak but including it would give users a basic scripting tool which goes beyond the DOS batch scripting. I've gone ahead and compiled BWBASIC 2.50 for FreeDOS. It's not in preferred .ZIP layout / format, but I'm honestly not sure who (if any) would care. (If needed, I can reorganize it. I'm not sure if anybody wants to mirror this, though. And yes, it includes full sources, binary, and my patch.) https://sites.google.com/site/rugxulo/bwbas250.zip?attredirects=0d=1 I didn't heavily test it, but it does seem to work. It does come with an OpenWatcom makefile, but it's for 386+ only (and apparently only Windows console). I couldn't decide a decent 32-bit solution (DOS/32A? Win32 w/ optional WDOSX STUBIT later if needed? Win32 only assuming HX?) for us, so I didn't include that. Obviously the main goal (for me) was to get 16-bit working (again). Hence I had to basically tweak my own makefile *and* spend a long time trying to pretend I understand all the 16-bit memory models (confusing!). There's probably a better way, but I'm no Japheth, so I'd have to dig in to see how he did JWasmR to really know. (I don't know what limitations are inherently present there. I've not done a lot of work with DOS memory models in C.) Anyways, the main problem was actually that somebody (Paul Edwards??) changed MAXSTRINGLEN to 4000 instead of (old 2.20's) 255, which easily overflowed something somewhere (again, confusing!). So by switching back to 255, it at least compiles and works again in 16-bit. :-)) That's exactly what I was referring to when I mentioned in a previous reply that nobody these days knows a thing about DOS anymore... :-( Don't know what AWK has to do with either BWBASIC, EXE2BIN or DEBUG, but awk is certainly not DOS and therefor should IMHO not be included in any base package... I'm still of the opinion that something should be included by default. Debug is better than nothing, but not much (by itself) That will probably have to wait until after FD 1.1 is out (2.0 ??). I still don't see how those tools are related (to awk or to each other). Each one is a tool in it's own right and for it's own purpose... Seeing that there is so little respect for the old tools that made out DOS, I am not sure if I should pick up one of my projects I had started a few years back, Anything is welcome, but some tools are more generic and useful than others. a GW-BASIC clone, looks like there won't be much interest for this at least in here. Not true! Maybe I need to dig out some email from this list from a backup tape from a years back... And BTW, I just read about this recently (since having never seen it first-hand): http://en.wikipedia.org/wiki/Donkey.bas http://www.youtube.com/watch?v=kymzTlqi1SYfeature=related Notice the (co)author!;-) And? Ok, big deal if you buy into the blabber from yapper mouth Jobs, who himself has yet to write a single line of code to begin with. He and Apple wouldn't gotten even off the ground if he would not have take advantage of the genius of Woz... But then DONKEY.BAS was never meant to be an epitome of BASIC graphics programming (which as far as the original IBM PC was concerned was limited to 320x200 pixel in 4 (fixed)colors (black, white, purple, cyan) on a CGA... I got a bit stuck at implementing routines for the floating point math in MBF (which is what BASICA/GW-BASIC and the early MS BASIC compiler use). I have some old routines for most of the single precision stuff but doing double precision with only 16bit registers at hand is a bit tough. I was thinking at times about taking a shortcut, doing the actual math using IEEE 754 of the C compiler's library and just convert from and to the MBF. But that would result in a loss of precision (MBF has one or two bits more in the mantissa but a smaller exponent/range than a IEEE 8 byte float) and that would create a possible compatibility issue... It can't be *that* impossible. Still, I'm not sure I'd be able to help much. (What language are you writing in? Assembly? C?) A mix of C and assembler. I am/was aiming for working like more than for creating a binary copy, so most interpreter logic and line/screen editor function is in C, most runtime library stuff would be linked-in assembler. I also started to maintain an a memory array which holds all those known PEEK and POKE addresses that where widely used, which isn't without a challenge either in terms of staying compatible.. And without MBF (Microsoft Binary Format), it can't work like GWBASIC. I recently read that there are routines out there that can convert this (oddball) format. One text online said check Borland's FTP (!), which of course is long gone, but that means
Re: [Freedos-devel] TDSK related issues.
On Sun, Jul 31, 2011 at 10:58 AM, Bernd Blaauw bbla...@home.nl wrote: Op 31-7-2011 16:48, Bernd Blaauw schreef: Op 31-7-2011 16:36, Tom Ehlert schreef: Bernd, assign a fix (W:) drive letter to the CD drive; Tom Experimented a little bit more: TDSK takes first driveletter after what seems to be last block device. Having harddisk (C:), then CDROM (D:) then SHSURDRV as E: makes TDSK become F:. But my intended scenario lacks XMS, so.. Having harddisk (C:), then CDROM (D:) makes TDSK become D:. TDSK isn't impressed by SUBST either. Guess it ignores installable file drivers in general. Please try http://www.fdos.org/kernel/testing/devload-3.23.zip and let me know if you experience any issues with it. I have done limited testing with it using shsucdx and tdsk and it seems to fix the issue. Note that if you install shsucdx then tdsk then uninstall shsucdx thus creating a hole in the used drives, installing a second tdsk with devload will use the drive letter of the hole. I have not tested with subst drives, but if there are issues then the flag check may need adjusted. For changes see http://fdos.svn.sourceforge.net/viewvc/fdos/trunk/source/BASE/devload/devload.asm?r1=126r2=133 Jeremy -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] BWBASIC 2.50 .EXE for FreeDOS (was: Re: EXE2BIN)
Hi, On Wed, Aug 3, 2011 at 10:48 PM, Ralf A. Quint free...@gmx.net wrote: At 01:59 PM 8/3/2011, Rugxulo wrote: Hence I had to basically tweak my own makefile *and* spend a long time trying to pretend I understand all the 16-bit memory models (confusing!). Anyways, the main problem was actually that somebody (Paul Edwards??) changed MAXSTRINGLEN to 4000 instead of (old 2.20's) 255, which easily overflowed something somewhere (again, confusing!). So by switching back to 255, it at least compiles and works again in 16-bit. :-)) That's exactly what I was referring to when I mentioned in a previous reply that nobody these days knows a thing about DOS anymore... :-( In fairness, this is my fault (or maybe you meant them too? Clearly they didn't target DOS with the makefile, at least not 16-bit). I'm not hugely familiar with C nor with the various memory models nor what is best for when, workarounds, etc. It was just a quick attempt to compile (more or less). I wanted to at least match the functionality of the old 2.20 16-bit compile Jim made for FD 1.0. In my defense, I maybe? should've just taken the easy way out and used DJGPP (which is 20+ years old, and that's as DOS as it gets, almost ...). But I didn't see a huge need or advantage. And BTW, portable C is really hard to find, esp. these days when All the world's a VAX! [32-bit / 64-bit Linux or Windows]. Don't know what AWK has to do with either BWBASIC, EXE2BIN or DEBUG, but awk is certainly not DOS and therefor should IMHO not be included in any base package... I'm still of the opinion that something should be included by default. Debug is better than nothing, but not much (by itself) That will probably have to wait until after FD 1.1 is out (2.0 ??). I still don't see how those tools are related (to awk or to each other). Each one is a tool in it's own right and for it's own purpose... FreeDOS BASE is strictly mimicking MS-DOS core stuff they included. But it lacks DOSSHELL or QBASIC, at least in BASE. So, for average scripting, while *nix has sh and awk, all we have is Debug! We don't even have BWBASIC to fully rely upon. That was my point, we're at a small disadvantage since we can't assume everyone has BWBASIC installed (whereas QBASIC was common enough to be occasionally utilized in Timo Salmi's .BAT FAQ). This was all related to my commentary on that, nothing more. a GW-BASIC clone, looks like there won't be much interest for this at least in here. Not true! Maybe I need to dig out some email from this list from a backup tape from a years back... Why? If you want to write it, write it! :-) And BTW, I just read about this recently (since having never seen it first-hand): http://en.wikipedia.org/wiki/Donkey.bas http://www.youtube.com/watch?v=kymzTlqi1SYfeature=related Notice the (co)author! ;-) And? Ok, big deal if you buy into the blabber from yapper mouth Jobs, who himself has yet to write a single line of code to begin with. He and Apple wouldn't gotten even off the ground if he would not have take advantage of the genius of Woz... I just meant, Look, even Gates wrote some real BASIC for public consumption, so it has some historic value to some people, if not (also) technical or nostalgic. But then DONKEY.BAS was never meant to be an epitome of BASIC graphics programming (which as far as the original IBM PC was concerned was limited to 320x200 pixel in 4 (fixed)colors (black, white, purple, cyan) on a CGA... No, of course not, but it's far from embarrassing. I'm sure we've all seen and written worse. It's just a (semi-) famous example that I thought was interesting, esp. since the IBM PC turns 30 next week (Aug. 12). I got a bit stuck at implementing routines for the floating point math in MBF (which is what BASICA/GW-BASIC and the early MS BASIC compiler use). I have some old routines for most of the single precision stuff but doing double precision with only 16bit registers at hand is a bit tough. I was thinking at times about taking a shortcut, doing the actual math using IEEE 754 of the C compiler's library and just convert from and to the MBF. But that would result in a loss of precision (MBF has one or two bits more in the mantissa but a smaller exponent/range than a IEEE 8 byte float) and that would create a possible compatibility issue... BWBASIC just uses doubles for everything, I think. I'm not sure much code really relies on MBF, so I wouldn't let it hold you up, IMO. But hey, knock yourself out. ;-) It can't be *that* impossible. Still, I'm not sure I'd be able to help much. (What language are you writing in? Assembly? C?) A mix of C and assembler. I am/was aiming for working like more than for creating a binary copy, so most interpreter logic and line/screen editor function is in C, most runtime library stuff would be linked-in assembler. I also started to maintain an a memory array which holds all those known PEEK and POKE addresses that where
