I agree that some functionality is dangerous in the hands of the masses, but
today we have DriverVerifier, so, this kind of licenses could be effectively
checked with Verifier and weeded out at WHQL time. However, there is the
need for non-WHQL functionality, again, performance monitoring is a good
example, and so is our BoundsChecker: that is, the ability of standing up
monitoring events and popping up the debugger when a selected event occurs.
Those events, mind you, need not be restricted to the OS API, they could
just as well be hardware events: I should be able to trip on an I/O access,
on an interrupt, and in general on anything the hardware architecture lets
me reach.
I think I have a little bit of a philosophical issue here, I believe that
even if the OS “owns” some piece of hardware, it must never assume that the
owned hardware hasn’t been virtualized by a piece of software that runs at
lower level and interposes itself between the machine and the OS. For
example, when I did mainframes back in the 70s, we had the FLIT debugger: it
virtualized a Univac 1100 inside itself, so that you could turn on FLIT on a
machine, boot a virtual 1100 inside FLIT, and the OS inside the debugger
would not know it was running inside a debugger and not on the real
hardware. You could single step through the operating system inside FLIT,
and you still had the full power of the real OS on top. It’s as if our
SoftICE virtualized the Pentium to such an extent that we could boot Windows
inside SoftICE that runs as a Windows App, and use the full power of the GUI
outside the debugger, all while we’re debugging at machine level and single
stepping through the OS. Actually, CP67 was a bit like that on the IBM/360
Model 67, no ? A real virtual machine OS. If I remember well, we could run
OS/360 and DOS concurrently on the same machine, neither OS would know that
they’re not driving the real hardware.
This was good old Exec 8, later known as OS1100. But alas, they don’t make
them like that anymore !
Alberto.
-----Original Message-----
From: Dan Partelly [mailto:xxxxx@rdsor.ro]
Sent: Monday, August 05, 2002 8:13 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Using Local APIC as a better method than modifyin g
the IDT
Alberto,
Yaps, I can see that . However, Linux / BSD has accees to those only like a
consequence of the fact its open src. So , basically, anyone can do any
insane thing calling any API, even private ones, if they very slightly
modify kernel sources (or sometimes directly, they are a bit less
restrictive than NT, I agree). Like a engineer which wants to control
sometimes as much as possible of the OS state I would love NT beeing open
src, and with an API giving direct access to anything. Like a user, I would
be not. Most likely, it would result in 1001 flawed drivers and flawed
designs on the market. I really dont need engineers fascinated by “Im the
god of OS”… If I have to choose between those two, then a rigid API is
the way to go for me. Not to mention that I strongly beleive in closed
source, altough , paradoxally, I encourage ppl to employee reverse
engineering techniques where its legal to gain a better picture of OS
internals and a deeper understanding of things. I think I stay between the
heretic and the blindly beleiver. Of course , all in the spirit of DMCA 
Ciao, dan
----- Original Message -----
From: “Moreira, Alberto”
To: “NT Developers Interest List”
Sent: Tuesday, August 06, 2002 12:36 AM
Subject: [ntdev] RE: Using Local APIC as a better method than modifyin g the
IDT
> Actually, NT display drivers are the closest to what I’d call a “Kernel
> Module”.
>
> What I mean is a piece of software that (1) adds functionality to the OS,
> (2) has access to the hardware, and (3) does not depend on PnP or WDM
> structures or even entry point organization. All one needs is a
DriverEntry
> and a DrvEscape, like the good old OpenGL ICD I worked with. Timing and
> performance measurement is an obvious application, there are others.
>
>
> Alberto.
>
>
>
> -----Original Message-----
> From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
> Sent: Monday, August 05, 2002 5:05 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Using Local APIC as a better method than modifyin g
> the IDT
>
>
> > about time you guys give us mechanisms to implement Kernel Modules,
> not just
> > device drivers.
>
> I suspect “device drivers” is just how “kernel modules” are called in
> NT.
>
> Max
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.