You are currently viewing our boards as a guest which gives you limited access to view most discussions and access our other features. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is fast, simple and absolutely free so , join our community today!

If you have any problems with the registration process or your account login, please contact us.

If you use BootItNG to save partition images instead of restore
points - have restore turned off - then you don't have to hide Vista.
Being able to get to files from either to either is sometimes handy.

Retaining Vista's backup features means needing to hide XP.
Lee Chapelle and Dave Cohen in the "Slide or Hide?" thread innews://terabyteunlimited.com/public.apps.bootitng
point out that if you decide not to limit things to 4 primary partitions,
then you can completely omit (not merely hide) the XP partition.
Your newsreader won't find the server for that newsgroup until
you change its NNTP port from 119 to 1198. You might want
to do that and tell TerraByte support about what you found.

"Dr Teeth" <no_email_here_please@tardis.com> wrote in message news:f9uet297omn0gtfc04fltm9uv9pmqt4oci@4ax.com...
>I have come across an omission in the documentation (a tutorial video
> in fact) that if followed to the letter could mean the loss of restore
> points in Vista if one double boots with XP.
>
> The video in error is
> http://www.terabyteunlimited.com/vid...g/vistanew.wmv which
> details how to install Vista into it's own partition.
> It OMITS the instructions on how to hide the Vista partition from Win
> XP. The details for doing so are in another file
> http://www.terabyteunlimited.com/tut.../tutorial1.pdf (pages
> 36-38).
>
> Cheers,
>
> Guy
>
> ** Stress - the condition brought about by having to
> ** resist the temptation to beat the living daylights
> ** out of someone who richly deserves it.

On Sat, 17 Feb 2007 22:13:17 -0600, "Michael Jennings"
>If you use BootItNG to save partition images instead of restore
>points - have restore turned off - then you don't have to hide Vista.
>Being able to get to files from either to either is sometimes handy.

Yep. But once-in-a-while BING images and SR are two different
approaches that don't replace each other, IMO.
>Retaining Vista's backup features means needing to hide XP.

Backup, or System Restore?

They may be interlinked via Shadow Copy technology.
>Lee Chapelle and Dave Cohen in the "Slide or Hide?" thread
>point out that if you decide not to limit things to 4 primary partitions,

The detail there is important.

Standard MBR is a partition table of 4 slots, thus limited to 4
partitions that are OS-agnostic. An extended partition is an MS-OS
facility that allows multiple volumes to be stored in a single
partition, though none of these will be directly bootable.

BING adds a feature that you can replace the MBR standard with BING's
extended partition table, as accessed by BING's replacement MBR code.

If you use that feature, you introduce a new brittleness into the
system. Things that don't boot through BING's non-standard MBR code
will not see BING's special partitions, and anything that corrupts the
MBR will deny access to these, unless you have an off-HD copy of
BING's MBR logic you can run instead.

Because MBR code is standard, many OSs and tools will happily re-write
this standard MBR code when they install or "fix" things. This will
also kill the BING logic required to access the "special" partitions.

So there are significant caveats and downsides if you "decide not to
limit things to 4 primary partitions".

Standard MBR rules are that an OS should ignore any partition that is
not of a type "owned" by that OS. This means that to hide a partition
from an OS, you merely set the partition type to a value not "owned"
by the OS. It *should* be so easy to hide a Vista partition from XP.

But Microsoft breaks the rules, digging into partitions that are
marked as not being theirs. This is why most standard attempts to
hide Vista from XP (or vice versa) fail.

So one has to resort to brittle dependencies such as BING's "special"
partition tables in order to hide one MS OS from another, even when
you don't need the features offered by these brittle special add-ons.

This says less about BING than it does about Microsoft.
>"Dr Teeth" <no_email_here_please@tardis.com> wrote
>>I have come across an omission in the documentation (a tutorial video
>> in fact) that if followed to the letter could mean the loss of restore
>> points in Vista if one double boots with XP.
>> The video in error is
>> http://www.terabyteunlimited.com/vid...g/vistanew.wmv which
>> details how to install Vista into it's own partition.
>> It OMITS the instructions on how to hide the Vista partition from Win
>> XP. The details for doing so are in another file
>> http://www.terabyteunlimited.com/tut.../tutorial1.pdf (pages
>> 36-38).

There's another glitch with BING; it often ASSumes file system is
FAT16, when in reality it has no idea what is going on (e.g. where the
PBR is non-standard or damaged).

But generally, glitches or no, I like BING. It is also one of the
only non-NTFS-SYS-based ways to check the integrerty of an NTFS
volume, which becomes important when the volume crashes NTFS.SYS on
contact. You have to "trick" BING into doing this, as it's not
written as a file system checker:
- start a partition resize of the volume you want to check
- BING will check the file system (which is the object here)
- BING pops up a "what size to resize to?" dialog
- cancel that dialog, as you don't really want to resize

Thanks for the info! Jim Allchin impolitely pleaded for simplicity - his
message may have been heeded only hypocritically at MS for now,
but who knows? Quieting complexity for the user *is* the trick.

BING doesn't bother much with this ideal, but in return for
accepting its complexity you get a much better value than with
image and partition management alternatives, we agree?

I am not alone in preferring once-in-a-while BING images to
system restore, but in disliking that you have the majority opinion.
My reason is emotional - I don't trust Microsoft not to screw up.
If it becomes clear that this view is irrational, then I may change it.

When you turn off XP's system restore for the Vista partition, both
systems being visible to each other, does XP still mess with volsnap?

"cquirke (MVP Windows shell/user)" <cquirkenews@nospam.mvps.org> wrote in message news:mbcgt25hbqd02pdod9q5bsttg3do0mj4c6@4ax.com...
> On Sat, 17 Feb 2007 22:13:17 -0600, "Michael Jennings"
>
>>If you use BootItNG to save partition images instead of restore
>>points - have restore turned off - then you don't have to hide Vista.
>>Being able to get to files from either to either is sometimes handy.
>
> Yep. But once-in-a-while BING images and SR are two different
> approaches that don't replace each other, IMO.
>
>>Retaining Vista's backup features means needing to hide XP.
>
> Backup, or System Restore?
>
> They may be interlinked via Shadow Copy technology.
>
>>Lee Chapelle and Dave Cohen in the "Slide or Hide?" thread
>>point out that if you decide not to limit things to 4 primary partitions,
>
> The detail there is important.
>
>
> Standard MBR is a partition table of 4 slots, thus limited to 4
> partitions that are OS-agnostic. An extended partition is an MS-OS
> facility that allows multiple volumes to be stored in a single
> partition, though none of these will be directly bootable.
>
> BING adds a feature that you can replace the MBR standard with BING's
> extended partition table, as accessed by BING's replacement MBR code.
>
> If you use that feature, you introduce a new brittleness into the
> system. Things that don't boot through BING's non-standard MBR code
> will not see BING's special partitions, and anything that corrupts the
> MBR will deny access to these, unless you have an off-HD copy of
> BING's MBR logic you can run instead.
>
> Because MBR code is standard, many OSs and tools will happily re-write
> this standard MBR code when they install or "fix" things. This will
> also kill the BING logic required to access the "special" partitions.
>
> So there are significant caveats and downsides if you "decide not to
> limit things to 4 primary partitions".
>
>
> Standard MBR rules are that an OS should ignore any partition that is
> not of a type "owned" by that OS. This means that to hide a partition
> from an OS, you merely set the partition type to a value not "owned"
> by the OS. It *should* be so easy to hide a Vista partition from XP.
>
> But Microsoft breaks the rules, digging into partitions that are
> marked as not being theirs. This is why most standard attempts to
> hide Vista from XP (or vice versa) fail.
>
> So one has to resort to brittle dependencies such as BING's "special"
> partition tables in order to hide one MS OS from another, even when
> you don't need the features offered by these brittle special add-ons.
>
> This says less about BING than it does about Microsoft.
> There's another glitch with BING; it often ASSumes file system is
> FAT16, when in reality it has no idea what is going on (e.g. where the
> PBR is non-standard or damaged).
>
> But generally, glitches or no, I like BING. It is also one of the
> only non-NTFS-SYS-based ways to check the integrerty of an NTFS
> volume, which becomes important when the volume crashes NTFS.SYS on
> contact. You have to "trick" BING into doing this, as it's not
> written as a file system checker:
> - start a partition resize of the volume you want to check
> - BING will check the file system (which is the object here)
> - BING pops up a "what size to resize to?" dialog
> - cancel that dialog, as you don't really want to resize
>

"Rock" <Rock@nospam.net> wrote in message news:Otw4Rs8UHHA.4784@TK2MSFTNGP03.phx.gbl...
> "Michael Jennings" <metarhyme@gmail.com> wrote
>> When you turn off XP's system restore for the Vista partition, both
>> systems being visible to each other, does XP still mess with volsnap?
>
> Yes, it doesn't matter whether SR is turned on in XP for that drive or not.
> XP's volsnap.sys sees the Vista restore points, shadow copy files, etc,
> thinks they are corrupt and deletes them.

On Sun, 18 Feb 2007 12:08:06 -0600, "Michael Jennings"
>Thanks for the info! Jim Allchin impolitely pleaded for simplicity - his
>message may have been heeded only hypocritically at MS for now,
>but who knows? Quieting complexity for the user *is* the trick.

Einstein said "things should be made as simple as possible, but no
simpler". So, how simple can we make things, without the user losing
control of what they are doing and thus get malware'd?

A use needs to know:
- whether something is from their PC or "out there"
- that what they think they're doing, is what they're really doing
- whether a file is data that's safe to view, or code unsafe to run

As it was, the user didn't know whether a "system alert" dialog box
was from the OS or some scumbag web site, because web sites were given
the power to automate pop-ups that could look like internal dialogs.

As it is, sometimes what you think you are doing (say, "opening"
D:\Data\Readme.txt after a search-as-you-type "Read<enter>" finds
E:\Suspect\ReadMe.exe instead) isn't what you're really doing.

And as to the difference between "viewing data" and "running code", MS
has steadily eroded the old ".BAT, .COM, .EXE" certainties (via macros
in Office "documents", scripts in HTML "message text", a plethora of
new code file types, and hiding of extensions) while not creating new
ones. You shouldn't have to know 50 file name extensions and bash the
OS over the head to see them, to know whether a file is safe to view
or risky to run. The meaningless word "open" is dumbing things down
too far; we should be using "Run", "Edit" and "View" instead.

Whenever there's a mismatch between the low risk the user things they
are taking, and a greater risk they are in fact taking, there will be
malware that will exploit this. No shortage of "Exhibit A" there.
>BING doesn't bother much with this ideal, but in return for
>accepting its complexity you get a much better value than with
>image and partition management alternatives, we agree?

I'd think so, yes. I don't find it difficult - IMO, if you're axing
around in a partitioner, you really should know what you're doing - as
long as you know to refuse the install if using it to manage
partitions rather than as a boot manager.
>I am not alone in preferring once-in-a-while BING images to
>system restore, but in disliking that you have the majority opinion.

I don't see SR and partition images as having much to do with each
other at all. It's like shoes and a car; yes, I could drive to the
letterbox to get the post and I could walk to Jozi, but each situation
so radically favours one of these tools over the other that I can't
see myself walking everywhere or driving everywhere.

For example, let's say I try some new beta device drivers for my
graphics card. (bear with me, maybe I need to, for some reason!

I could make an SR point, try the drivers, go AAAACK!, do an SR
restore to undo the damage.

Or, I could leave Windows, change my boot order, boot my BING CDR,
start a partition image of C: to logical volume E:, go out to lunch,
come back, wait for the image to complete, go back into Windows, try
the drivers, go AAAACK!, boot BING again, restore the image, have a
bath, make tea, get fresh milk, reboot back into Windows, and get
clobbered by a rogue CDR next week because I forgot to set the boot
order back to HD before CD.

Now try the above on a "great unwashed" one-big-doomed-C: 200G hard
drive. Take the day off while BING images, and the night off while
BING restores the partition. Scratch your head about where you're
going to put up to 200G of image, when you have one 200G HD.
>My reason is emotional - I don't trust Microsoft not to screw up.

I don't trust myself not to screw up, let alone anyone else :-)
>If it becomes clear that this view is irrational, then I may change it.

Machines stay on rails quite reliably.

Humans can go off the rails to find other solutions, but also tend to
accidentally fall off the rails when there's no need to so.

Machines are made by humans, so the rails they follow so well, do not
always take you to a sane destination.
>When you turn off XP's system restore for the Vista partition, both
>systems being visible to each other, does XP still mess with volsnap?

Now THAT's a good question!

XP, like WinME before it, duuuuufaults to enabling SR for every new HD
it sees - and you cannot turn off this behaviour without turning off
SR entirely (which is another option, mind you).

I'm surprised XP's screwing up on thios one. I really thought XP had
learned many of the lessons from WinME when it came to SR, in that it
uses an installation-specific CLSID in the SR data store path.

That means dropping an XP HD into another XP system will not cause the
one installation to splat the other's SR store - unlike WinME, which
screws up in about the worst possible way (kills all SR stores on all
installations on all drives)

So I can't understand why XP kills Vista's SR data, unless it's by
design for some reason. It's crazy... Vista knows XP's code logic and
should be able to stay out of XP's way, and there's no
legacy-compatibility reason to limit design of Vista's SR.

As to why MS screws around in partitions that are marked as not
theirs, that is IMO inexcusible. It may be to stay compatible with
GoBack, which fiddles around with partition type bytes while (to the
naked DiskEditing eye) maintaining internal file system compatibility,
but I think MS should have stayed within the lines of what an OS may
or may not do, and to hell with GoBack's shenannigans.

On topic: it is likely that turning off system restore altogether in XP
will restrain it from corrupting Vista's backup; doing an SR after an
AAAACK! may fail to fix things but restoring an image always does;
balance is important, as when the boss says, "Poop it out it's got to
ship I don't care how you do it," well, you find some way or other.

"cquirke (MVP Windows shell/user)" <cquirkenews@nospam.mvps.org> wrote in message news:kudkt25d6noovodu0ds42o9errq8u3bvrv@4ax.com...
> On Sun, 18 Feb 2007 12:08:06 -0600, "Michael Jennings"
>
>>Thanks for the info! Jim Allchin impolitely pleaded for simplicity - his
>>message may have been heeded only hypocritically at MS for now,
>>but who knows? Quieting complexity for the user *is* the trick.
>
> Einstein said "things should be made as simple as possible, but no
> simpler". So, how simple can we make things, without the user losing
> control of what they are doing and thus get malware'd?
>
> A use needs to know:
> - whether something is from their PC or "out there"
> - that what they think they're doing, is what they're really doing
> - whether a file is data that's safe to view, or code unsafe to run
>
> As it was, the user didn't know whether a "system alert" dialog box
> was from the OS or some scumbag web site, because web sites were given
> the power to automate pop-ups that could look like internal dialogs.
>
> As it is, sometimes what you think you are doing (say, "opening"
> D:\Data\Readme.txt after a search-as-you-type "Read<enter>" finds
> E:\Suspect\ReadMe.exe instead) isn't what you're really doing.
>
> And as to the difference between "viewing data" and "running code", MS
> has steadily eroded the old ".BAT, .COM, .EXE" certainties (via macros
> in Office "documents", scripts in HTML "message text", a plethora of
> new code file types, and hiding of extensions) while not creating new
> ones. You shouldn't have to know 50 file name extensions and bash the
> OS over the head to see them, to know whether a file is safe to view
> or risky to run. The meaningless word "open" is dumbing things down
> too far; we should be using "Run", "Edit" and "View" instead.
>
> Whenever there's a mismatch between the low risk the user things they
> are taking, and a greater risk they are in fact taking, there will be
> malware that will exploit this. No shortage of "Exhibit A" there.
>
>>BING doesn't bother much with this ideal, but in return for
>>accepting its complexity you get a much better value than with
>>image and partition management alternatives, we agree?
>
> I'd think so, yes. I don't find it difficult - IMO, if you're axing
> around in a partitioner, you really should know what you're doing - as
> long as you know to refuse the install if using it to manage
> partitions rather than as a boot manager.
>
>>I am not alone in preferring once-in-a-while BING images to
>>system restore, but in disliking that you have the majority opinion.
>
> I don't see SR and partition images as having much to do with each
> other at all. It's like shoes and a car; yes, I could drive to the
> letterbox to get the post and I could walk to Jozi, but each situation
> so radically favours one of these tools over the other that I can't
> see myself walking everywhere or driving everywhere.
>
> For example, let's say I try some new beta device drivers for my
> graphics card. (bear with me, maybe I need to, for some reason!
>
> I could make an SR point, try the drivers, go AAAACK!, do an SR
> restore to undo the damage.
>
> Or, I could leave Windows, change my boot order, boot my BING CDR,
> start a partition image of C: to logical volume E:, go out to lunch,
> come back, wait for the image to complete, go back into Windows, try
> the drivers, go AAAACK!, boot BING again, restore the image, have a
> bath, make tea, get fresh milk, reboot back into Windows, and get
> clobbered by a rogue CDR next week because I forgot to set the boot
> order back to HD before CD.
>
> Now try the above on a "great unwashed" one-big-doomed-C: 200G hard
> drive. Take the day off while BING images, and the night off while
> BING restores the partition. Scratch your head about where you're
> going to put up to 200G of image, when you have one 200G HD.
>
>>My reason is emotional - I don't trust Microsoft not to screw up.
>
> I don't trust myself not to screw up, let alone anyone else :-)
>
>>If it becomes clear that this view is irrational, then I may change it.
>
> Machines stay on rails quite reliably.
>
> Humans can go off the rails to find other solutions, but also tend to
> accidentally fall off the rails when there's no need to so.
>
> Machines are made by humans, so the rails they follow so well, do not
> always take you to a sane destination.
>
>>When you turn off XP's system restore for the Vista partition, both
>>systems being visible to each other, does XP still mess with volsnap?
>
> Now THAT's a good question!
>
> XP, like WinME before it, duuuuufaults to enabling SR for every new HD
> it sees - and you cannot turn off this behaviour without turning off
> SR entirely (which is another option, mind you).
>
> I'm surprised XP's screwing up on this one. I really thought XP had
> learned many of the lessons from WinME when it came to SR, in that it
> uses an installation-specific CLSID in the SR data store path.
>
> That means dropping an XP HD into another XP system will not cause the
> one installation to splat the other's SR store - unlike WinME, which
> screws up in about the worst possible way (kills all SR stores on all
> installations on all drives)
>
> So I can't understand why XP kills Vista's SR data, unless it's by
> design for some reason. It's crazy... Vista knows XP's code logic and
> should be able to stay out of XP's way, and there's no
> legacy-compatibility reason to limit design of Vista's SR.
>
>
> As to why MS screws around in partitions that are marked as not
> theirs, that is IMO inexcusable. It may be to stay compatible with
> GoBack, which fiddles around with partition type bytes while (to the
> naked DiskEditing eye) maintaining internal file system compatibility,
> but I think MS should have stayed within the lines of what an OS may
> or may not do, and to hell with GoBack's shenannigans.
>
>
>
>>--------------- ---- --- -- - - - -
> Saws are too hard to use.
> Be easier to use!
>>--------------- ---- --- -- - - - -

On Mon, 19 Feb 2007 22:12:27 -0600, "Michael Jennings"
>On topic: it is likely that turning off system restore altogether in XP
>will restrain it from corrupting Vista's backup

I'd hoped so, but apparently not, from what I;ve read. The process
that kills the SR material is one that's active even when SR is off
(volsnap) and if that's the case, it's tougher.
>doing an SR after an AAAACK! may fail to fix things but restoring
>an image always does

SR isn't going to undo corrupted file system etc. as imaging will do,
but neither will it blast your data back into the stone age, as an
image restore would do, if there's user data on C: (as there often
will be if using MSware).

It takes ages making an image, so you prolly are not going to image
just before every hairy operation, as you could so easily make a
restore point. So now you have an older fallback that also eats data
created since that fallback... nah, I don't see the one substituting
for the other, even if you do keep a lean, data-free C:

Rigorous OS-volume hiding is prolly the best approach, even if you do
have to build the skills and caveat knowledge to do this via 3rd-party
tools. I wouldn't mind if I never have to find out.