Windows 7 on my Tablet

A few months ago I bought an old but nice (Pentium M, 1.5GB RAM, 30GB drive, wireless, Bluetooth) tablet to experiment and to use it as an eBook (in my opinion something far better than Kindle, the Amazon’s eReader).

One of the things I wanted to test were the new features of Windows 7, but the machine has no CD / DVD, and I have no USB-DVD.

I had read, long ago, that it was possible to create a version of XP that fit in (and boot from) a USB, so I decided to investigate whether it was possible to use a USB drive to install Windows 7.

It seems that my idea was not original, because I found a dozen blogs and articles describing how this was done.

After reading “ Install Windows 7 from a USB Flash Drive " and "Windows 7 on LE1600 - Installation from pen drive ", I decided to give it a try.

I downloaded Windows 7 Professional from Microsoft.com and I borrowed a Sony USB 5 GB from work.

I followed the instructions to the letter, but every time I tried to boot from the USB, the light blinked a couple of times and then it would just remain ON while the display only showed a blinking cursor.

Evidently, this was a boot issue. I tried doing a bootsect / nt60 , but this did not help ...

I thought that maybe the computer was slow to access the USB and it might only be a matter of patience. It was already 1 am, so I decided to call it the night and to leave the system running, but the next morning everything was unchanged.

The next day, I borrowed the USB drive, and decided to try again ...

Researching a bit more I found that " How To: Install Windows 7 Beta from a USB Key! " recommends formatting the disk as NTFS rather than FAT.

I gave it a try, this time the system started to boot, but it stopped with an error:

File:\Boot\BCD
Status: 0xc0000001
Info: An error occurred while trying to read the boot configuration data

I Google it and Bingil , but did not find a convincing solution...
I decided to try again from scratch, and sure enough, it failed again (as Einstein would say: "only a fool does the same thing over and over and expecting different results").

There I remembered that a few days ago, while updating the firmware of a system at work, a vendor insisted about not booting from a USB over 2 GB. I figured there might be a connection.
I had a 2GB USB, the issue is that the installation DVD of Windows 7 has more than 2 GB and therefore had not tried.

I decided to test, at least to help determine the problem.
Copied the whole disc except for a single file (\sources\install.wim), I knew that that file is the most important of the installation process, but I decided to continue, after all this was just a test to see if I could boot.

I placed the USB on the table, and rebooted, and lo and behold! The Windows 7 Setup began to run. Of course, as soon as I clicked install, the program complained that he could not find the file.

OK, one step forward and a new challenge...

I Connected the USB 5 GB (still had the image of my previous attempts) and clicked install, the 5 GB USB was not accessed even once and the installation failed just as before ...

I Rebooted the system to try again. This time, the 5GB USB was read, but the installation failed as before.

Looking around, I found a way to access the CMD, and I began to investigate.

My hard drive was there, in the good old C: my 2GB USB was seen as D: and the 5GB as E:, the system was running from a virtual drive X: (later determined that it was based on information from \sources\boot.wim ).

Last year we created the images for the 1200+ Windows Vista machines at work, and I became quite knowledgeable of the Windows installation process. I knew that the installation program can told from where to take install.wim information.
This option is primarily for organizations to put the file on a centralized server, or a modified version of the OS, but it should be fine for my needs.
As far as I remembered, there were two ways to specify this setting to the installer process: through an “unattended installation file” (what we had done in at work to configure the VISTA machines), or through a parameter to the executable.

I did not have an "unattended file" (nor the time or the desire to create one), so I decided to use the parameter InstallFrom for the executable.

Once again, I went to CMD, and run " setup.exe /InstallFrom:e:\sources\Install.wim ", the installer ran, but gave me the same error than before. I tried a few variations (without the file name, from different locations, adding the directory path, etc), but none worked.

I started to check the virtual disk X:, and navigated to the “Phanter” directory witch, I remembered my experience with VISTA, has the log and records of the installation process.

After a while of reading those files (very entertaining, especially when using only TYPE MORE ), I realized what my problem was: The installation and was already running.
This CMD window in which I worked had been launched from the installer and was running within the environment of the installation program, so every time I executed the setup command, the installer was restarted in memory instead of a new one being executed. That is why it was ignoring my parameters.
The program was set to find the installers in D:\Sources, and there no convincing him otherwise.

Thus, I had two choices: to create an automated installation file (unattended XML file), or tricking the system to use the USB 5GB instead of 2GB.
I needed to replace an existing disk (D:) with another disk (E:), I knew the E: drive had all the same information from the D:, so if I could replace then I should have no problem even if the system tried to look for files in the old location.

Had I have access to the disk manager I would had simply changed the drive letters, but this was not the case.

Then remembered an old DOS 3.11 command SUBST which lets you assign a drive letter to a directory.
It was a very useful command when, back in my PC-XT, we copied the games to the HD diskettes, sometimes a game would complain if it was ran from a directory, in those cases we used SUSBST to give it a drive letter and played the game from that “drive”.

I wasn’t sure if the command was still available, particularly in the reduced CMD console of the installer, but turned out to be there.

I gave it a “dry test”: SUBST R: E:\ ran smoothly, and DIR R: returned the expected result.
I knew that SUBST cannot use a drive letter that is already in use, thus I needed to eliminate the D: in order to replace it with the E:, but if I boot without the 2GB USB I would not be able to reach the installer. Catch 22

After a bit of thinking, I realized that the installer was running on Windows (a reduced version but still Windows), and I knew that the plug-and-play was working (it had detected my keyboard as soon as I plugged in).
With a little luck, if I removed 2GB USB the system would release the drive letter ... or it would hang completely:-P

I crossed my fingers and removed the USB 2GB ... the system continued to operate, good sign. :-)
I ran SUBST D: E:\ and it executed without errors, I did a DIR D: I got the expected results.
It was time for the ultimate test: I clicked on install and hold my breath until the system started to install my new OS ...

A few minutes later my tablet joined the Windows 7 family !!!! :-)

Lessons learned:
"Never retreat, never surrender"
It took me 3 days and many attempts, but finally achieved what I wanted!

"Long life to DOS!"
Most of the troubleshooting I did was using 2 very old commands TYPE and MORE , and also the solution was an old command: SUBST .