Re: [Freedos-user] Virtual floppy change problem with VirtualBox
I was about to post bugreport at VirtualBox bugtracker, but decided to double-check the issue first. On my system floppy images change are correctly recognized. VirtualBox 4.1.4-3.2.3 OSE OpenSUSE 12.1. On 16.05.12 19:33, Wolfgang Schechinger wrote: Dear experts, I have some floppy images I want to use with FreeDos that is running in a VM (VirtualBox). The images work fine with e.g. Windows in such an environment. However with the virtual FreeDos, disk changes are not recognized: Only the first Image that has been used after boot is show with e.g. dir, even when the image has been remove or replaced. I suppose that the problem is how to tell FreeDos that the disk has changed. Anything I could do? Thanks for your help! Wo PS The host system is Opensuse Linux 11.4 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
I was about to post bugreport at VirtualBox bugtracker, but decided to double-check the issue first. On my system floppy images change are correctly recognized. VirtualBox 4.1.4-3.2.3 OSE OpenSUSE 12.1. The issue is that VirtualBox is not posting diskette media-change status in the BIOS data table. So a cache (like UIDE/UIDE2), that needs to know when a new diskette is loaded, is NOT being notified, and the cache will continue to provide data for the PRIOR diskette! If only the VirtualBox diskette driver is used (no cache), there is no problem. To use a cache, or any subordinate diskette driver, posting the BIOS media-change status for a diskette MUST be done by VirtualBox! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Hi Tom, thanks for checking the int 13 details on VirtualBox! I was about to post bugreport at VirtualBox bugtracker, but decided to double-check the issue first. On my system floppy images change are correctly recognized. VirtualBox 4.1.4-3.2.3 OSE OpenSUSE 12.1. The issue is that VirtualBox is not posting diskette media-change status in the BIOS data table. the 'issue' is that VirtualBox clearly states 'floppy without change-line support' Then the bugreport should be a feature request: Please add floppy change-line support to VirtualBox int13/15 returns '01h floppy without change-line support int13/16 returns '06h change line active or not supported but UIDE ignores this, and relies on change line support anyway. That is a bug in UIDE then. I just checked LBACACHE: It rejects non-change-line floppy drives when asked to cache floppy (LBACACHE FLOP command line option). It does this in setup (13.15) so there is no special handling for 13.16 needed after setup imho... So you cannot cache floppy on VirtualBox with Lbacache, but at least you do not get data errors that way either. Eric -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Tom: The issue is that VirtualBox is not posting diskette media-change status in the BIOS data table. the 'issue' is that VirtualBox clearly states 'floppy without change-line support' int13/15 returns '01h floppy without change-line support int13/16 returns '06h change line active or not supported but UIDE ignores this, and relies on change line support anyway. You are WRONG, Tom!! UIDE has NEVER ignored if a diskette has change-line support! It does in fact check the BIOS data table at 0:448h for bit 0 (change line for diskette A:) or bit 4 (change line for diskette B:). If those bits are off, diskette A: or diskette B: will not be cached. My update to UIDE in adding the /E switch was simply to add a mask which is 011h without /E, 000h with /E, to mask against the bits at address 0:448h. This works fine. With /E, the mask prevents UIDE from seeing any change-line bits, so diskettes go uncached. But, if what you wrote above is correct, VirtualBox expects people to use ONLY the Int 13h requests, when determining if a diskette has change-line support. And in any event, by indicating NO such support, as you also wrote above, they make it impossible for UIDE to cache diskettes anyway! I will NOT cache a drive which cannot tell me when its media has changed, and I REFUSE to add all of the logic in UIDE that Eric notes the DOS kernel contains, to find out if a media-change has occurred using other methods! So, I shall amend my earlier post to say that VirtualBox now needs TWO changes: (A) It needs to provide media-change status for each diskette, and (B) It needs to provide a PROPER BIOS DATA TABLE, as the table bits that are seen when VirtualBox runs are INCORRECT! maybe the real issue is that noone finds the time to do a tiny bit of debugging the problem but finds a lot of time to write loong emails To which I shall add: Maybe you might have read the UIDE.ASM file before making any BASELESS and WRONG accusations about my drivers! Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Jack, the 'issue' is that VirtualBox clearly states 'floppy without change-line support' int13/15 returns '01h floppy without change-line support int13/16 returns '06h change line active or not supported but UIDE ignores this, and relies on change line support anyway. You are WRONG, Tom!! UIDE has NEVER ignored if a diskette has change-line support! It does in fact check the BIOS data table at 0:448h for bit 0 (change line for diskette A:) or bit 4 (change line for diskette B:). If those bits are off, diskette A: or diskette B: will not be cached. That is an interesting bug in VirtualBox then (wrong 40:xx data) but I support Tom here because int 13 is the front entrance to knowing if change lines are supported. Whether and how this uses the back office 40:xx data and whether this data reflects the official statement returned by int 13 is not always reliable, so asking int 13 is probably better. Also, it would be very easy for UIDE to ask int 13 instead of or in addition to 40:48 bits. I remember that DOSEMU also had no change line support back in version 1.1.3, but reported that correctly via int 13.15 and when you queried int 13.16, it always said changed... But, if what you wrote above is correct, VirtualBox expects people to use ONLY the Int 13h requests, when determining if a diskette has change-line support. And in any event, by indicating NO such support ... they make it impossible for UIDE to cache diskettes ... Indeed. But it is better to not cache than to damage data. Back in the DOSEMU 1.1 days, I had an undocumented option for LBACACHE to cache diskettes even without change line, but the user had to manually tell the cache each time when the diskette changed. I have not implemented something a la flush on boot sector read then, because all physical floppy drives that I had did support the change line and I only wanted to play with floppy caching myself, did not suggest to normal users to cache no-change-line drives... cache diskettes anyway! I will NOT cache a drive which cannot tell me when its media has changed, and I REFUSE to add all of the logic in UIDE that Eric notes the DOS kernel contains, to find out if a media-change has occurred using other methods! Given the new information from Tom, I agree that it is not worth the effort to add heuristic cache flushing, as it turned out that it IS possible to detect that no change line exists in VirtualBox. So VirtualBox users will not enjoy UIDE caching, but please do use int 13 (instead of or even better in addition to 40:48) for the detection of systems without change lines... That will protect VirtualBox users from data loss dangers! So, I shall amend my earlier post to say that VirtualBox now needs TWO changes: (A) It needs to provide media-change status for each diskette, and (B) It needs to provide a PROPER BIOS DATA TABLE, as the table bits that are seen when VirtualBox runs are INCORRECT! With change (a) it will support floppy caches better, but I consider (b) to be low priority, as the normal way to ask the BIOS about change lines is int 13. To which I shall add: Maybe you might have read the UIDE.ASM file before making any BASELESS and WRONG accusations about my drivers! The sources are circa 4000 lines long and do not even mention change line. Now that you explain how UIDE works, I was able to find this snippet: mov al,FMCMask ;Use diskette media-change bits and al,es:[MCHDWFL] ; for our number of diskettes. I_FScn: testal,001h ;Can next unit signal media-changes? jz sI_FMor ;No? CANNOT use this old clunker! where MCHDWFL equ 0048Fh. You claimed that you would check 40:48, not 40:8f, but I could not find anything in UIDE which checks 40:48 and RBIL does not give any meaning for 40:48 either. Looking at RBIL for 40:8f, I see that you can check whether drives support 80 tracks and/or multiple baud rates, but not on XT and nothing is said about change lines being flagged by this byte according to RBIL. In other words, it MAY be the case that most BIOS implementations that you have seen somehow tell something about change lines in some 40:xx byte, but it is NOT documented in RBIL and therefore you should not blame VirtualBox for not implementing this undocumented flag needed by UIDE. Eric -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Jack, The issue is that VirtualBox is not posting diskette media-change status in the BIOS data table. the 'issue' is that VirtualBox clearly states 'floppy without change-line support' int13/15 returns '01h floppy without change-line support int13/16 returns '06h change line active or not supported but UIDE ignores this, and relies on change line support anyway. You are WRONG, Tom!! UIDE has NEVER ignored if a diskette has change-line support! It does in fact check the BIOS data table at 0:448h for bit 0 (change line for diskette A:) or bit 4 (change line for diskette B:). If those bits are off, diskette A: or diskette B: will not be cached. if UIDE would check INT13/15 if change line is supported, and not cache the floppy if it's not supported everything would be fine (and /N5 not needed) I can't locate any documentation about 0:448 My update to UIDE in adding the /E switch was simply to add a mask which is 011h without /E, 000h with /E, to mask against the bits at address 0:448h. This works fine. I prefer software that works without switches. at least if it can handle the situation itself. But, if what you wrote above is correct, VirtualBox expects people to use ONLY the Int 13h requests, when determining if a diskette has change-line support. wrong. VirtualBox tells you 'change line is not supported' which part of this is difficult to understand ? And in any event, by indicating NO such support, as you also wrote above, they make it impossible for UIDE to cache diskettes anyway! exactly. hands off these floppies. maybe the real issue is that noone finds the time to do a tiny bit of debugging the problem but finds a lot of time to write loong emails To which I shall add: Maybe you might have read the UIDE.ASM file before making any BASELESS and WRONG accusations about my drivers! neither BASELESS nor WRONG. and neither accusations. just stating that they behave suboptimal. Tom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Jack-181 wrote: I will NOT cache a drive which cannot tell me when its media has changed, and I REFUSE to add all of the logic in UIDE that Eric notes the DOS kernel contains, to find out if a media-change has occurred using other methods! It's not impossible to cache floppies, Jack. You just need to do it differently than you're doing now. Probably the simplest thing you can do is an indirect collaboration with DOS. You can simply ignore the hardware change line completely, like DOS basically does. The only time DOS should try to access the boot sector (sector 0 on a floppy) is when it's trying to figure out if the media has changed or not, and you can use that as a signal to flush the cache entries for that disk. You could even go a step further and compare the cached sector 0 and the new one to see if the disk has really changed or not, and not flush the cache if it hasn't, but I'm sure that's too complicated for you to implement. I can't think of a scenario where that wouldn't solve the problem. The only potential issue I can see is if the disk has an MBR or GPT at sector 0 instead of a boot sector, but that shouldn't ever happen on a floppy. -- View this message in context: http://old.nabble.com/Virtual-floppy-change-problem-with-VirtualBox-tp33859302p33897120.html Sent from the FreeDOS - User mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
At 09:22 AM 5/23/2012, Jack wrote: You are WRONG, Tom!! Sorry, Jack, but he is not Honestly Jack, please don't explode each time someone is making a critical statement. There simply is no reason to get all personal about this... UIDE has NEVER ignored if a diskette has change-line support! It does in fact check the BIOS data table at 0:448h for bit 0 (change line for diskette A:) or bit 4 (change line for diskette B:). If those bits are off, diskette A: or diskette B: will not be cached. Beside assuming on my part that 0:0448 is a typo (and you are referring rather to 0040:0041, as used in your sources), the problem that Tom is trying to make you aware of is that you rely on the value in that location regardless of the fact if the system is indicating via BIOS interrupt INT13h/15h that the line change status is supported in the first place. And VB is apparently clearly stating when asked that it does not support the drive change line status, hence you can not rely on those bits in the BDA. Simple as that... Ralf -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
UIDE has NEVER ignored if a diskette has change-line support! It does in fact check the BIOS data table at 0:448h for bit 0 (change line for diskette A:) or bit 4 (change line for diskette B:). If those bits are off, diskette A: or diskette B: will not be cached. if UIDE would check INT13/15 if change line is supported, and not cache the floppy if it's not supported everything would be fine (and /N5 not needed). I can't locate any documentation about 0:448. Apologies, I misread my own source file (early!) this morning. UIDE and UIDE2 check 0:48Fh (not 448h) for the bits that indicate if drive A: or B: suipport a media-change line. Note the BIOS data lists at: http://www.bioscentral.com/misc/bda.htm My update to UIDE in adding the /E switch was simply to add a mask which is 011h without /E, 000h with /E, to mask against the bits at address 0:448h. This works fine. I prefer software that works without switches. at least if it can handle the situation itself. And I prefer emulators which emulate EVERYTHING, including a valid alternate way of determining change-line support! But, if what you wrote above is correct, VirtualBox expects people to use ONLY the Int 13h requests, when determining if a diskette has change-line support. wrong. VirtualBox tells you 'change line is not supported' which part of this is difficult to understand? I run V6.22 MS-DOS and V4.0 Win/NT, that I got for free in 1994 and 1998 as a software developer. I have never run any later Windows, Linux, or other C-based systems. So, I have never used VirtualBox and have NO REASON to study its documentation or sources. I rely on what others tell me about it, and before today NOBODY ever told me it positively states 'change line is not supported'. What part of THAT do you not understand?? We all cannot be experts on everything, and after all this, I in fact want NOTHING TO DO with VirtualBox, as it too-often proves itself a piece of TRASH!! And in any event, by indicating NO such support, as you also wrote above, they make it impossible for UIDE to cache diskettes anyway! exactly. hands off these floppies. Thus you joke about this being GOOD?? I think it is PATHETIC that they choose not to support diskette media-changes!! maybe the real issue is that noone finds the time to do a tiny bit of debugging the problem but finds a lot of time to write loong emails To which I shall add: Maybe you might have read the UIDE.ASM file before making any BASELESS and WRONG accusations about my drivers! neither BASELESS nor WRONG, and neither accusations. Just stating that they behave suboptimal. I say again, apologies for my referencing 0:448h this morning, when I should have referenced 0:48Fh as UIDE/UIDE2's source for the diskette media-change flags. However, suboptimal has NEVER been a problem, at-least never before VirtualBox, and UIDE/UIDE2 have worked properly using this scheme for 6 years! I also say again: I will NOT add any (large) amount of logic in UIDE merely to handle one miserable emulator program which admittedly is NOT emulating EVERYTHING! On any hardware PC system, UIDE's logic for handling diskettes and their media-changes runs fine. As I want to keep UIDE/UIDE2 simple, I shall leave things as-is. If users want to run VirtualBox, they can simply use UIDE/UIDE2 /E which specifies 'hands off those floppies' (like Tom stated above), exactly as the writers of VirtualBox intended! No diskette data errors, and everybody should be happy! Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
UIDE has NEVER ignored if a diskette has change-line support! It does in fact check the BIOS data table at 0:48Fh for bit 0 (change line for diskette A:) or bit 4 (change line for diskette B:). If those bits are off, diskette A: or diskette B: will not be cached. That is an interesting bug in VirtualBox then (wrong 40:xx data) but I support Tom here because int 13 is the front entrance to knowing if change lines are supported. Whether and how this uses the back office 40:xx data and whether this data reflects the official statement returned by int 13 is not always reliable, so asking int 13 is probably better ... Who says there is a front office and back office way of dealing with diskette media-changes?? Both seem valid to me! And if the two methods do NOT return the same info, we should CORRECT whatever program (VirtualBox, in this case) which has CAUSED such a problem, rather than requiring all previously-GOOD software to get changed! Also, it would be very easy for UIDE to ask int 13 instead of or in addition to 40:48 bits. Would take more logic, and is NOT needed on any hardware PC. As I am NOT working for VirtualBox (or I damned-well HOPE not!), let THEM make changes to address the problems they have created! But, if what you wrote above is correct, VirtualBox expects people to use ONLY the Int 13h requests, when determining if a diskette has change-line support. And in any event, by indicating NO such support ... they make it impossible for UIDE to cache diskettes ... Indeed. But it is better to not cache than to damage data. Another statement on which you can bet your [rear-end]! Given the new information from Tom, I agree that it is not worth the effort to add heuristic cache flushing, as it turned out that it IS possible to detect that no change line exists in VirtualBox. So VirtualBox users will not enjoy UIDE caching, but please do use int 13 (instead of or even better in addition to 40:48) for the detection of systems without change lines... That will protect VirtualBox users from data loss dangers! So will UIDE/UIDE2 /E, and so I shall leave my drivers as-is. To which I shall add: Maybe you might have read the UIDE.ASM file before making any BASELESS and WRONG accusations about my drivers! The sources are circa 4000 lines long and do not even mention change line. Now that you explain how UIDE works, I was able to find this snippet: mov al,FMCMask ;Use diskette media-change bits and al,es:[MCHDWFL] ; for our number of diskettes. I_FScn: testal,001h ;Can next unit signal media-changes? jz sI_FMor ;No? CANNOT use this old clunker! where MCHDWFL equ 0048Fh. You claimed that you would check 40:48, not 40:8f, but I could not find anything in UIDE which checks 40:48 and RBIL does not give any meaning for 40:48 either. Looking at RBIL for 40:8f, I see that you can check whether drives support 80 tracks and/or multiple baud rates, but not on XT and nothing is said about change lines being flagged by this byte according to RBIL. See my earlier post this morning re: the BIOS Central list of what is present in the BIOS data table at 0:48Fh.I am not surprised if change-line data is not specified for an XT as they were not available till 1985, back in the AT days! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
It's not impossible to cache floppies, Jack. You just need to do it differently than you're doing now ... Back in 1980, I told an old friend of mine about a 750K video-driver package which I had seen (written in C, of course!), and he noted, They've got GUTS, calling that a DRIVER! If I had done your type of diskette caching, your type of re-entrant driver, and all else you seem to suggest, GUESS what that would add, to the size of UIDE/UIDE2!! Since my drivers work in at-most about an 800K-byte DOS system (640K low-memory plus maybe 160K with LOL!), I will keep them SMALL, and NOT end up with any 64K-byte ATROCITY like at least one I have seen! And certainly, it is not impossible to cache floppies.Before the debut of VirtualBox, UIDE/UIDE2 had done so successfully, for years, without any complaints at all! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Jack, PLEASE, don't pull yourself up on the VirtualBox issue, it is rather a more general problem. You simply rely on the contents of the memory region rather than than properly query system via INT13. And that isn't adding much to the logic and overall size of your drivers compared to the indiscriminate reliance on the validity of the BIOS data area. Who says that properly querying system via Int 13h IS in fact proper?? Why would the BIOS include the flags at 0:48Fh if the BIOS designers did NOT intend them to be USED?? And who says it is indiscriminate, if I rely on the validity of the BIOS data?? This time, my friend, you have REALLY overstepped your bounds!! Yes, this will be more likely an issue with a(ny) virtual machine setup than with a real iron box, but then querying the DOS interrupt would rather help for example to make use of the floppy drive caching in a system with more than 2 floppy drives... UIDE/UIDE2 are designed to support a maximum of 2 diskettes. Since diskettes are no-longer offered for general sale, and people now use USB devices, etc., I see no reason to worry about 3 or more diskette systems -- very few ever existed, and they needed special software!! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Eric, Apologies, I misread my own source file (early!) this morning. UIDE and UIDE2 check 0:48Fh (not 448h) for the bits that indicate if drive A: or B: suipport a media-change line. Note the BIOS data lists at: http://www.bioscentral.com/misc/bda.htm This document states that bit 0 and 4 indicate change line support for drive A: and B: respectively, but RBIL states that the bits are about 80 track support. A safe option would be not to read 40:xx coffee grounds but instead use the well-documented int 13 interface... As I just got through noting, in another post, why would the BIOS data include diskette change-line flags if they were NOT intended to be USED?? Until someone can positively REFUTE the data offered by the BIOS Central data-table list, my opinion is that neither you nor any- one else can say Int 13h is better or 40:xx is coffee grounds! Given how UIDE/UIDE2's diskette I-O has never been a problem BUT for VirtualBox, I will keep UIDE/UIDE2 as-is. VirtualBox users now have the /E switch they can specify with my drivers, and all other users of hardware PCs and (NOT so flaky) hardware change lines will continue to run just fine! Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Given how UIDE/UIDE2's diskette I-O has never been a problem BUT for VirtualBox, I will keep UIDE/UIDE2 as-is. this is going nowhere. Jack is right and everybody else is a bloody idiot. AMEN Tom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
At 12:31 PM 5/23/2012, Jack wrote: As I just got through noting, in another post, why would the BIOS data include diskette change-line flags if they were NOT intended to be USED?? Until someone can positively REFUTE the data offered by the BIOS Central data-table list, my opinion is that neither you nor any- one else can say Int 13h is better or 40:xx is coffee grounds! There is no need to refute anything, it all comes down to the very simple fact that IBM documented the mentioned INT13h BIOS calls, while vast areas of the BIOS data segment simply are not!!! Comes to show that you are just out to prove another old engineering truth, good is the enemy of great. Just as Tom mentioned, this is all going nowhere, Du hast Recht und ich hab meine Ruhe... :-( Ralf -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
As I just got through noting, in another post, why would the BIOS data include diskette change-line flags if they were NOT intended to be USED?? Until someone can positively REFUTE the data offered by the BIOS Central data-table list, my opinion is that neither you nor any- one else can say Int 13h is better or 40:xx is coffee grounds! There is no need to refute anything, it all comes down to the very simple fact that IBM documented the mentioned INT13h BIOS calls, while vast areas of the BIOS data segment simply are not!!! And this makes using the BIOS data segment WRONG??? Comes to show that you are just out to prove another old engineering truth, good is the enemy of great. NO, you F*g S**t!! I am simply trying to show that I had to MAKE A CHOICE, when I wrote UIDE/UIDE2 in 2006. That CHOICE was NOT to use DOS/BIOS calls except where NECESSARY, and the data as noted by BIOS Central for byte 0:048Fh made it UNNECESSARY for me to issue Int 13h calls! This keeps UIDE/UIDE2 generic for use across ALL possible DOS variants, which was my MAJOR design goal! That, sir, IS A CHOICE, NOT any attempt to do as YOU seem to want to propagandize!! And I still STAND BY that choice, until you or anyone PROVE to me BIOS Central's data table is INCORRECT!! Just as Tom mentioned, this is all going nowhere, Du hast Recht und ich hab meine Ruhe... :-( Well, since you both have moved this thread to another level, I shall reply by saying only Zu BEFEHL, Herr OBERST!!! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
On Wed, 23 May 2012 14:33:00 -0400, Jack gykazequ...@earthlink.net wrote: Back in 1980, I told an old friend of mine about a 750K video-driver package which I had seen (written in C, of course!), and he noted, They've got GUTS, calling that a DRIVER! Wow, that sounds familiar. Was your friend Hal Hardenberg by any chance? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Dear STF, I have tried both. No difference. Wo How did you change the floppy? I mean, did you just choose one image file after another? Or did you *remove* the current floppy image *and then* choose the next one? -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Eric, et al: thanks for the hint! I have commented out the line in autoexec.bat which loads the UIDE.SYS cdrom driver. Now there is no problem accessing the floppy images. So maybe there is a problem with floppy change signalling versus caches - would be interesting to know whether it is sufficient to keep UIDE but run UIDE in no-cache mode, and if lbacache flop (lbacache with floppy caching enabled) would work correctly with floppy changes in virtualbox. UIDE does not include logic to ignore a diskette drive. If one or two are present, UIDE will always cache them. I never expected any- one would need (or want!) to run diskettes without caching. One can use UIDEJR instead, but UIDEJR is only a driver with no caching and thus would not perform as well. Folks really should INSIST that the writers of VirtualBox Follow the RULES! for PC hardware, instead of leaving you and I (perhaps others as well) to make changes in long-established programs just for them!! Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Hi Jack, I am so happy that there is something like FreeDos available, even for free, that I can play around with. As I usually pretty soon run into very strange challenges for (any) software - some people say, that every computer that sees me for the first time, simply crashes, simply for this fact - I do not want to expect from the developers that they care about my issues by changing their baby. If there is a way to work around the issue, that's fine for me. Of course it might be nice if the developers might take care of this issue, if there really should be a significant demand, but I am already happy with the fact that FreeDos is running on my notebook in a VirtualBox, so that I do not need to set up a dedicated machine. In the actual case, I needed to install an old prgram (GEM and an APP (!!! :) for it from several floppy disk images. So it is no problem for me to (temporally) disable the UIDE driver in order to get my stuff done. Wo Original-Nachricht Datum: Sat, 19 May 2012 14:46:56 -0700 Von: Jack gykazequ...@earthlink.net An: freedos-user@lists.sourceforge.net Betreff: Re: [Freedos-user] Virtual floppy change problem with VirtualBox Eric, et al: thanks for the hint! I have commented out the line in autoexec.bat which loads the UIDE.SYS cdrom driver. Now there is no problem accessing the floppy images. So maybe there is a problem with floppy change signalling versus caches - would be interesting to know whether it is sufficient to keep UIDE but run UIDE in no-cache mode, and if lbacache flop (lbacache with floppy caching enabled) would work correctly with floppy changes in virtualbox. UIDE does not include logic to ignore a diskette drive. If one or two are present, UIDE will always cache them. I never expected any- one would need (or want!) to run diskettes without caching. One can use UIDEJR instead, but UIDEJR is only a driver with no caching and thus would not perform as well. Folks really should INSIST that the writers of VirtualBox Follow the RULES! for PC hardware, instead of leaving you and I (perhaps others as well) to make changes in long-established programs just for them!! Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
thanks for the hint! I have commented out the line in autoexec.bat which loads the UIDE.SYS cdrom driver. Now there is no problem accessing the floppy images. So maybe there is a problem with floppy change signalling versus caches - would be interesting to know whether it is sufficient to keep UIDE but run UIDE in no-cache mode, and if lbacache flop (lbacache with floppy caching enabled) would work correctly with floppy changes in virtualbox. UIDE does not include logic to ignore a diskette drive. If one or two are present, UIDE will always cache them. I never expected any- one would need (or want!) to run diskettes without caching. One can use UIDEJR instead, but UIDEJR is only a driver with no caching and thus would not perform as well. Folks really should INSIST that the writers of VirtualBox Follow the RULES! for PC hardware, instead of leaving you and I (perhaps others as well) to make changes in long-established programs just for them!! Jack R. Ellis Hi Jack, I think the /B switch works for me. /B For UIDE only, requests a basic stand alone UltraDMA driver for disks or CD/DVD drives (no cache or diskettes). This may help in tests or diagnostics. The basic UIDE can use 128K of XMS memory and can now load in HMA space. UIDEJR will ignore /B. If I now change the floppy in the VirtualBox devices menu, this is recognized immediately in FreeDOS. So everything seems to be correct with this setting. The downside is that booting takes much longer, as the VirtualBox default chipset PIIX3 still conflicts with UIDE.SYS.The alternate chipset ICH9 works fine with UIDE.SYS but unfortunately conflicts with the ethernet controller. (1) regards Ulrich (1) http://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox_-_Chapter_8 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Wolfgang, I am so happy that there is something like FreeDos available, even for free, that I can play around with. As I usually pretty soon run into very strange challenges for (any) software - some people say, that every computer that sees me for the first time, simply crashes, simply for this fact - I do not want to expect from the developers that they care about my issues by changing their baby. If there is a way to work around the issue, that's fine for me ... Should NOT be a question of changing their baby, since if the VirtualBox people had done a PROPER job of emulation, neither they nor I would need to worry about changes. However, I have now seen that VirtualBox (A) times out if UIDE tests for SATA/IDE drives using their ICH9 logic, (B) doesn't post a diskette media change flag, and God-knows what else!! Backward compatibility must be something they never have heard of, same as Microsoft proves with each new issue of Vista or whatever it is called today! Be-advised that UIDE does not have logic to flush its cache for specific drives; it can only flush its ENTIRE cache when a diskette/CD/DVD changes, or when the user issues a CC command (clear cache) to my CC.COM program. CC issues a BIOS reset to all hard disks, useful if one wishes to verify data written to a disk. So, a workaround for you, if you must ever use multiple diskettes in VirtualBox with UIDE again, is to issue CC if your diskette must be changed. This will flush UIDE's cache and prevent the same diskette problem from occurring. Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Jack, I don't think that this is possible. In my case, the installation prgrams is asking for the disks one by one, so there is no way to issue a commandline command inbetween. Wolfgang -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Jack, when your harddrive as well as your floppies are virtual: does it make sense to cache them at all? The host operating system probably is already caching the relevant data. Wolfgang -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Wolfgang, when your harddrive as well as your floppies are virtual: does it make sense to cache them at all? The host operating system probably is already caching the relevant data. One cannot be sure the host system is caching data! You should test this, by running with UIDE (caching) and then again running with UIDEJR (no cache). If there is no speed change, your host likely is doing caching, and you may not need my drivers at all. Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
El 16/05/2012 12:03 p.m., Wolfgang Schechinger escribió: Dear experts, I have some floppy images I want to use with FreeDos that is running in a VM (VirtualBox). The images work fine with e.g. Windows in such an environment. However with the virtual FreeDos, disk changes are not recognized: Only the first Image that has been used after boot is show with e.g. dir, even when the image has been remove or replaced. I suppose that the problem is how to tell FreeDos that the disk has changed. Anything I could do? Thanks for your help! Wo PS The host system is Opensuse Linux 11.4 After, shutdown and reboot freedos, your changes appear on new sessions? Say you create a new text file, close VM and start it again. Your text file is there? On a linux host, the VM needs permissions to write on image file. -- -- +-+-+-+-+-+-+-+ Marco A. Achury http://www.achury.com.ve/eudos -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Hi Marco, thanks for your quick reply! However, your suggestion couldn't solve my problem. Meanwhile I have found that floppy access works when FreeDos is started without any drivers (Option 4). As it's just for installing some programs, I can live with that. Cheers Wo Original-Nachricht Datum: Wed, 16 May 2012 13:27:59 -0430 Von: Marco Achury marcoach...@gmail.com An: freedos-user@lists.sourceforge.net Betreff: Re: [Freedos-user] Virtual floppy change problem with VirtualBox El 16/05/2012 12:03 p.m., Wolfgang Schechinger escribió: Dear experts, I have some floppy images I want to use with FreeDos that is running in a VM (VirtualBox). The images work fine with e.g. Windows in such an environment. However with the virtual FreeDos, disk changes are not recognized: Only the first Image that has been used after boot is show with e.g. dir, even when the image has been remove or replaced. I suppose that the problem is how to tell FreeDos that the disk has changed. Anything I could do? Thanks for your help! Wo PS The host system is Opensuse Linux 11.4 After, shutdown and reboot freedos, your changes appear on new sessions? Say you create a new text file, close VM and start it again. Your text file is there? On a linux host, the VM needs permissions to write on image file. -- -- +-+-+-+-+-+-+-+ Marco A. Achury http://www.achury.com.ve/eudos -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Hi Wolfgang, I just tested this with FreeDOS 1.1 as guest and VirtualBox 4.1.14 under OS X as host and it works for me. I start FreeDOS with option 1 in the start menu. I did not load UIDE.SYS in AUTOEXEC.BAT, as I normally don't work with CDs in FreeDOS anyway and VirtualBox conflicts with the driver. See (1). I added a Virtual Floppy Drive in the settings of the VirtualBox guest by going to Storage selecting the IDE Controller and clicking the second + sign to Add floppy controller. Afterwards I added a floppy drive by clicking on the small floppy symbol in the line floppy controller. I leave the floppy drive empty. I then can choose to load a floppy image by selecting in the VirtualBox menu Devices - Floppy devices - Choose a virtual floppy disk file. Changing between floppies works for me without having to do anything in FreeDOS. I just enter A: in DOS. As soon as I change to a new image in the Devices menu FreeDOS recognizes it and shows the contents by running the dir command in A:. I don't even have to change to C: and back to A: to make FreeDOS recognize the new floppy, I just stay in A: and get the new contents by running dir. Maybe the virtual floppy image is the problem? I think there are various ways to create them with free tools. I was so lazy to create img-files with the non-free utility WinImage (2) in Windows XP. These work for me. regards Ulrich (1) http://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox_-_Chapter_8 (2) http://http://www.winimage.com Am 16.05.2012 um 18:33 schrieb Wolfgang Schechinger: Dear experts, I have some floppy images I want to use with FreeDos that is running in a VM (VirtualBox). The images work fine with e.g. Windows in such an environment. However with the virtual FreeDos, disk changes are not recognized: Only the first Image that has been used after boot is show with e.g. dir, even when the image has been remove or replaced. I suppose that the problem is how to tell FreeDos that the disk has changed. Anything I could do? Thanks for your help! Wo PS The host system is Opensuse Linux 11.4 -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Hi Ulrich, thanks for the hint! I have commented out the line in autoexec.bat which loads the UIDE.SYS cdrom driver. Now there is no problem accessing the floppy images. Best regards, Wo -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Wolfgang and Ulrich, Hi Ulrich, thanks for the hint! I have commented out the line in autoexec.bat which loads the UIDE.SYS cdrom driver. Now there is no problem accessing the floppy images. This sounds to me as if VirtualBox is NOT posting the media change bits for a floppy-disk in the BIOS, when the floppy-disk is changed. Needless to say, UIDE requires those bits! Nor is UIDE designed to use any other way of detecting a floppy-disk change (if any such way exists), since the media change bits have been part of all PC BIOS programs from about 1985 onward. I suggest you Have another LONG chat! with the creators of Virtual Box, who seem to live in their own world and seem to IGNORE a lot of pre-existing PC hardware conventions Whenever it suits them!. Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
