Hi, Forwarding here, in case someone didn't do it already (Gmail didn't pick any reply to this, did anyone else comment on it?).
Aitor ---------- Forwarded message ---------- From: Bret Johnson <[email protected]> Date: 2009/7/24 Subject: [Freedos-user] USB Driver Comparison To: [email protected] 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 Johnson The only things you get to keep forever are the ones you give away. ------------------------------------------------------------------------------ _______________________________________________ Freedos-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user ------------------------------------------------------------------------------ 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-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
