Copying between Win 7 64-bit and Win XP subsystem

[Dr J R Stockton]

I have Windows 7 pro 64-bit, with a command prompt where VER reports
6.1.7601, and with Windows XP mode with a command prompt where VER
reports 5.1.2600.

Can I, with a batch file in Win 7, copy to/from the XP mode; and
can I, with a batch file in XP mode copy to/from the Win7?

And if so, how do I address the one from the other?

Otherwise, how about doing it with WSH JScript, WSH VBScript, or
Powershell? or otherwise?

I need to invoke certain systematic copying with a single command.

 

[Paul]

I have Windows 7 pro 64-bit, with a command prompt where VER reports
6.1.7601, and with Windows XP mode with a command prompt where VER
reports 5.1.2600.

Can I, with a batch file in Win 7, copy to/from the XP mode; and
can I, with a batch file in XP mode copy to/from the Win7?

And if so, how do I address the one from the other?

Otherwise, how about doing it with WSH JScript, WSH VBScript, or
Powershell? or otherwise?

I need to invoke certain systematic copying with a single command.

Treat this as a series of ideas, and not a recipe.

1) WinXP Mode relies on Windows Virtual PC software.
That's a "wall of emulation", intended to prevent direct
host to guest interaction. Interaction is only allowed
through certain specially defined ways. Windows Virtual PC
is a follow-on of VPC2007, and as far as I know, inherits
a 137GB limit on how large a file system can be made visible
in the guest environment.

2) The guest OS supports file sharing. You can mount a Windows 7
host share, within the guest OS. And then, run a script in the
guest if you want to copy.

3) Via "VPC Additions", when you have the WinXP Mode desktop visible,
you can "drag and drop" files from a host folder, into a guest
folder.

4) The virtual PC software may support a "shared folder". Which
is a way to get a folder of files to show up within the guest.
Again, once the stuff shows up as its own drive letter,
like X:, you can run a script in the guest, to copy files
to the internal WinXP Mode file system.

Note that the "bar" in the GUI, with VPC options, is poorly
implemented in Windows 7. You may want to look at VPC2007
control box dialogs, to get some idea as to the technical
capabilities of the software. Windows 7 hides things, and makes
it *very* hard to understand what options are available to you.

5) The final method, is to consider how the WinXP Mode OS is stored.
It could be stored on a .vhd or .vhdx file. This is a multi-GB
file, holding the entire C: of the WinXP Mode OS.

You shut down WinXP Mode first. That stops access to the .vhd or
.vhdx from WinXP. Then, you investigate Windows 7 method for
"mounting a .vhd". Once the VHD is mounted, it has its own
drive letter in Windows 7, and you can script or copy as you
see fit.

There are a ton of ways to do it.

*Always* be careful of the 137GB limit, which is a part of
Windows Virtual PC. I lost an NTFS partition when it got
corrupted by being shared between a host and guest. I was
writing an uncompressed video track, when I crossed the 137GB
boundary, and the file system as seen on the host side, was
irretrievably lost (address rollover and overwrite). As long
as the things you work on, are smaller than 137GB, it's
probably safe. If you're dealing with things larger than
that (like doing file sharing of a single 500GB partition),
then, ask more questions before proceeding. In fact, make
sure you have backups, before doing a thing like that.

Enjoy the research,

Paul

 

[Steve Hayes]

*Always* be careful of the 137GB limit, which is a part of
Windows Virtual PC. I lost an NTFS partition when it got
corrupted by being shared between a host and guest. I was
writing an uncompressed video track, when I crossed the 137GB
boundary, and the file system as seen on the host side, was
irretrievably lost (address rollover and overwrite). As long
as the things you work on, are smaller than 137GB, it's
probably safe. If you're dealing with things larger than
that (like doing file sharing of a single 500GB partition),
then, ask more questions before proceeding. In fact, make
sure you have backups, before doing a thing like that.

That is one reason that, when I got a new laptop with Win 7 64-bit installed,
and found that a lot of programs I use would not run on it, I used the 32-bit
version that came on a DVD and installed that, and had no problems using those
programs.

The more important reason was what nothing in the documentation that came with
the computer said anything about virtual PC, so I didn't know it existed.

But from what you have said it sounds like a very clumsy and roundabout
solution. If I'm working in one program, and want to look up something in
another, loading a virtual operating system to look at the data in the second
program sounds like a risky process to me.

 

[Paul]

That is one reason that, when I got a new laptop with Win 7 64-bit installed,
and found that a lot of programs I use would not run on it, I used the 32-bit
version that came on a DVD and installed that, and had no problems using those
programs.

The more important reason was what nothing in the documentation that came with
the computer said anything about virtual PC, so I didn't know it existed.

But from what you have said it sounds like a very clumsy and roundabout
solution. If I'm working in one program, and want to look up something in
another, loading a virtual operating system to look at the data in the second
program sounds like a risky process to me.

Not at all.

On my old Macintosh (G4), two OSes run practically all the time
(MacOSX and MacOS9). I have older programs I use, and they run
on the older OS. And like WinXP Mode, the output is rootless,
and each program and window floats freely. Copy and paste is
seamless between environments. And that should be more or
less what WinXP Mode ends up doing for you.

One difference in that case though, is that both guest and host
see the same file systems. Which means, there's no reason to
be copying files between OSes, as both OSes use all the same
disks.

*******

The 137GB limit is an implementation detail. A nasty detail,
but a detail none the less. It's like worrying about
using >4GB files, when your C: drive is FAT32. Same kind of thing.
Only if the 137GB limit is violated, corruption can result.
Whereas violating the 4GB rule on FAT32, just stops your
download dead in its tracks.

After having one minor catastrophe because of the 137GB thing,
I haven't had one since. You could say I'm a lot more careful now,
about what connects where.

What is also interesting, is the same limit exists when using this tool.
The limit in this case, is stated as 127 GiB. I prefer the 137GB number,
because GB is what the disk manufacturers use. On computers, you'll find
these units mixed casually without a care in the world, leaving it to
the reader to work out the details (so my radar has to be tuned for
two numbers).

"Disk2vhd v1.63"
http://technet.microsoft.com/en-us/sysinternals/ee656415

http://en.wikipedia.org/wiki/Gibibyte

Paul

 

[Steve Hayes]

Not at all.

On my old Macintosh (G4), two OSes run practically all the time
(MacOSX and MacOS9). I have older programs I use, and they run
on the older OS. And like WinXP Mode, the output is rootless,
and each program and window floats freely. Copy and paste is
seamless between environments. And that should be more or
less what WinXP Mode ends up doing for you.

One difference in that case though, is that both guest and host
see the same file systems. Which means, there's no reason to
be copying files between OSes, as both OSes use all the same
disks.

Does that mean that in Windows they do not use the same file systems?

For example, if I have a file with a .txt ending, Windows tends to open it
with Notepad, but if I wanted to open it with a DOS word processor, would I
have to copy it before I could do so, and then copy it back so that Notepad
could open the latest version?

 

[Paul]

Does that mean that in Windows they do not use the same file systems?

For example, if I have a file with a .txt ending, Windows tends to open it
with Notepad, but if I wanted to open it with a DOS word processor, would I
have to copy it before I could do so, and then copy it back so that Notepad
could open the latest version?

I made a statement to that effect, in my initial answer.

That's a "wall of emulation", intended to prevent direct
host to guest interaction.

If you have a VM, the file system visible inside there, is not
the same as the host file system. On a virtual machine, you set
up a VHD file as the place the guest stores its files. If you
run an installer CD in the guest, the installer CD installs
to the VHD file. And the VHD file is like an "image" of a file
system.

And that is why the OP asked his question. He's trying to ease
the communications gap between guest and host. I tried to explain
the many ways of gaining visibility. But there's no punching
through the "wall of emulation" otherwise. One benefit of doing
it that way, might be that malware can't write to the host.
I say *might*, because there are already exploits for
virtual environments, and I don't know how common those would
be in the wild.

Also of note - of the many methods for copying files, some
of them are quite slow. If you have gigabytes of files to
transfer, you'd better think very carefully, how to get
them between guest and host. On my machine here, doing
file sharing, gives perhaps 1.5MB/sec transfer rate.
Some other option might give 30MB/sec. I don't typically
transfer files that large, but it's a consideration if
you do. I might try mounting the VHD with WinXP Mode shut
down, as a way to get the files into the image faster.

I think I may have tried FTP between my laptop and a guest
VM running on my desktop, and that worked pretty well. But
many of the I/O paths in the VM, are pretty damn slow. So
slow in fact, it almost looks like it was done on purpose.
Any decent buffering scheme, should have given better
results than that.

Paul

 

[Wolf K]

Does that mean that in Windows they do not use the same file systems?

Windows and Macs use different file systems. IIRC, OS-X could from the
beginning read and write to disks, flash drives, etc formatted with DOS
and Windows file systems. NB that in this context "file system" means
the way the tracks and sectors are organised, and the way the directory
(folder) keeps track of the files. The DOS system is the usual one for
USB flash drives.

For example, if I have a file with a .txt ending, Windows tends to open it
with Notepad, but if I wanted to open it with a DOS word processor, would I
have to copy it before I could do so, and then copy it back so that Notepad
could open the latest version?

File formats are a different animal. A text file (*.txt) consists
entirely of text characters, with no formatting codes (such as bold,
columns, etc), or inserted pictures. Notepad, like any other text
editor, will open and display a *.txt file correctly, as long as the OS
can read the file on the disk. It doesn't matter what program created
the file, nor on what operating system it ran.

The same is true of other standard file formats: it doesn't matter what
program created a *.jpg picture file, or what OS hosted it, you can open
and admire it on your computer. This universality of file formats is one
the reason you can use the web to exchange stories, pictures, etc, with
your friends'n'relations.

Actually, text editors will open any file as a display of characters.
Try dragging a *.jpg file into the text-editor window. You should see a
block of nonsense. If your text editor does not do this, that means that
the programmers are protecting you from doing silly things with non-text
files.

HTH

 

[Paul]

Windows and Macs use different file systems. IIRC, OS-X could from the
beginning read and write to disks, flash drives, etc formatted with DOS
and Windows file systems. NB that in this context "file system" means
the way the tracks and sectors are organised, and the way the directory
(folder) keeps track of the files. The DOS system is the usual one for
USB flash drives.


File formats are a different animal. A text file (*.txt) consists
entirely of text characters, with no formatting codes (such as bold,
columns, etc), or inserted pictures. Notepad, like any other text
editor, will open and display a *.txt file correctly, as long as the OS
can read the file on the disk. It doesn't matter what program created
the file, nor on what operating system it ran.

The same is true of other standard file formats: it doesn't matter what
program created a *.jpg picture file, or what OS hosted it, you can open
and admire it on your computer. This universality of file formats is one
the reason you can use the web to exchange stories, pictures, etc, with
your friends'n'relations.

Actually, text editors will open any file as a display of characters.
Try dragging a *.jpg file into the text-editor window. You should see a
block of nonsense. If your text editor does not do this, that means that
the programmers are protecting you from doing silly things with non-text
files.

HTH

The two OSes running on my Mac G4, work like this. Programs
in either environment, see the same disk. Or set of disks.
I had around 20 partitions on the G4, and both environments
see all of them. It's not a true virtual machine environment,
because it doesn't have the same degree of isolation.
What it does have, is cooperative multitasking inside OS9,
and regular multitasking in OSX. If OS9 "jams up", you can
select to restart MacOS9, without screwing up OSX. Cooperative
multitasking has that exposure, that it jams up more easily. And
this architecture provides the best of both worlds, allowing
older programs to run. One of the reasons for buying this G4,
was it was one of the last to support this feature. You can
also boot MacOS9 "native" and have it take over the machine,
but I don't do that very often. You can do that, because the
processor was PowerPC and not Intel (which came later).

MacOSX --------> Macintosh HD
MacOS9 -------->

On the PC (or for that matter, most other virtual machine
implementations), it works like this. There is no direct
path from C: to C: as such. You can't "Save As" in the
guest and store a file in the host C:. But if you arrange
file sharing, shared folder, Drag N' Drop, FTP, or the
like, there are ways to (eventually) get there. With enough
effort, you can make it look like it is integrated, but
it won't be quite as seamless as the Mac method above.
And with this particular platform (Windows Virtual PC),
you have to be careful about that 137GB issue when
setting up file systems. I had my one corruption in
VPC2007, and that was enough of a warning for me
about that issue.

(File sharing, shared folder, Drag N' Drop)
___________
/ \
/ \
Host Guest
Win7 WinXP
| Mode
| |
C: on |
real C: inside
hard VHD image
drive file

I don't have WinXP Mode set up, so have no ability
to verify any details about it. My experience is
more generally with the usage of VMs. And only
on a couple platforms (VPC2007 based or VirtualBox).

HTH,
Paul

 

[Gene Wirchenko]

On Thu, 22 Nov 2012 06:47:23 +0200, Steve Hayes

[snip]

Does that mean that in Windows they do not use the same file systems?

For example, if I have a file with a .txt ending, Windows tends to open it
with Notepad, but if I wanted to open it with a DOS word processor, would I
have to copy it before I could do so, and then copy it back so that Notepad
could open the latest version?

Nope. A file is a file. As long as the two programs are playing
by the same rules, it should be fine. That stated, be sure that the
character sets are the same. A Unicode-character file is not going to
work so well with a DOS program.

Sincerely,

Gene Wirchenko

 

[Seth]

I have Windows 7 pro 64-bit, with a command prompt where VER reports
6.1.7601, and with Windows XP mode with a command prompt where VER
reports 5.1.2600.

Can I, with a batch file in Win 7, copy to/from the XP mode; and
can I, with a batch file in XP mode copy to/from the Win7?

And if so, how do I address the one from the other?

Otherwise, how about doing it with WSH JScript, WSH VBScript, or
Powershell? or otherwise?

I need to invoke certain systematic copying with a single command.

I haven't tried this in "XP Mode" but this does work in "MED-V v2" (which is
very similar). In XP mode, see if you can address the Windows 7 host drive
as \\tsclient\c. That's exactly what I do to access the host drive from
within MED-V.

 

[Zaphod Beeblebrox]

On Wed, 21 Nov 2012 22:13:42 +0000, "Dr J R Stockton" <reply1247
@merlyn.demon.co.uk.invalid> wrote in article

I have Windows 7 pro 64-bit, with a command prompt where VER reports
6.1.7601, and with Windows XP mode with a command prompt where VER
reports 5.1.2600.

Can I, with a batch file in Win 7, copy to/from the XP mode; and
can I, with a batch file in XP mode copy to/from the Win7?

And if so, how do I address the one from the other?

Otherwise, how about doing it with WSH JScript, WSH VBScript, or
Powershell? or otherwise?

I need to invoke certain systematic copying with a single command.

XP Mode uses Terminal Services, which automatically makes each drive on
the host PC available as a shared resource. You can map a drive letter
to your existing hard drive by using the \\tsclient server name. For
example, to use your C: drive in XP Mode as, say H: (H for Host) you
would use the command NET USE H: \\tsclient\c. Since the mapping is
persistent by default, it should be available in all future XP Mode
sessions.

 

[Dr J R Stockton]

In alt.windows7.general message <[email protected]
-september.org>, Mon, 26 Nov 2012 10:44:28, Zaphod Beeblebrox <Zaphod.Ar
(e-mail address removed)> posted:

On Wed, 21 Nov 2012 22:13:42 +0000, "Dr J R Stockton" <reply1247
@merlyn.demon.co.uk.invalid> wrote in article


XP Mode uses Terminal Services, which automatically makes each drive on
the host PC available as a shared resource. You can map a drive letter
to your existing hard drive by using the \\tsclient server name. For
example, to use your C: drive in XP Mode as, say H: (H for Host) you
would use the command NET USE H: \\tsclient\c. Since the mapping is
persistent by default, it should be available in all future XP Mode
sessions.

Looks good. Real Life has intervened, but I'll try it with every hope
of success as soon as I can. Thanks; and also to Seth.

 

[Dr J R Stockton]

In alt.windows7.general message <[email protected]
rlyn.invalid>, Thu, 29 Nov 2012 18:24:54, Dr J R Stockton <reply1248@mer
lyn.demon.co.uk.invalid> posted:

In alt.windows7.general message <[email protected]
-september.org>, Mon, 26 Nov 2012 10:44:28, Zaphod Beeblebrox <Zaphod.Ar
(e-mail address removed)> posted:

Looks good. Real Life has intervened, but I'll try it with every hope
of success as soon as I can. Thanks; and also to Seth.

Yes. Both work. Now all I need is a way of remembering them!

 

[Zaphod Beeblebrox]

On Fri, 30 Nov 2012 19:28:29 +0000, "Dr J R Stockton" <reply1248
@merlyn.demon.co.uk.invalid> wrote in article

In alt.windows7.general message <[email protected]
rlyn.invalid>, Thu, 29 Nov 2012 18:24:54, Dr J R Stockton <reply1248@mer
lyn.demon.co.uk.invalid> posted:


Yes. Both work.

Thanks for the follow up. Glad I could help.

Now all I need is a way of remembering them!

I'll confess, I had to go back and check my notes so no suggestions to
help you there.

--
Zaphod

"So [Trillian], two heads is what does it for a girl?"
"...Anything else [Zaphod]'s got two of?"
- Arthur Dent

 

[Dr J R Stockton]

In alt.windows7.general message <[email protected]
-september.org>, Mon, 3 Dec 2012 08:43:32, Zaphod Beeblebrox <Zaphod.Ari
(e-mail address removed)> posted:

On Fri, 30 Nov 2012 19:28:29 +0000, "Dr J R Stockton" <reply1248
@merlyn.demon.co.uk.invalid> wrote in article
<[email protected]>...

Thanks for the follow up. Glad I could help.


I'll confess, I had to go back and check my notes so no suggestions to
help you there.

I do not actually need it; but if there is a batch way, within the outer
64-bit system, of addressing directories within the inner 32-bit system,
it would be nice to know of it for completeness.

 

[Zaphod Beeblebrox]

On Tue, 4 Dec 2012 19:41:04 +0000, "Dr J R Stockton" <reply1249
@merlyn.demon.co.uk.invalid> wrote in article <XVHz+TEQHlvQFwx6
@invalid.uk.co.demon.merlyn.invalid>...

In alt.windows7.general message <[email protected]
-september.org>, Mon, 3 Dec 2012 08:43:32, Zaphod Beeblebrox <Zaphod.Ari
(e-mail address removed)> posted:


I do not actually need it; but if there is a batch way, within the outer
64-bit system, of addressing directories within the inner 32-bit system,
it would be nice to know of it for completeness.

You'll need to use diskpart to select and attach the VHD as a disk.
Fortunately, diskpart can be scripted, and equally fortunately, someone
has already done the work to produce batch files to mount the VHD as a
drive letter (and optionally specify the drive letter) and unmount it
when done.

Both take the fully qualified path and file name to the VHD as the
first parameter (quoted, if necessary), and MountVHD.cmd takes an
optional second parameter for the desired drive letter (otherwise,
diskpart will use the next available drive letter).

MountVHD.cmd (lines not starting with two spaces have wrapped):

@echo off
setlocal enabledelayedexpansion

if {%1}=={} (
echo Usage: %~nx0 [vhd] [letter]
exit /b 1
)
set vhdPath=%~dpnx1
set driveLetter=%2

if {!driveLetter!}=={} (
echo Mounting !vhdPath!
) else (
echo Mounting !vhdPath! to !driveLetter!:
)

REM
REM create diskpart script
REM
set diskPartScript=%~nx0.diskpart
echo sel vdisk file="!vhdPath!">!diskPartScript!
echo attach vdisk>>!diskPartScript!

REM assign the drive letter if requested
if not {!driveLetter!}=={} (
echo select partition 1 >>!diskPartScript!
echo assign letter=!driveLetter!>>!diskPartScript!
)

REM Show script
echo.
echo Running diskpart script:
type !diskPartScript!

REM
REM diskpart
REM
diskpart /s !diskPartScript!
del /q !diskPartScript!

echo Done!

endlocal


And UnmountVHD.cmd:

@echo off
setlocal enabledelayedexpansion

if {%1}=={} (
echo Usage: %~nx0 [vhd]
exit /b 1
)
set vhdPath=%~dpnx1

echo Unmounting !vhdPath!

REM
REM create diskpart script
REM
set diskPartScript=%~nx0.diskpart
echo sel vdisk file="!vhdPath!">!diskPartScript!
echo detach vdisk>>!diskPartScript!

REM
REM diskpart
REM
diskpart /s !diskPartScript!
del /q !diskPartScript!

echo Done!

endlocal

I've not tested either, but from a quick review of the script they look
reasonable to me.

--
Zaphod

"So [Trillian], two heads is what does it for a girl?"
"...Anything else [Zaphod]'s got two of?"
- Arthur Dent

 

[Dr J R Stockton]

In alt.windows7.general message <[email protected]
-september.org>, Wed, 5 Dec 2012 08:57:12, Zaphod Beeblebrox <Zaphod.Ari
(e-mail address removed)> posted:

I've not tested either, but from a quick review of the script they look
reasonable to me.

Saved, for study if/when I **really** need them. Thanks.