Print driver folder location

  • Thread starter Thread starter John Smith
  • Start date Start date
J

John Smith

Hi,

If I move the print spooler folder to a driver other than system - say I
have C:\Winnt but I move the spooler to Z:\spool or E:\spool - should the
actual drivers remain in C:\Winnt\System32\Spool\Drivers\W32x86 or should
they be moved to the new drive location such as Z:\ or E:\ as above?

If I delete the original C:\Winnt\System32\Spool folder then I assume that
screws everything up.


John.
 
John Smith said:
Hi,

If I move the print spooler folder to a driver other than system - say I
have C:\Winnt but I move the spooler to Z:\spool or E:\spool - should the
actual drivers remain in C:\Winnt\System32\Spool\Drivers\W32x86 or should
they be moved to the new drive location such as Z:\ or E:\ as above?
Click to expand...

Leave them where they are.
If I delete the original C:\Winnt\System32\Spool folder then I assume that
screws everything up.
Click to expand...

Very much so.
 
On Sun, 28 Sep 2003 20:02:38 -0400, Carey Gregory wrote:

=>>If I delete the original C:\Winnt\System32\Spool folder then I assume that
=>>screws everything up.
=>
=>Very much so.

Oh, the weaknesses of W2K/XP! And some other OSs, too, I'm
sorry to say. No OS should have specific paths to
peripheral service modules written into it. Every OS should
be capable of _finding_ such things, no matter where you
put them.

For that matter, all an OS needs to know is where to find a
pointer to the things it needs. A jump-table should be an
industry standard. Jump-table pointer --> module location
data should work nicely. The pointer location would be
fixed (reserve a fixed range of addresses in ROM or RAM for
this) The module location data could be anywhere (each OS
would reserve its own block of addresses for this, since
the size of this data block would vary); the module could
be anywhere -- in RAM, on disk, in a memory stick - you
name it.

One side effect of this would be that a incremental
improvement would be child's play, since each module could
be maintained and fixed separately.

Bah!
 
Wolf Kirchmeir said:
Oh, the weaknesses of W2K/XP! And some other OSs, too, I'm
sorry to say. No OS should have specific paths to
peripheral service modules written into it. Every OS should
be capable of _finding_ such things, no matter where you
put them.
Click to expand...

Maybe they shouldn't, but I can't think of an OS that doesn't. UNIX offers
more flexibility with indirect files and aliases, but it still has
directories where certain files must reside.

Windows makes some vague efforts toward this with mountable volumes and the
SUBST command, plus a few folders that can be moved by changing registry
entries, but overall you need to think long and hard when you choose where
to install an OS.
For that matter, all an OS needs to know is where to find a
pointer to the things it needs. A jump-table should be an
industry standard. Jump-table pointer --> module location
data should work nicely. The pointer location would be
fixed (reserve a fixed range of addresses in ROM or RAM for
this) The module location data could be anywhere (each OS
would reserve its own block of addresses for this, since
the size of this data block would vary); the module could
be anywhere -- in RAM, on disk, in a memory stick - you
name it.
Click to expand...

Yes, this would be very flexible. It has some headaches and could create a
performance problem in some cases, but I agree it would be nice to be able
to move individual folders without having to reinstall the whole damn OS.
One side effect of this would be that a incremental
improvement would be child's play, since each module could
be maintained and fixed separately.

Bah!
Click to expand...

Yeah, mainly I agree: Bah!
 
On 30 Sep 2003 07:04:37 -0700, freddyzbm wrote:

=>From: Nhmike21 ([email protected])
=>Subject: Re: Why is alt.firefighters different?
=>
=>
=>
=>
=>can anyone tell me what a troll is?


A critter that thinks it can eat billy goats for breakfast.
 
Back
Top