16 Dec
2005
16 Dec
'05
9:37 p.m.
On Fri, 2005-12-16 at 20:57 +0100, David Hinz wrote:
[snip]
But something about burning: Why do we have to handle this like MS does?
We can enable burning for ordinary users by default, so this problem
wouldn't appear...
The rest of it sounds good... but the only problem with burning is that
it requires, as far as I understand, low-level driver access.... which
is something that could be considered an administrative privilege. It's
sort of akin to what was found when people would run older DOS programs
that expected raw hardware access, under Windows NT. They'd fail in
unpredictable ways because the operating system went and circumvented
the action, because raw hardware access could potentially change the
state of the system in a fashion that Windows NT wouldn't be aware of.
So it's prohibited.
Now, I don't know the low level logistics of burning a CD under Win32 as
of yet, but I was planning on looking around to see if I could find that
out - just for curiosity sake. The theory that I have at the moment,
which seems to make sense to me, is that you bypass many layers of the
operating system to get around problems such as caching and what-not,
and use the low level I/O driver to do most of the work. Probably even
bypassing the CD-ROM driver that Windows uses by default. Now, I cannot
verify that theory under Vista, and didn't let Vista stay on my system
long enough to, because even on this system (a 1.8 GHz Duron w/ 512MB of
RAM) it was slow and felt very bulky. Nero, even as an admin, crashed
quite a bit, and the burn-to-CD functionality of Windows seemed to not
work (they may have removed it, but I'm not sure).
In any case, I'm not sure if its very feasible to have a monitor look
for low-level requests and audit them saying "x requests are permitted
and the rest aren't" - but I'm not sure. That could probably be
something akin to a network firewall, but only for internal system I/O.
- Mike