OSDev.org

Can this be possible or NOT. I just think, maybe somebody can correct me
and maybe they can share some useful experience here. I’ve been reading
the following OSDev.org tutorial: IDE, Detecting an IDE drive.

Now this shows how you can write an IDE driver, and do a lot more.
It includes a function for CD-ROM driver ejection:

====================================================
void ide_atapi_eject(unsigned char drive) {};
====================================================

But I am wondering if we would compile this driver to a *.sys file (like in Windows®),
and then install the *.sys for the specific CD-ROM driver.

If I then would right-click the CD-driver from My computer and select
Eject, would it be possible that Windows® OS (or any other OS) is invoking
the ide_atapi_eject() function?

Thanks!

I'm seeing a pattern here:
1: This place is about hobby OS development, not writing drivers for Windoze. Go to MSDN
2: Use code tags
3: You've violated and pointed at each of the related forum rules in your previous (all two of them!) posts.

Are you a troll? At least you behave as if you don't want to be taken seriously.

I am sorry. I just wanted to ask a question,
this is NOT about Windows, I stated there and any other OS,
I want to know how OS and driver files communicate and then
communicate with Hardware.

If I click Eject then something is happening.

haha, MSDN, I've been a member there for many years...now...
their forums is funny sometimes, because once a OS question
appears they suggest the OP go to a Linux like forum.

AFAIK on modern Operating Systems (Not all Operating Systems, but some) today,
I think, the manufacturer writes the driver for their device (or hardware part), the
driver is then shipped in form of file.

Now the actual Question is whether
the OS invokes a function like this one: void ide_atapi_eject(unsigned char drive) {};

Basically, does the actual driver file work as a sort of library which shares functions
like the above one and probably other?

OK, fine. I'll add more details.

If I go in any OS and I right-click the CD icon and I select
"eject" and the CD AUDIO Door will open, so it works. But
what about the secrete behinde this, how does this really
occur, thats what I want to know.

I mean I bet that each CD-reader or DVD-reader has their
own addresses and memory addresses and ports.

So to invoke a function that uses the port address
to send a signal to the CD-reader door and suddenly
it will eject (open), but how does it work.

I haven't been able to find the actual answer, therefore
I decided to ask here, since this deals with OS development
and probably writing a kernel which can talk to the nort-and-
south bridge is an important task, right??

No, it's a binary coded Visual Basic script...
To give you an answer, a "driver file" is executable code in a form or another. AFAIK, linux and some hobby OSes use ELF for modules, which happen to coincide with your "driver files". Windows... doesn't deserve to be taken into discussion, to be honest.
Oh, and I think you should read again (at least twice) Combuster's post .

EDIT: this was written before Developer's last post. I'll let someone else explain him how electrons travel through CPU and all those things .
LE: forgot to mention the complex system that transfers electrical energy into a rotation movement and then a linear movement, used to open the drive's "Door".

So you mean everything is made in VBS and then
they use an interpreter for it.

I don't buy this. You're kidding right ?

Yes with the last post reply above. However, I am NOT kidding regarding
my question of how a OS ejects the actual CD/DVD audio door throught
the physical hardware.

Thanks for your reply!

Oh, brother...
Did any of you read the lines under the VBS crap?
Anyway, this will help you .

Finally somebody that understands, Eddyb, thanks for your reply.
The ENTIRE topic is about how can a OS and hardware communicate?

AFAIK, the OS talks with north-and-south bridge and then
can through memory addresses invoke (or something) and
collect driver details..etc.

AFAIK, once we pass BIOS, and MBR and our booloader loads in the
needed stuff and then invokes our main(); for our C kernel, then
the reset hangs on the OS, AFAIK, the OS acts "almost" (keep in mind ALMOST)
as an BIOS, because its left on its own.

EDIT: I did NOT see that it was you....hahahahaha!!! Funyy! Man!

Please, randomly posting smart-sounding terms gives you absolutely no credit. Not reading what has been said too.

If you know how you can call functions in other files, you know the answer. Get lost.
If you don't know how you can call functions in other files, you are a programming n00b and absolutely unsuited for OS development. Get lost.
If you want to get answers fed by the spoon, you are asking for trouble. Get lost before someone shoots you.

Anyway, I am sorry, I will probably ask a similar question on another Forum.
I thought that this was the place where software engineers and software
developers were and that I could find them here. I also thought that the
pros here could understand my question and then give me important details.
Anyway, guys thank you for taking your TIME. Bye, have a great time and
a nice day......Thanks!