Re: [Freedos-user] Re : Support for 4k byte sectors
I am saying that for gaining speed on modern disks, in particular flash disk ands large sector disks, you should already make a big difference with a small pooling cache and a short delay, That's true -- but I don't think either LBACACHE or UIDE actually do that. I could be wrong, but I think they are very simple write-through caches that don't delay or try to pool/combine any of the writes at all. If they did, and also added support for non-INT 13h disks, it could indeed make a HUGE difference. which is both simpler and less risky than large, long delay caches where a lot of hooks try to find out when a good moment to write is and a last safe moment to write, e.g. before reboot, before crash? or before you return to the prompt, as many users assume it is safe to switch off a DOS PC while it is idle at the prompt. Less risky, at least if the system is unstable. Actually only a little simpler, though, since any kind of delay at all, no matter how small, requires monitoring reboots and prompts. In all cases, it should be OK to shut off the system at a prompt. All caches, including SMARTDRV, must commit their write-delay caches before the DOS prompt returns. I personally have an OFF.BAT file to shut down my computers instead of using the power switch, anyway, and it makes sure everything is flushed and committed. Handling crashes is another story -- no way to handle those in any OS unless you use a journaling file system. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re : Support for 4k byte sectors
... No cache will ever compete with a RAM disk. RAM is always faster than disks with their seek/rotational latencies and their much slower transfer rates. I knew this would provoke a comment from you, Jack. The purpose of a cache is to put as much data in RAM as it can, so that the disk is accessed as little as possible. It's true that the cached data does eventually get written to disk, and that part is slow. From a speed perspective, though, a well-designed cache can be competitive with a RAM disk. The advantage of a write-delay cache is that that the writing can be done when the system is idle (a simple form of multi-tasking). The end result is that even though disk writes actually take the same amount of time they always did, the SYSTEM actually runs much faster. In my experience and opinion (and it is only an opinion), write-through caches don't provide enough speed benefit to be very helpful, and I don't use them. ... There is a REASON why Write Back caches are all so large -- they demand MANY hooks of a non-generic type into a DOS system, to handle Ctrl/Alt/DEL and other events that require a flush of sectors not-yet written to disk. Yes, write-delay caches are MUCH more complicated than write-through caches. But, they also provide MUCH more practical benefit, IMO. Even with that being said, I don't use SMARTDRV all the time. I only use it in certain situations when it provides noticeable benefit, and in those particular situations a write-through cache doesn't help. Also, FWIW, you can disable write-delay caching in SMARTDRV if you want, in which case it works sort of like UIDE or LBACACHE (except that it will also _natively_ work with non-INT 13h disks like USB and SCSI), but at the expense of requiring more memory. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re : Support for 4k byte sectors
yes you would see a problematic mismatch if you were to talk raw SCSI or CHS to a disk while being inconsistent about whether you use 512 byte or rather 4096 bytes per sector... That's precisely the problem. Depending on which DOS programs you use, some simply call DOS, some may use INT 25h/26h, some may use INT 13h, others may use raw SCSI/ASPI, and there are also other possibilities. If you could force all calls through the DOS device driver, you could eliminate any potential problems with DOS. But DOS doesn't force programs to do that, and there are certain kinds of programs (FDISK, FORMAT, SYS, CHKDSK, SCANDISK, ...) that require low-level access and can't go through the DOS Device Driver. And that doesn't even address the potential issues of using that same device on another OS or BIOS. The potential compatibility problems are just too great for me to even want to attempt this. FYI, my driver provides an INT 13h interface (and I think it's the only one that does). That allows you to use standard DOS utilities to partition and format and create bootable disks, without needing to resort (at least in some cases) to the special Windows and Linux utilities. However, when DOS mounts a partition with help of a loadable block device driver, nothing would access the raw view of the disk. In any case the kernel will not, it will only talk to the block device driver. Anything beyond that is of course evil, but so is dosfsck-ing a partition in Linux while it is mounted at the same time. It actually isn't evil in DOS to do low-level maintenance on a mounted partition. You just need to make sure you flush any buffers and caches, and re-mount if anything that DOS may care about (sector size, number of sectors, cluster size, ...) is changed. In the case of removable media (like USB and floppies), that shouldn't even require a reboot. Can you recommend any free int 13 or block device based delayed / pooled write caching software? As far as I can remember, all modern (LBA compatible, given disk sizes on current PCs) implementations of this are commercial. I don't know of any, but there's definitely a need for one. I normally don't use caches at all, but when I need one it needs to be a write-delay cache and I use MS SMARTDRV. I actually don't like SMARTDRV very much (it uses too much memory and requires a reboot to uninstall), but I have it and it works OK. I don't find write-through caches like LBACACHE and UIDE to provide enough speed benefit to be very helpful (though they might increase disk life to some degree). In addition, LBACACHE and UIDE are INT 13h caches instead of INT 21h caches (like SMARTDRV is), so they don't work with all disks (including USB and SCSI). When I really need to increase disk access speed (a big problem in some VM's), I copy my commonly-used utilities and batch files to a RAM disk. Thanks, but can you benchmark it? ;-) I've already done a simple benchmark, though I don't think it's exactly what you're looking for. It's discussed on pages 158 and 159 of USBINTRO.DOC (in the Sector Transfer Size discussion of the USBDRIVE section). Basically, the speed increases when you pool large numbers of contiguous sectors and send them at the same time. A true, valid benchmark would require all sorts of external parameter variability elimination, which I probably won't ever do. Only if you can look beyond the virtualization in a bad way... For example the same issue existed with ontrack ezdrive drivers installed in the master boot record: ... There are lots of examples of this in the past. I also remember when there were some programs that used incorrect formulas in the CHS - LBA translations that created all sorts of compatibility problems. That's why I think it's dangerous to do anything unique that no other OS or BIOS does. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re : Support for 4k byte sectors
FWIW: In my USB disk driver (USBDRIVE), here's what I've done. USBDRIVE does not try to virtualize the sector sizes as others are suggesting here as a possibility -- I figure doing that has the potential to cause as many problems as the alternative (using defective utilities/programs that are hard-coded for 512-byte sectors). USBDRIVE will only assign drive letters to disks/partitions that it believes DOS can handle properly. E.g., USBDRIVE will ignore partitions that aren't formatted properly (NTFS, HPFS, FAT32 in certain cases, etc.). Likewise, it will ignore disks with sector sizes larger than what DOS says it can handle (this particular detail is part of the easily accessible DOS List of Lists). In the source code for USBDRIVE (starting at line 289 in the latest official release of USBDRIVE.A36), I have a comment that shows you how you can modify MS-DOS and IBM-DOS to handle sector sizes larger than 512 bytes. It involves using DEBUG (or something similar) to modify the DOS kernel (MSDOS.SYS or IBMDOS.COM). I don't know if the same method will work with FreeDOS or not. With the modification, DOS itself can supposedly handle sector sizes up to 8192 bytes, which means you can read/write to the disk using standard DOS internal calls. Programs and utilities that do not let DOS do the work for them may have problems. Booting from such a device is another level of complexity, and I'm not sure which versions of DOS (if any) can boot from a disk with sector sizes larger than 512 bytes. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re : Support for 4k byte sectors
USBDRIVE does not try to virtualize the sector sizes as others are suggesting here as a possibility -- I figure doing that has the potential to cause as many problems as the alternative... Maybe you could make that configurable, so people can experiment with virtual 512 byte sectors at their own risk? Might be useful for people who want to make their disk oriented tools 4k-wrapped- to-512-sane :-) Possible, but a REALLY BAD IDEA if you ask me. The most obvious problem is that the disk will instantly become non-portable, and can't be used with other OS's or even other DOS drivers that don't virtualize the sectors. Internally, there are lots of technical issues with things like DMA and buffering that will probably cause at least as many, if not more, problems than trying to use hard-coded-512-byte programs with disks that aren't 512-bytes. There is also a significant speed and memory usage problem -- all disk transfers will need to be double-buffered (the driver will need to internally store the entire large sector and then transfer only the part that was requested). Again, possible, but NOT a good idea, IMHO. Can you send the URL of that MS DOS patching instruction? Go to my web site: http://bretjohnson.us and download the source code for the USB drivers (USBSOURC.ZIP -- the link is near the bottom of the first section). Inside the zip file is USBDRIVE.A36, and the comment that shows how to do it is around line 300. I am wondering how much it could tell us about how to patch FreeDOS but of course FreeDOS already is known to have a bit more hard coded 512 byte ish ness. On the other hand, FreeDOS sources are easily available and easy to read... :-) From what I understand, in MS-DOS and IBM-DOS, the maximum sector size is stored in only one place (part of the List of Lists). This value is adjusted while booting to match the largest sector size of any disk that the kernel finds and assigns drive letters to. In the kernel code, it always uses the value stored there in its various calculations, and never uses any hard-coded values. That's the way FreeDOS _should_ be as well, though I don't know if it actually is. Interesting. Any known side effects? Not that I know of. I've been using a 2048-byte sector size in MS-DOS for a long time now (since USBDRIVE came out), and haven't had any problems. I should point out that I don't actually have any disks with other than 512-byte sectors, so my testing is not very complete. But this trick has been around for a LONG time, and I've never seen any mentions of problems. Of course it will not help tools like FORMAT or CHKDSK unless they already are sector-size flexible. In my opinion, there's no legitimate reason for programs like FORMAT and CHKDSK to disallow non-512-byte sectors. Other sector sizes have been around since before MS-DOS was created, and MS has always stated that programs should never assume 512 bytes. I can't say this for sure, but I don't think any MS utilities ever had problems with other sector sizes. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re : Support for 4k byte sectors
maybe virtual 512 byte sectors are actually not that evil: Imagine a NORMAL 4096 byte sector based FAT32 filesystem. ... Actually they are, or at least potentially are, at least from a compatibility perspective. In the case of USB, the SCSI protocol is normally used. The sector size is not simply stored on the disk (in the BPB's). It is also stored outside the disk in the SCSI overhead that is part of the initialization process, and those can't be virtualized (there's more than one of them). The sector size that the SCSI overhead tells you and what's stored on the disk itself need to be exactly the same, or you'll likely to run into problems somewhere that will either prevent a disk from being recognized, or contaminate the data. BPB CHS geometry differs - but does a disk with 4096 byte sectors allow CHS based access at all? I hope it does not. Already answered by Bertho -- of course it does. CHS addressing and 512-byte sectors aren't synonymous. ... Other operating systems would gain performance by pooling writes to MULTIPLE sectors which makes a very noticeable difference on flash based disks such as SSD or USB flash sticks. Some DOS programs already do that, though usually only the ones that use low-level INT 13h access. I don't think DOS itself ever does. ... This is why I suggest to first grow such a file to the final size, putting all FAT writes into ONE access and then writing the file's contents in large N kB chunks. Excellent idea, especially with USB. Then I expect the side effect to be that the kernel inflates all sector-sized areas to 4096 bytes, to be prepared to handle 4096 byte sized sectors in SOME disks. For all old disks with classic 512 byte sectors, this means a lot of wasted space in RAM for each such buffer in memory. Unless I misunderstood the details, MS DOS would not adjust sizes on a per-buffer basis. That is correct -- the buffers are all the same size, big enough for the largest sector of any disk. It does indeed waste memory, especially if you set BUFFERS to a large number. If somebody was ambitious enough, they might be able to implement dynamic buffer sizes, I suppose (I don't know what the required data structures for DOS Buffers, if there are any, are supposed to look like). ... You mean you know any sort of USB storage device which has native 2048 byte sectors? I thought that for flash and large disk formats, only 4096 was popular and 512? No, I personally don't have anything except 512-byte sectors. I just did 2048 as an experiment to see if there were problems, while still keeping the size small enough that I didn't waste too much memory. So you actually do the virtual trick the other way around? As mentioned above, that only works when all relevant structures on the actually-512-byte-per-sec disk are aligned to and sized in 2 kB boundaries, not counting the global offset of the partition, though. Unless I'm misunderstanding what you're saying, it's not the other way around. If a buffer is 2048 and the sectors are only 512, the last 1536 bytes of the buffer are simply never used. There aren't any cluster alignment issues. ... if we can mount a 4096 byte per sector disk in DOS, no matter what tool and operating system formatted / fdisked it then we can already enjoy using those disks :-) Yes. But for reasons already discussed, this should not be done by virtualizing the sector size -- that is asking for problems, IMHO. ... By the way, is the 55aa boot sector thing and similar flags for fsinfo and 2nd stage boot sectors on FAT32 always at the end of the sector or rather just at the end of the first 512 bytes of the sector? Also already answered by Bertho. It's always at offset 510 in the sector, not necessarily the end of the sector (the MBR and VBR's still need to fit in 512 bytes even if the sector is larger). If the sector size is larger than 512, you can use the rest of the sector to store other things if you want, though. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] VMSMOUNT 0.5: Now with (partial) long file names su pport
This is unavoidable. When you intercept system interrupts, you only can safely uninstall when the nobody else has trapped the same interrupt or, in other words, you can only uninstall when the interrupt vector is pointing to the TSR you are trying to uninstall. This is an opportunity to jump on my AMIS soap box again, so I will. This actually IS avoidable when the involved programs (in this case, SHSUCDX, VMSMOUNT, and any other programs that may be installed after those) implement AMIS. IMO, all modern TSR's and device drivers should implement AMIS. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] VMSMOUNT 0.5: Now with (partial) long file names su pport
I'm aware of AMIS. I could implement it in vmsmount. Then you'll only have to convince the maintainers of shsucdx, doslfn and some more or less popular proprietary tsrs like ntfs4dos... :) Please, don't get me wrong. I think AMIS is a great idea, maybe just a bit too late, and I'm open to consider it for a future release if it is worth the effort. I know that not all programs, even new ones, will implement it, even if they should. However, I don't think the fact that many/most others don't do it is a valid reason for me not to do it. It's a VERY good idea, and ultimately helps the user. As far as I'm concerned, it is almost always worth the effort when it helps the user. I'm going to implement AMIS it on all of my new/updated programs, whether anybody else decides to follow suit or not. Also, FWIW, all of my new/updated programs will support DPMS and EMS (and possibly later other environments like JLM) to reduce conventional/upper memory requirements, at least where it makes sense (it doesn't necessarily make sense on VERY small TSR's that use only a couple kB of RAM). -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDos4Kids (and Kids-at-heart)
On the topic of wear leveling I would go with the DOM products, as they are designed as hard drive replacements. It's pretty easy to burn up FLASH so wear leveling is important. FWIW, they claim that FLASH has unlimited read capability, but is limited in the number of writes. So, at least theoretically, wear-leveling should only come into play when writing to disk. To extend the life of the system, you should try to do as much as you can in RAM (like using RAM disks for temporary files, etc.) and minimize writes as much as possible. This is true for regular hard drives as well. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] sys.com not executable on Windows 7 64bit
I'm retired and I fool around with lots of hardware, some of which is nothing more then a motherboard, a keyboard and a lcd. Virtually all motherboards come with a USB. Also when I have to deal with a broken disk Spinrite is great but not if you can't boot it. Some claim it will run great from a fob, but I have not been able to figure out a way to boot it on a fob. Gone are the happy days when I could key a bootloader into the console of a PDP-11, actually to read a paper tape in and boot something else :)) Spinrite has an option to create a bootable floppy but it won't work on a device it thinks is not removable and for whatever reason it thinks all fobs are not removable, haven't looked into that. I figure if I can boot freedos I should be able to turn around and run Spinrite from that. Using my USB drivers, it is possible to make a bootable USB disk or manipulate partitions just using standard DOS tools (FORMAT, FDISK, SYS, etc.). You don't necessarily need Windows or *nix to do that. The drivers still have a long ways to go before they're really good, but can be useful even in their current limited state. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] sys.com not executable on Windows 7 64bit
The USB drivers make a flash drive look like a removable hard drive, not a floppy drive (though the drivers will also work with a USB floppy drive). You can't start with a floppy image. If the BIOS will correctly boot from an external USB hard drive or flash drive, you can simply use the standard DOS tools and the disk should be directly bootable. You don't need to use a multi-stage process that involves booting another program, creating a RAMDISK and copying a floppy image, and booting from it (which is the way a lot of *nix-based software works). You can copy and delete and move files all you want to directly on the disk, without needing to manipulate an image. The problem you'll run into is that not all BIOS's work like they're supposed to, and won't boot correctly. Some will and some won't. Also, even if a flash drive comes formatted as a super-floppy (no MBR), you can re-partition it (with FDISK or Ranish Partition Manager or some other DOS utility) so that it does have an MBR if that's what you want. The drivers should work correctly whether it has an MBR or not. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] batch programming language
With some limited exceptions (like 4DOS), the expansion of batch functionality has generally been provided by external utilities, rather than being integrated into the kernel. E.g., once in awhile I use the old PC Magazine utility called STRINGS, and I know there are other similar utilities available as well. There's also REXX, which already comes with FreeDOS. It's debatable to me whether this should be an integrated function or not, since it will require more memory. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] New release of DOSUTILS package
Yes, do! I'd be curious to see it. I realize this is many weeks late, but I finally have the new version of PRTSCR ready to go. The documentation was in far worse shape than I remembered, so that's what took most of my time. It's available from my web site: http://bretjohnson.us -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Can't Install; FreeDOS 1.1 test release #2
They works when I DEVLOAD them post boot-up, but the USB flash drive steals the DVD-RW drive's letter (E:\ in my case). USBUHCI, and USBDRIVE don't work at all for me. It not only wont load my USB drives, it doesn't even find them. Strangely enough if I load them before USBASPI/NJ32DISK, my flash drive is assigned M:\ instead. Send me an e-mail (bretjohn at juno.com) and we can try to get your USB disks to work. I don't think this Forum isn't the correct place to do it, though. It may be pretty simple to fix. I'm guessing that you are simply running USBUHCIL with no options, which will only install the driver for the first USB host controller, and you may not be plugging your disks into the first one. The M:\ thing also makes sense if you are installing USBDRIVE with no options, since USBDRIVE reserves drive letters that will be used when you do plug in some disks. -- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard in some computers')
Appart from turning DISPLAY into a DOS device driver and override kernel's CON, but not only IOCTL, but also write. FWIW, you don't actually need to turn DISPLAY into a device driver in order to replace/enhance CON. You can do that with a TSR also. See my USBPRINT if you want an example of how -- it replaces the default LPT1-LPT3, adds LPT4-LPT9, and even passes calls through to the old LPTx in situations where that is needed. IMHO, TSR's have a lot of advantages over device drivers, and can still be installed in CONFIG.SYS if you actually want/need to do that (with the INSTALL= option). -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard in some computers')
Ok, sorry, that's what I meant. That you find the chain at the List of Lists, right? Yes. The first Device Driver header (NUL) is in the LoL. From there, you can follow the chain (a linked list of pointers) as far as you want, and can insert/remove new headers wherever you want. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard insome c omputers')
Most programs could already be loaded earlier in CONFIG.SYS if they were adjusted in that way, though some of the DOS structures aren't available yet in that case. That's one of the big advantages of TSR's, in my opinion. While CONFIG.SYS is being processed, DOS is not yet all there. As a result, there are certain advanced DOS support functions you can't (or at least shouldn't) try to use, because they may not actually exist yet. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Problem with USB keyboard in some computers
use the 8042 keyboard controller command 0xd2 to simulate scancode received. that's documented (again in the IBM technical reference) this will simulate a scancode all the way through interrupt handler, int15.4f, ... That is exactly what I call Method 1 does. The problem is, function D2h doesn't exist in all keyboard controllers, even modern ones. Nor is it always 100% reliable -- I have at least one computer where it is flaky (sometimes works OK and sometimes doesn't). On that particular computer, I have to use Method 3, since Method 2 doesn't work reliably, either. And, on top of that, I must load MS KEYB because the regular BIOS itself is incompatible (again, flaky) with my Method 3. I cannot use MKEYB (or FD-KEYB) on that computer even if I would want to, because they use INT 15.4F and do not actually replace the entire BIOS INT 9 handler like MS KEYB does. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Problem with USB keyboard in some computers
Returning ignore this scancode or returning the scancode untranslated would not crash anything, at most drop a key. That's true, as long as the INT 15.4F code could do that re-entrantly (i.e., not crash when it received the re-entrant request). INT 15.4F handlers are usually pretty simple, so they most (if not all) may be able to do this anyway without any special code. In general, however, TSR and device driver writers must at least be cognizant of re-entrancy issues and how to handle them, since it is nearly impossible to guarantee that re-entrancies can NEVER happen. Many programs (especially simple programs) are lucky in that they are re-entrant without the programmer ever even thinking about it. As far as I remember, power keys could be handled by the BIOS int 9 Could be, but usually aren't. Power keys are normally ignored by the BIOS, and don't do anything at all (at least on any of my computers). pause Normal processing of Pause does indeed use part of the BDA, but also involves pretty severe manipulation of the hardware. Pause processing involves issuing EOI to the PIC and resetting the keyboard controller, but not actually exiting the INT 09 code. Essentially, you are trapped inside a semi-permanent INT 09 code loop, but interrupts are enabled and processed. However, because you have never actually exited the INT 09 handler (issued the appropriate IRET), foreground operations are never resumed. The INT 09 handler must then wait for at least two more IRQ's to occur (a key press and a key release) before exiting the semi-permanent loop (BTW, all of this requires re-entrancy in the INT 09 handler). Appropriate handling of the Pause key from INT 15.4F would be problematic, though it might be possible. All of that, of course, assumes the the Pause key is not redirected in some fashion (e.g., my SCANCODE program will let you turn the Pause key, or any other key, into a type of macro key, if you want). windows / multimedia keys could just be stored in 40:xx as normal ASCII 0, scancode X function keys. Could be, but there actually is no universally accepted standard for which scancodes go with which multimedia keys -- different manufacturers do it differently. Microsoft supposedly has a standard way they do it on their keyboards, though. So, merely throwing them into the keyboard buffer (which you could also do with the power keys, BTW) probably won't do anything useful, and could actually cause problems. With my virtual keyboard programs, I leave try to leave this totally flexible, even though I know that almost no DOS programs (at least today) use any of the special keys. My programs will still type them, and let the INT 09 handler decide whether or not they are useful. I fully expect the standard definition of what keys are considered useful in DOS to change (increase) as time goes by. As mentioned earlier, my SCANCODE program can already take literally any keystroke, including the multimedia ones, and turn it into a type of macro key. Of course writing to 40:xx (after asking 15.4f) would be cleaner and easier, but as noted, MS KEYB does not follow standards here. Actually, most everybody is following the standards, including MS KEYB (I didn't think the INT 15.4F programs were following the standards, but they actually are). MS KEYB is not in defiance of the standards any more than any program that provides its own INT 09 handler is. MS KEYB merely replaces the BIOS-level INT 09 handler (which, e.g., doesn't understand anything about alternative code pages or keyboard languages, or could have compatibility problems) with an OS-level INT 09 handler. The problem is, the standards are sometimes merely precedents instead of standards, are not always coherent or complete and can be interpreted ambiguously, and as a result sometimes unintentionally conflict with each other. I personally think that the invention of INT 15.4F was a mistake, though I'm sure IBM thought it was a really good idea, at least at the time. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Problem with USB keyboard in some computers
I believe you that you tried almost everything; I still think that 0x shouldn't hurt, and CLI is even a bug Tried both of those -- didn't help. Came to a reasonable value of 200, which was far more long enough to work on any computer I had for testing, but did not take too long (and slow everything down to a crawl) when it failed. I don't think CLI is a bug, since I don't want an INT 08 interrupting me during this process (though I have tried that, too). btw: while USB keyboards are nice, USB disks are even more popular. and then 'full speed' hurts big time (OHCI/UHCI disks are almost useless). whats happening with EHCI/XHCI ? In the pipeline. Just takes a long time with all of the distractions and minimal time I can spend on it. I don't know about almost useless, but they are definitely less than optimal. Even at the minimum speeds, they are still faster and more reliable than floppies. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Problem with USB keyboard in some computers
We (well, at least I) have a severe dilemma going on here. int 15.4f is supposed to be called from the BIOS from the INT 09 handler, and NOBODY else. I've done some more research regarding this, and it is never stated anywhere that this function can ONLY be called from the INT 09 handler. That is merely an assumption on your part. As a general rule, BIOS functions are allowed to be called by any program (including IRQ handlers) at any time, and as a result must be re-entrant. Obviously, MS believes that INT 15.4F can be called from outside INT 09, based on what they've published on their web site. If INT 15.4F is not re-entrant, and the user happens to press (or release) a key on the keyboard while the MS code is in process, the computer may hang, or do something far worse, instead of rebooting. You can find various references to similar variations of this same reboot code in multiple places on the Internet. However, IBM seems to have a different perspective. They explicitly say in some of their documentation (comments in the PC/AT BIOS source code, as well as the PS/2 Technical Reference Manuals) that INT 15.4F is allowed to process the scancodes (something which up until now, I never thought was allowed). None of the documentation I've found outside of IBM actually says this, though. The reference I was referring to earlier that I mistakenly thought came from IBM actually came from somewhere else. So, based on IBM, INT 15.4F shouldn't be called from outside INT 09, not because they explicitly say so anywhere, but rather because of the potential damage that could be caused if INT 15.4F actually processes the unreal scancode. MS apparently disagrees. ** Now comes the real dilemma. RBIL states that IBM classifies INT 15.4F as required. I don't know where that statement came from (I didn't find it in any of the documentation I came across), but I do believe IBM actually stated this somewhere. The problem with this is when you have a program that provides its own INT 09 handler, and doesn't use even use the BDA to keep track of things (Windows, GEM?, GEOS?, many games, ...). If these programs call INT 15.4F as is required, and INT 15.4F actually processes the scancode (modifies the BDA, puts keystrokes in the keyboard buffer, toggles the LEDs on the keyboard, etc.) and then tells the INT 09 handler to ignore the scancode, there is a big problem. At a minimum, the BDA will be all screwed up when the program exits (if you can even find a way to exit the program, because you may not be able to use the keyboard properly). I think most (if not all) of these programs ignore INT 15.4F for this reason, though technically (at least according to RBIL) they are in violation of the standards. The other issue with an INT 15.4F handler, of course, is that it won't directly work with the BIOS on PC's and early-model XT's and AT's. Most people don't care about that kind of compatibility any more, though, and FD-KEYB has an option that fixes that problem. no single DOS or BIOS call is 'fully' reentrant Actually, all DOS and BIOS functions must be re-entrant in a general sense, though you're correct that they don't necessarily need to be fully re-entrant. Any resident function (BIOS, DOS, or anything else) that can potentially be called from both inside and outside an IRQ handler (and there are very few that can't be), or anything that can conceivably be called recursively (INT 16h calling INT 10h calling INT 16h), must be able to handle the possibility of re-entrancy. Common ways of handling re-entrancy issues are to return an I'm busy -- go away error (like the InDOS Flag), provide some sort of context-switching mechanism (like the DOS Swappable Data Area), queue up the requests (which requires a stack and call-back mechanism of some sort), and full, unadulterated re-entrancy (where the old process is temporarily halted, the new one is handled, and then the old one is resumed). The INT 14h handlers in my DOS USB Host Drivers are, in fact, fully re-entrant. INT 15.4F is problematic right now regarding that (at least from what I see), because IBM indirectly says it doesn't need to be re-entrant, while MS indirectly says it does. Even though IBM is technically correct here, MS actually has more clout in the industry. INT 15.4F must in fact worry about the possibility of re-entrancy, at least in the case of Ctl-Alt-Del. that's why it was created in the first place: to free the KEYB implementation from the burden of supporting micro channel machines, where it's not as easy as 'handling INT 09' What exactly would you do differently in the INT 09 handler for an MCA machine than you would on an ISA machine? AFAIK, there is no difference -- you can install MS KEYB or any of the early KEYB clones (which all used INT 09 instead of INT 15.4F, BTW) on a PS/2 just like you can on an ISA machine, even if they were written before MCA even
Re: [Freedos-user] Problem with USB keyboard in some computers
I disagree here. You would only need reentrant handling if it could happen that int 15.4f is called while int 15.4f already is busy. This is unlikely for two reasons ... Agreed: Unlikely, but absolutely not impossible. Drivers should be designed to handle even unlikely events without crashing the machine. The fact that the machine is about to reboot isn't a valid reason to let it possibly crash, IMHO. Int 15.4f is not supposed to do anything else than keyboard layout translations so there is no far worse. Far worse includes a potential loss or corruption of data. Though, as you stated, the caches and buffers _should_ already be flushed. It is not the job of int 15.4f to toggle LEDs etc. The standard way to do that is to manipulate the bits at 40:17 and then call int 16.1 to give the BIOS a chance to sync with that. Neither int 9 nor int 15 manipulate the LED in that context, it seems. At least in MS KEYB, it is part of the INT 9 handler. In perusing the PC/AT BIOS source code, I don't see where INT 16.01 issues any I/O to the keyboard controller to manipulate the LED's, so I'm not sure how the LED's would get changed that way. Maybe I'm missing something, though. To create fake keystrokes, use int 16.5, again avoiding direct I/O manipulation and staying on the 40:xx keyboard buffer level. There are a couple of problems with that approach. The first is that not all keys on the keyboard end up in the BDA/keyboard buffer (Pause, PrintScreen, SysReq, Left/Right Windows/GUI, Power/Sleep/Wakeup, multimedia keys, etc.). If these keys are to be simulated, it must happen at the scancode level, not the BDA level. The second problem is that some programs provide their own INT 9 handler, and don't even use the BDA at all. For these kinds of programs, the simulation must also happen at the scancode level. Particularly in the case of USB, where the USB keyboard may be the only one the computer has, simulation at the scancode level is the only viable option. Simulation at the BDA level would almost be pointless. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Problem with USB keyboard in some computers
I think it could bounce off attempts to use it recursively but I do agree that it should not do I/O, so it can only be used in combination with something else which does the I/O and/or buffers. Not true. It does not ONLY need to be used in combination with something that does the I/O. In my programs, I use it to test the keyboard configuration to make sure it is correct or if a keystroke (scancode) should even be typed at all. In addition to not doing I/O, INT 15.4F cannot modify the BDA, put ASCII codes into the keyboard buffer, or anything else that the INT 09 handler proper does. In short, it cannot replace the INT 09 handler in whole or in part -- that is not its purpose. From a purely practical perspective, turning an INT 15.4F handler into a proper INT 09 handler is pretty trivial, and only requires a small amount of extra code (issuing the EOI and sending some I/O to clean up the keyboard controller). Small price to pay to ensure 100% compliance with the standards and compatibility with other programs. ? As discussed earlier, there could be a DISPLAY which processes UTF8 instead of ASCII, but it will confuse programs which assume that all string lengths are equal to their byte lengths for the layouting... I was thinking of something different, yet a separate function (which could be part of DISPLAY). The input would be a Unicode character, and the output would be a code page character (either for the current code page, or possibly for any requested code page if there was sufficient memory). Actually displaying (or in the case of KEYB, typing) the character is unrelated to this. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] New release of DOSUTILS package
I meant that support for controlling PRTSCR in this way could be a part of the PRTSCR program, without requiring the detour via SCANCODE. I can see where that might be desirable is some circumstances, though I purposely decided to go with a more modular design. Having separate programs is actually more flexible, even though it may be a little more cumbersome to implement. In terms of timing, I still need a few more days before I can upload it. I'm making some last minute additions to the program, and still need to update the documentation, before it's ready for publication. -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] New release of DOSUTILS package
But isn't it the advantage of a free operating system that there are several alternative approaches available (often more or less different) and the user has the freedom to pick the one that fits best his special requirements? But before someone can make a choice one has to know that there is one. Indeed. Another interesting thing, though, is that in combination with my SCANCODE utility, it is actually possible to automate PRTSCR. SCANCODE is able to simulate keystrokes (including the PrintScreen key) into almost any other program, including PRTSCR. SCANCODE can be programmed to do this based on various input parameters, such as absolute or relative timing, some type of message appearing on or disappearing from the screen, or other criteria. SCANCODE is actually an _extremely_ powerful tool that can automate all sorts of keyboard-related tasks, though it can take some effort to program it to do what you want. Depending on what you're actually trying to accomplish, though, your program may be a better choice than even the combination of PRTSCR and SCANCODE. -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] New release of DOSUTILS package
Points for creativity, but you have to admit that actual support for command-line (or environment variable, script) driven operation of PRTSCR would be simpler, and would suffice in at least most cases. I'm not exactly sure what you mean here. I think you can usually do what you're talking about with simple output redirection, so I have a feeling I'm missing something. -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] New release of DOSUTILS package
SCRDUMP - a utility to dump parts of the screen to a file With a hotkey as TSR, I assume? Nope. Again this utility is most useful within batch files (e.g. autoexec.bat). Typically it is called twice, once before and a second time right after the command whichs output is to be copied to a file A hotkey / TSR print screen to file tool would be nice, though. Maybe somebody on this list can recommend a nice tool for this? You can look at my PRTSCR utility which works with the PrintScreen key, available on my web site: http://bretjohnson.us It has quite a few options to let you filter the output to some degree (like skipping menu lines at the top or bottom of the screen, or skipping blank lines in the middle of the screen). It also lets you redirect the PrintScreen output to a device (like NUL or LPT3), instead of to a file. If you do multiple PrintScreens, it keeps appending the output to the same file instead of creating a separate file each time. -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] New release of DOSUTILS package
You can look at my PRTSCR utility which works with the PrintScreen key, available on my web site: http://bretjohnson.us Oops! There is indeed a PRTSCR utility there, but it is an older, simpler version that doesn't have all of the features I mentioned. The version with all of the new features is still in beta on my computer. I will try to clean it up and get it onto the web site in the next few days. -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unloading TSRs
Google up TSRCOM35 and download it. It's a package that's been around for a LONG time, and has two programs called MARK and RELEASE that are specifically designed to remove a TSR from memory. They don't work with all TSR's, but they do work with many. Also included in the package are MARKNET and RELNET, which are more advanced versions of MARK and RELEASE that are intended to allow removal of even network drivers. Network drivers usually manipulate all sorts of things in the DOS internals that the simple MARK and RELEASE programs can't undo properly. The package includes several other TSR- and device driver-related utilities. The one I personally use all the time is MAPMEM, which displays a memory map (similar in concept to MS-DOS's MEM). I find the format of MAPMEM's output more useful than any other similar program I have tested. -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Code pages in dot-matrix printers
FWIW, I still have and occasionally use a 9-pin dot-matrix printer. It's a Panasonic, and to print graphics (like from a DOS CAD program I used to use all the time) I have to tell the program I have an IBM Graphics Printer, not any kind of Epson. You should also at least consider the implications for different versions of PCL and PostScript. There may be other manufacturer-specific protocols you may want/need to support as well. Messing with printer protocols is a MAJOR headache, and this project could easily turn into a black hole for your time. I'm not saying this wouldn't be a worthwhile project, just be forewarned that it's not as simple as it may seem at first. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Problem with USB keyboard in some computers
Maybe on some machines USB has IRQ uses which are not reliably enabled during HLT? Maybe even NMI/SMI? Hard to say exactly what the problem might be, though I don't suspect it has anything to do with HLT, NMI, or SMI. It is interesting (and encouraging, at least to me), though, that it only seems to affect USBKEYB and not any of the other USB programs, including the host controller driver. Also interesting that some BIOSes are not fully compatible with DOS keyboard (layout drivers). The incompatibilities aren't related to the keyboard layout drivers as such. They are related to the way my programs simulate keystrokes (the way the my programs insert a value in AL when the BIOS issues an IN AL,60h to request a scancode from the keyboard hardware). What my programs do, in SOME cases, is call the INT 09 code stored in the IVT with the CPU's trap flag set. When the INT 09 code issues an IN AL,60h OpCode, my programs skip over the OpCode and instead insert the scancode they're trying to simulate into AL. You can download the source code for USBKEYB and review exactly how this works. For some reason, this doesn't work with all BIOS's. If I had to guess, I would say MKEYB uses int 15 and KEYB uses 40:xx. I think a lot of KEYB programs use INT 15.4Fh. I personally don't know of any that use the BDA. BTW, INT 15.4Fh will only work properly for certain keys (the letter and number keys). It usually won't work properly for things like Ctrl, Alt, Shift, PrintScreen, Pause, number pad keys, etc., if anybody ever wanted those keys to work differently than they normally do. MS KEYB doesn't use either INT 15.4Fh or the BDA. It COMPLETELY REPLACES the BIOS INT 09 handler with a new one, that process all possible keystrokes (including things like Pause, SysReq, PrintScreen, and Ctrl-Alt-Del). It doesn't simply process the keys that are different than the default BIOS handler for a particular keyboard language layout, which is what the other KEYB programs do. The other KEYB programs are not, in any way, equivalents of MS KEYB. When reading about the wish to map the mouse wheel to keystrokes on BTTR forum, I immediately thought about MOUSKEYS and was happy to see in the docs that it is actually by you (many many years ago). Maybe you could still add wheel support to it in 2011? :-) I saw that on the BTTR forum as well. I do intend to add support for wheels in the next version of MOUSKEYS, though I doubt that it will happen this year. BTW, I would also like to see CTMOUSE expanded to support the IntelliMouse2 protocol (two wheels and five buttons). If CTMOUSE did that, the next version of MOUSKEYS would support the extra buttons and wheels as well. USBMOUSE already supports the extra wheels and buttons for USB mice that have them. So in short, you have my vote for the idea to add QPI... I/O traps int 67.1axx or RM386 int 67.5dex I/O trapping or (preferred by me AND imho the easiest variant) MS EMM386 int 2f.4a15 I/O virtualization to JEMMEX. The last is I think is the only reasonable one to implement, since it is already supported by both the MS and Qualitas EMM's. This could be implemented as an optional JLM by Japheth instead of including it natively in the EMM the way MS did, though I think the control interface should still be INT 2F.4A15h. Qualitas made some expansions to the original MS standard, and I think it could be expanded even more to make it even more useful. E.g., right now the standard will only support I/O port numbers = 100h, and I think that limitation should be eliminated. Doing so would allow yet another method of simulating keystrokes in my programs. See RBIL Intlist part 2F4A15BX Install I/O virtualization handler. I've already implemented this in the USB joystick driver (USBJSTIK), and it seems to work pretty well, though I've only tested with MS EMM386. The one problem it does have, though, is that the I/O virtualization does not work with applications that access the I/O ports while in protected mode (e.g., DPMI). That could bring up a long debate about DOS DPMI applications and their general lack of concern for compatibility with modern (i.e., virtualized) hardware like USB, but I won't go there from here. See the following link, where you can download a paper and some sample code from written by Bob Smith, one of the founders of Qualitas, regarding the INT 2F.4A15 interface: http://www.programmersheaven.com/mb/x86_asm/376018/376018/virtualize-io-in-dos/?S=B2 PS: For the KEYB issue, as probably only few BIOSes are affected, some separate proper int16 and int 15.4f implementation driver would be a good idea, I would not suggest to put that into a default KEYB itself. It would certainly be possible to create a separate INT 09 BIOS Replacement program, rather than including it in KEYB. I do think the appropriate place for it is probably in the KEYB program, though, just like the MS
Re: [Freedos-user] byggy usb keyboard.
... usb keyboard; slow and not properly responsive. It is this way both with the BIOS and with my programs? Note that I can't guarantee that USBKEYB will work with Windows -- it will probably work on some computers and not on others, depending on the BIOS. USBMOUSE definitely won't work with Windows. Windows is even worse than DPMI it comes to not liking hardware virtualized by DOS. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Problem with USB keyboard in some computers
Marcos has already responded to some of this, but I will as well. Bret's USB keyboard driver worked perfectly for my two notebooks (Compaq and IBM, both year 1999) and one desktop (Pentium 166). It is unusual that the BIOS did not already do the keyboard for you. I'm not surprised at all by this, considering the ages of Marcos' hardware. BIOS's only support some subset of USB keyboards, mice, and mass storage devices (flash drives, CD-ROM's, etc.). Even modern BIOS's do not necessarily support all of these, and even if they do, the support is not always complete (they may not boot from USB disks, may not support hot-plugging, etc.). In the early days, especially with laptops, the BIOS's many times didn't support USB keyboards at all (since laptops always have a built-in keyboard). Even modern BIOS's still don't (and probably never will) support USB printers, joysticks, audio, video, serial, Ethernet, etc. There is an incompatibility with FDAPM. I forgot the details, but if FDAPM is loaded, the USB keyboard does not work properly. Did you try FDAPM ADV:REG instead of FDAPM APMDOS? That makes the power saving a bit less heavy and might reduce some side effects. In my experiments, the ADV:REG option didn't make any difference. On my computer, loading FDAPM after USBKEYB seemed to fix the problem, but apparently that didn't work for Marcos. I will investigate this further and hopefully figure out exactly what the problem is before I release the next version of USBKEYB (still several months down the road, I'm afraid). - MS-DOS keyb.com should be used instead of FreeDOS keyb.exe. Of course we cannot do that because we have no license for that. Can you be more specific? Are there any particular problems with FreeDOS KEYB? Are you using the current version? I myself like MKEYB by Tom Ehlert - fewer layouts and features but very small. The problem is that none of the KEYB replicas are fully functional replacements for MS KEYB. MS KEYB actually does two things. The first is to provide alternative keyboard layouts (e.g., the Brazilian layout that Marcos uses and the German layout that Eric uses). All of the KEYB replicas that I'm aware of do this. The other thing that MS KEYB does is replace the hardware/firmware keyboard BIOS with a new software keyboard BIOS. NONE of the KEYB replicas (at least none that I'm aware of) do this. I actually have several programs that simulate keystrokes (MOUSKEYS, JOYKEYS, SCANCODE, and USBKEYB). However, in order to simulate keystrokes properly, the BIOS must be compatible with the keyboard simulation as provided by the programs. Some hardware/firmware BIOS's are compatible, while others aren't. If you don't ever use these programs, or if your BIOS is compatible, MS KEYB is not needed. However, if you use any of these programs, and your BIOS is incompatible, you need to replace the keyboard BIOS with a new one that is compatible. MS KEYB does this, and is the only program I'm aware of that does. USB driver by Bret would also work there, I think. However MS DOS has not had any updates for ca 15 years, many parts are outdated. That may be true, but there are some parts of MS-DOS that still have not been replicated by FreeDOS or any other alternative DOS. Two significant and critical ones (at least concerning USB) that I'm aware of are the KEYB issue discussed above, and the I/O Virtualization API provided by MS EMM386. FWIW, I/O Virtualization is essential for USB emulation of things like joysticks, serial ports, and audio. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Problem w/ CONFIG.SYS INSTALL
Hi Bret, I checked the system's state with INSTALL=DEBUG.COM on a boot disk (Rugxulo's bare DOS disk, with a 2008-03-08 kernel, build 2038) and it appears fine to me. Memory that belongs to the configuration/initialization program is allocated to a PSP at segment 60h (!) which is properly set up except there's no MCB in front of it. (This means programs that display a process's name display garbage instead.) Some simple tests, including resident installation of a TSR that uses process relocation and the new Int21.4C method, passed. Tell us the programs that are used and their versions, that might help. The TSR I'm working on can't be published just yet, so that's not an option right now. It's also _really_ complicated, so I'm not sure anyone would want to mess with it anyway. I'm using an older version of the kernel -- I'm not sure exactly which one right now, but it's one from right after FreeDOS version 1 was released. I'm working with some other programmers who are using the latest versions of the kernel. I can find out exact details if it might help. Can you reproduce the crash with a minimal (dummy) TSR? Could you make a TSR available that causes this crash? I don't know -- I'll see if I can create a simple TSR that still has the problem. -- Bret -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Problem w/ CONFIG.SYS INSTALL
I was using kernel 2036. Just tried 2038 -- no effective difference. The JEMM error is different now (Error 06 at a seemingly random CS:EIP, near the top of conventional memory but where there is no associated PSP). -- Bret -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Processor overheating under DOS
I normally don't use FDAPM or POWER, but did a little bit of testing after reading this. If you load FDAPM first and then load my USB drivers, there is indeed a problem and the keyboard doesn't work properly. If you load the USB drivers first and then load FDAPM afterwards, everything seems to work just fine. I also tried using MS POWER (installed in CONFIG.SYS), and everything works fine with my USB drivers installed afterwards. So, as an alternative to what you're doing now, either use POWER instead of FDAPM, or install FDAPM after installing the USB drivers instead of before. In either case, though, you still seem to have a hardware problem -- there's no legitimate reason the CPU should get hot enough to start causing data corruption. The purpose of programs like FDAPM POWER is to extend battery life, component life, and reduce overall power consumption, not to keep the computer from overheating and destroying data. I'll try to investigate this before the next release of the USB drivers and see if I can figure out exactly what the problem is. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Liam Proven comment
LFNs on FAT was a very clever hack! It's now generally forgotten that it was Windows NT 3.5 that introduced the system, long before Windows 95. I personally don't think LFN on FAT was clever at all. It broke many programs that worked just fine before that, including Microsoft's own SCANDISK and DEFRAG. In fact, I would venture to say that if anybody other than Microsoft had come up with the hack they would have been laughed right out of the market. Up to that point, DESCRIPT.ION files were becoming something of a standard that essentially accomplished the same thing, and didn't destroy the accepted FAT structure. I'm not suggesting that DESCRIPT.ION files are a panacea, but I think they are a MUCH better idea than what Microsoft did. -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Call for volunteers (Re: Concerns about topics on t his mailing list...)
Since it seems that there is much interest in producing version 1.1, I'm putting out a call for volunteers. Please reply with what features and/or utilities you will be working on. I assume that people will want my USB drivers to be part of the utilities released with version 1.1, even though the distribution requirements are not GPL-compatible. I will be continuing to work on those, and could use help with them if anybody is interested (documentation, testing, additional device drivers, etc.). -- Bret Johnson The only things you get to keep forever are the ones you give away. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] USB for FreeDos
Hi JVP, thanks for testing the Bret Johnson USB drivers :-)
{snip}
cd\usb
usbuhci IRQ 11 DisableLegacySupport
I assume the IRQ can also be set automatically?
Yes, the IRQ is normally set automatically, either by the BIOS or by
USBUHCI{L}. The reason JVP needed to change it was because the BIOS configured
the USB Host Controller to use IRQ 12, which conflicts with the PS2 mouse
software. IRQ 12 is supposed to be dedicated to the PS2 mouse, and is never
supposed to be used for anything else.
usbprint
usbmouse
C:\Dos32\ctmouse
Cute :-) Does it support more advanced PS/2 commands
as well, in other words, can things like third button
and wheel be enabled by the ctmouse usbmouse combo?
USBMOUSE supports three different mouse protocols: the regular PS2 protocol
(max 3 buttons, no wheels), the IntelliMouse protocol (max 3 buttons, 1 wheel),
and the IntelliMouse2 protocol (max 5 buttons, 2 wheels). CTMOUSE currently
supports the first two protocols, so if your USB mouse has a wheel it will work
just fine with CTMOUSE and USBMOUSE. If CTMOUSE is ever upgraded to support
the IntelliMouse2 protocol, and your mouse has 5 buttons and/or 2 wheels,
USBMOUSE already supports it and everything will work just fine.
USBMOUSE also supports multiple mice at the same time, including a real PS2
mouse. So, you can have a right-handed USB mouse, a left-handed USB mouse, a
USB trackball, and a real PS2 mouse of some sort on the same computer and
switch back and forth between them (or even use them all at the same time) if
you want. It also supports plug-and-play for the USB mice, so if you have
more than one USB mouse but don't have enough hub ports to plug them all in at
the same time, you can simply unplug and swap them around any time you want
without needing to reboot.
USBPRINT allows you to print to USB printers from real DOS, without needing
to do it from a DOS box underneath Windows (which is the normal way everybody
does it now). USBPRINT also allows two-way communication to both USB and
parallel printers, so you can download configuration data (such as printer
identification and ink level information) from the printers. This would also
allow someone to create a DOS application to use the scanner and fax functions
on a multi-function printer (such an applications has not yet been developed,
but it is very possible to do). USBPRINT also has several other features that
should make printing better in DOS, both for USB printers and parallel
printers. You don't actually need a USB printer for USBPRINT to be useful to
you.
... 10 Micro Sec on a 533Mhz Industrial Board, with
a FreeBasic / CGUI app.
Previously I used a 2 button mouse pad on ps2.
Using the usb mouse driver with a Microsoft mouse didnt change the
timing at all, which I am very pleased about.
Great news :-) I remember running something with 1 msec
TSC based time measurements on a classic Athlon a few
years ago - there the BIOS USB driver did cause delays
big enough to make me switch to real PS/2 mice again.
Eric
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Over 4-GB for FreeDOS, Etc.
I pretty much agree. I actually don't really need or even want access to even the full 4GB that a 32-bit CPU allows, but would like what's there to work correctly no matter how much memory there actually is. My newest computer came with 6GB (64-bit Vista), which I multi-boot to DOS. I had to take 4GB out of the computer (leaving it with 2GB) to get DOS to recognize any extended memory at all, thereby leaving Vista in a less-than-optimum configuration. I should also point out that some of my programs require I/O virtualization, which is only available in MS EMM386 or Qualitas 386MAX -- none of the other memory managers are complete enough to work properly. It should also be noted that a 32-bit Windows OS (including XP-32 and Vista-32) are limited to about 3.5 GB. The absolute maximum for 32-bits is 4GB, but you have to leave room for things like video RAM and shadow RAM that don't use real memory. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS-C and GPL (was Re: Whatever happened to freedos -32?)
Pat is correct. A device driver is no different than any other executable, it just normally gets loaded via CONFIG.SYS instead of AUTOEXEC.BAT or at the command line. If a GPL OS only allowed GPL applications to run on it, it would be useless. In the DOS world, almost no programs are GPL, especially the ones you want to keep DOS around for (WordPerfect, Procomm Plus, all sorts of games, etc.). It would also have to work the other way as well -- a GPL application would not be allowed to run on a non-GPL OS (like MS-Windows). This is a ridiculous discussion, frankly. With respects to DOS-C, if loading non GPL drivers really did violate GPL, then it would have never been released under GPL. The comparison of drivers to OSLib is an apples and oranges comparison. A DOS loadable device driver is simply an executable that is loaded into memory that follows a certain calling convention. FreeDOS, or any GPLed MS-DOS alternative, would be totally useless if it disallowed non GPL device drivers, since the vast majority of device drivers are non GPL. Besides, Richard Stallman is well aware of our project and would have contacted us if he felt we were doing something wrong. Pat -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] USB Driver Comparison
There has been some discussion lately on the FreeDOS mailing list about the comparison between the DOS USB drivers made by me (Bret Johnson, http://bretjohnson.us), and those made by Georg Potthast (http://georgpotthast.de/usb). The discussion has been around three major points, and I would like to comment about those points from my perspective. 1) The licensing arrangements. The licensing arrangements for my programs are stated pretty clearly on page 6 (the Copyrighted Freeware section) of USBINTRO.DOC. The license is not simply a copy of some other canned license (GPL, Artistic License, etc.), and never will be. Rather than inserting a bunch of legal jargon for lawyers to fight over, I simply state my intent. Read it and see if you still have questions. 2) The possibility of placing a wrapper around one or both of the drivers so that in the end they have the same API, and the user will have a choice as to which one they use. At a very basic level, the two architectures are completely different from each other and incompatible. The difference is so fundamental that it actually goes right over most people's heads, and they don't grasp what it really means. A quote from Georg's documentation: Using the URB you can only schedule a transaction to a single device specified by the device address. So you can send and receive data from a mass storage device or send data to a printer. If you have a camera, which sends a constant stream of data or a mouse, DosUSB will not be able to retrieve that data while it is executing a transaction to e.g. a printer. In other words, Georg's architecture allows only one thing to happen at a time. For example, under Georg's architecture, it would be impossible to be listening to some background music from a USB-attached CR-ROM, playing on a USB-attached sound system, while typing on a USB-attached keyboard at the DOS command prompt. It would also be impossible, for example, to be using Arachne to access browse the internet across a USB-to-Ethernet converter, while using a USB-attached keyboard and a USB-attached mouse to control the Arachne program. Of course, all of these things are possible in today's world when you're not using USB, and should be possible when you start using USB hardware as well. Now a quote from my documentation: These DOS USB Drivers are specifically designed to be run in the background. That is, when you tell the Driver to send some data to a particular Logical Device, the Driver essentially says, OK -- now go do something else and I'll let you know when it's done. The Driver takes care of sending the data ENTIRELY in the background, while the computer is busy doing other things in the foreground. As you might imagine, running a process in the background is much more complicated (requires more memory) than doing it in the foreground. However, the advantages it provides (such as the ability to support mice and keyboards) generally makes it worth the extra complexity. In addition, a background process can very easily simulate a foreground process in situations where that is required, while it is impossible for a foreground process to simulate a background process. The examples stated above are all completely possible under my architecture, even though drivers for USB CD-ROMs, sound systems, and USB-to-Ethernet converters have not been written yet. The point is, under Georg's architecture, it is impossible to write drivers that could do all of those things, and do them AT THE SAME TIME. It's also impossible under Georg's architecture to implement plug-and-play. There are also very fundamental differences in the API's. Georg's API is limited to scheduling packets across the USB bus (what he calls a URB, or USB Request Block). My API allows almost complete management of the bus, not simply the scheduling of packets. In fact, it would be possible to build an application (even a GUI) that almost completely monitored and controlled the USB busses and all the USB devices attached thereto, using only calls to the API. I should point out that I have no intention of writing such an application, but somebody else certainly could. 3) The code is complicated and hard to understand. Of course it's complicated. A host driver is capable of managing dozens of devices at the same time, scheduling thousands of USB packets every second, managing plug-and-play of the devices, and doing it all in the background without any interference to the normal stuff you're doing in the foreground. How could you possibly expect it to NOT be complicated? The code is heavily commented, so someone else could understand it if they took the time. The problem is, it's not just the code that's complicated. It's understanding all of the details and nuances and interactions between DOS, USB, IRQ's, the BIOS, legacy hardware, etc. There's way more to it than just trying to understand the code. -- Bret
