Man does it seem like a long time ago that I wrote here or what? :D The deal is this, I'm writing a device driver interface document. It is mainly in line with how DOS implemented it's own device drivers, with several distinctions, you will be able to uninstall drivers real time, as well as install drivers real time. I am working out the final details on the device manager before I go public. these ideas center around the common names for devices like CON, PRN, NUL, etcetera and their respective linking within the OS. When I have finally finshed battling with that I will post an interface document for review (scrutinization). Perhaps we can finalize a semblance of it for everyone her who could benefit from a common interface.

Great! I'm going to be working on software again, another term of school is done. Now I'm an expert of Digital Systems!! :roll: In any case, I can design a light bar like the one on Knight Rider. :lol: I also got a new Test PC, a Dual Pentium Pro /200 with 128 mb RAM, Ethernet, USB, SCSI, etc. Nice machine. DEX boots on it, too. 8)

Look forward to reviewing your interface document smiddy and it will be great to have your valuable input tonyMac :). Taking about flashing lights, I am thinking about making one of these : http://drewish.com/blogger/archives/2005/03/17/2sided_pov_toy.html with "www.Dex4u.com" displayed in the wheel, but for a car :lol:. Here you can try the driver i made for AC97 sound card for "Dex4u", you just need to run the dex file from the command prompt and it will tell you if its found your sound card or not, even if its found your card it does not mean it will work with your card. If it works you can go to the GUI and use the cdplayer to try it. http://www.dex4u.com/Dex4uBmp.zip

ARGH! It is taking time...
Hi All, I figured I'd post an update on my progress in relation to device interface document et al. Well, as you know I ran into a slight snag with 16-bit protected mode (the worms flowed out of that can, let me tell you). I have since figured out the issue there. The reason I snagged there is I was wondering why, and for the most part all home-brew OSes do this, they assume that particular hardware is installed and the reality is they may not be. In order to combat this issue I went in search of ways to determine just what exactly is installed on the potential PC that may be running your (our's collectively; Dex4u, BOS, smiddyOS, etc.) OS. It would be nice, I thought, if this information was already available. As it turns out it is, and in several locations. The first such location I looked with PnP and assocaited BIOS, hence the snag with 16-bit protected mode. (for those not familiar, 16-bit protected mode still uses 64kB segments, but they are setup in your selectors, so imagine if you setup all 16 MB space in your GDT; interesting stuff I hadn't considered). Well, I figure out an algorythm to detect what was installed on my systems. However, not all my systems behaved as I had expected (BTW, I found another way of determining RAM size). This lead me to search out why PnP specs are so old and no new info was published. Well, it seems ACPI has integrated, not only PnP, but a lot of other BIOSes in using the ACPI specification. I have just skimmed the 3.0 spec and it is a lot of information to digest, but, it appears there is already a common interface within the PC to find and implement drivers through ACPI. As I said, I have skimmed it, but what I have gleened so far is it is a lot like Alex had invisioned, a seperate language and interface in comtrolling the PC. Now I realize this may be out of scope for this discussion considering the complexity ACPI employs, but I suspect it would be worth it to implement it is you are serious about global (meaning generic across the PC realm) hardware drivers. The draw back to this is it will take me even more time to implement another quasi interface path, which I've gone down once already with PnP. I'd like to hear thoughts on this because I don't want to waste anyone else time if I am out-of-bed with the general consesus here. Please interject your own experiences with these interfaces and what your knowledge adds to the the discussion and is this even worth my own effort from this collective community. Thanks!

Sorry, but i would after say to keep it simple, if not you will end up with a PC diagnostic tool, which would be good when you need that, but to have it built in to a hobby OS, will just slow the booting and make your OS big. Maybe it would be good to make a separate bootable program that tested your PC and put the info in a text file that could be used by your OS :idea: . Also would it not be better to use unreal-mode ?. PS: Run "Dex4u" on a 64bit PC (in 32bit pmode) and it run fine :).

Good questions Dex. To address unreal mode: I had considered that and have resorted to it essentially with the PnP interface. I was trying to stay within the protected mode environment for ease, but PnP was done way back when there was a lot of 286 systems employed. BTW, it can also be done in real mode...I've done all three for education purposes. To address a seperate text file: I had pondered this too. I know that I will have some sort of mechanism in place for specific device drivers, say for nVidia cards versus a standard VGA driver. While my hope is I can swap drivers out at a whim, it would serve a good purpose if the information was already available as far as the OS setup. This is a near MUST have. Diagnostics tool: Yes, in my attempt to get educated, I am over doing it a bit I suppose. In an attempt to make a smart OS it seemed smart to find out what is possible and implement it. This has side-tracked my progress in finishing my initial design goals but has given me better insight into what is possible. Perhaps this is a precursor to an application into the contest starting next month? :) I think a leaner kernel is necessary, for that you're correct. An install tool on the other hand would want to check out everything on a potential system to ensure it installs the write stuff. So this exercise isn't in vein, but merits a portion of my OS attention. CONGRATULATIONS! That is fantastic to hear (see) that it works on 64-bit machine in 32-bit mode. Can you provide details in another thread on how it ran and did it meet with your expectations?

Do not get me wrong, i do not think its a wast of time, i think its a very valuable part of OS dev, that there is little info on. And as a learning exercise it will be great and very usefull 8). If you made such a tool i would use it and tell other "Dex4u" users to test there PC with it (that is if the program was for general uses). So i would say go for it. I think if you wrote your diagnostic part into a bootable program like these : http://www.miray.de/products/sat.html they would be very usefull :). As far as "Dex4u" goes i am at the other end, "Dex4u" is designed for people to make Tools like that, as "Dex4u" can call any bios int as easy as a pmode int and would be able to print the info to a text file and put it on a floppy etc. This would save them making the OS parts so they could concentrate on the diagnostic part, but in your case its differant as the OS is the main part. As for the 512b compo, that would be a very good entry, but do not put any code in you would not like to share.