steve17

Apparently WIn8 can't be installed on a GPT formatted drive if the computer uses BIOS. It must use UEFI. Also Win8 won't install on a computer using UEFI if the hard drive is formatted MBR. It must be GPT In other words: GPT UEFI - yes. MBR BIOS - yes Otherwise - no. ..

This requires you to enter the password of a healthy admin account. (unless I'm horribly confused ). What if your normal admin account gets clobbered? I guess you could put a password on Administrator to use in this case.I normally run from a non-admin account, and also have an admin account. I create another admin account that is hidden from the login screen to use if my normal admin account gets clobbered. I hide it with the registry entry: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList] "account name goes here"=dword:00000000 Such a hidden account is still enabled, and it's password can be used. I can make this account loginable from my non-admin account by running regedit using "run as different user" (hold down shift key), and using it's password. From regedit I can flip the "hide" bit in the registry. I know I can login to Administrator from safe mode, if all admin accounts are "disabled", but I don't trust Win7 to know if my admin account is "clobbered".

Yep. There was a minor bug in XP when the taskbar was at the side. When it was at the bottom it would group like items. If I had multiple explorers running it would put them in one icon. When the taskbar was at the side it would not group them. If I dragged the taskbar from the side to the bottom, the items would group instantly. If I dragged it back to the side, the groups would remain. Strange. It seems they use different code depending where the taskbar is. I smell a mess there.

I have now installed Win7 on a second machine. It has different graphics hardware (Radeon x1550). I see the same taskbar problems on this machine. I have found 3 ways to cause the taskbar to shrink. 1. switch user (and come back) 2. run performance assessment 3. change the "Enable desktop composition" in the Performance Options window. The initial taskbar conditions required are: 1. left side of screen (or right side) 2. auto-hide 3. stretched out width 4. translucent taskbar It sure seems like a bug in the Win7 Aero to me, but since I've switched to an opaque taskbar by unchecking "Enable desktop composition", I'm happy. I have posted two threads on a Microsoft website, but they don't seem to be very interested. http://social.technet.microsoft.com/Forums...d1-a3a1e1c1eb1b My experience on that website is that when I post about something that looks like a Windows bug, they either ignore it or suggest I have a driver problem.

Apparently my taskbar problems are related to Aero, and they are apparently graphics hardware specific. My graphics hardware is on my Intel DG43NB motherboard. The Microsoft boys couldn't reproduce it on their computers so could not fix it. By trial and error, I found that when I unchecked "Enable desktop composition" in the Performance Options window, the taskbar bugs went away. My taskbar and windows are no longer translucent. No longer do the desktop icons, etc. peek through the taskbar and annoy me. I like it better this way. Maybe I'm missing something, but as long as I don't know what I'm missing, I'm happy. I understand the annoyance of accidentally unhiding wide taskbars at the side of the screen. For that reason I don't put it at the right side. I find that it's not much of a problem at the left side. It happens occasionally, but the convenience is worth it. I don't have my windows full screen. I stretch out browser windows to almost full, but no quite. Maybe that's the reason I don't have much trouble accidentally unhiding. With Win7's magic taskbar (grouping etc.) there is less advantage to a wide taskbar then there was in XP. The two things that benefit from a wide taskbar are the quick launch, and the notification area. Since I've learned to use the magic taskbar, I don't install quick launch any more. Maybe I'll try it again sometime. I did use it with Win7 beta and didn't notice any problems. But that was running on old hardware that didn't support Aero.

The failure to unhide with the mouse problem is more puzzling. It seems to be unique to this machine. Apparently my hardware and Win7 RTM don't play well together in this case. I have 4 installations on this machine of Win7 RTM, 2 32 bit and 2 64 bit. All of them have this problem. I also have 2 installations of Win7 RC and 2 installations of XP on this machine and they don't have this problem. I investigated this problem further. It only happens when the taskbar is on the left of the screen. It does not happen if the taskbar is on the right, top, or bottom. Normally when the taskbar is hidden, there is still a 2 pixel wide remnant of it that is visible. Apparently when the mouse pointer is over this remnant, the O.S. is triggered to un-hide the taskbar. When the taskbar is on the left with auto-hide, and I do a "switch user" and come back, that 2 pixel remnant is not there. I need to get it back by pressing the "Windows" key. It might seem like a simple hardware problem or incompatibility, but it is not that simple. Win7 RC and XP running on this machine don't have the problem. Very strange. The Win7 RC and Win7 RTM use the same display driver.

Thanks LordFett. I really appreciate it. It seems the shrinking taskbar is a bug in Win7. It exists in the RTM and RC versions. I did some more investigation. It happens when the taskbar is on the right or left. It does not happen when the taskbar is at the top or bottom. It only happens when auto-hide is used. And of course it is triggered by doing a "switch user" and coming back. I wonder if it is possible to report this to Microsoft. Does the fact that I purchased the upgrade license entitle me to a little free service from Microsoft? Steve

Thanks LordFett for testing. I don't understand the end of the sentence. I'm not sure if you had the problem of the mouse not being able to unhide it after a "switch user".Can you confirm you did have the unhide problem? Thanks, Steve

I have re-booted Win7 RTM dozens of times and I've rebooted Win7 RC hundreds of times. The taskbar width I set survives re-boots and survives logoffs. It's just "switch user" that causes it to shrink to the default width. Similarly, after reboots and logoffs, my auto-hide works fine. It's only "switch user" that screws it up. I've been trying to get someone else to confirm this problem on several forums to no avail. I guess I am the only person in the world who moves the taskbar from the bottom of the screen.

Be aware that the Administrator account has no password by default. Personally I wouldn't mess around with the Administrator account because I assume (probably at my peril) that Microsoft knows what they are doing better than I know what they are doing. At least by a slim margin. The Administrator account seems to be Win7's ace in the hole. You can log on to this disabled account from safe mode when all other admin accounts are disabled.

I find when the taskbar is not at the bottom, there are two bugs. I normally put it at the left side of the screen. If I stretch out the taskbar to make it wider, do a "switch user", and return, the taskbar will be shrunk to the default size. The default size is about the width of an icon. If I use auto-hide, do a "switch user", and return, I can't un-hide it with the mouse, until it's been un-hidden by other means, like pressing the "windows" key. Can anyone else confirm these problem? It doesn't surprise me that Windows taskbars are buggy when not at the bottom. XP's taskbar won't group tabs unless the taskbar is at the bottom. Do you suppose I'm the only person in the world that doesn't have the taskbar at the bottom? Am I also only one of two people in the world that hides the taskbar? I know of one other person that hides it.

One more question. If I understand correctly, I need to have XP running (or Vista) to install the upgrade Win7. And I understand XP gets wiped off the disk. So what would I do if the upgrade Win7 gets wiped or the hard drive dies? Can I just keep re-installing XP and from there install Win7? I can do an unattended install of XP in 15 minutes, so I guess I could tolerate that. But would XP need to be activated before installing Win7? Can I keep on activating XP until hell freezes over, even though I've upgraded to Win7?

Thanks for all the info. The Microsoft's upgrade offer was sadly lacking in details. I have the full retail XP and it looks like the upgrade will basically give my an OEM version of Win7. If I'm wrong, please inform me. I want to have the "full retail" license of Win7 just like I have with XP. I can move my XP to another machine any time I get tired of the old one. If the upgrade license doesn't allow that, it's no good to me. Also I can install XP multiple times on the same machine. I always have at least one install on each of the two hard drives. This allows me to boot up come hell or high water, or a sick hard drive. A third install is good for testing new software packages to see how badly they would contaminate the regular XP install I depend on always being there. If the upgrade gives me this ability, please explain. Hopefully the full retail Win7 will give me this, otherwise I'll have to stick to XP forever.

When I log in, numlock is turned on. I want it to stay off. I used regedit to change InitialKeyboardIndicators from 2 to 0, but it does nothing. After logging off and on, or after rebooting, it's back to 2. This is in HKEY_CURRENT_USER\Control Panel\Keyboard. How can I beat Win7 rc into submission? P,S, It's shut off in the BIOS.

Thanks Mr. Snrub. I'll get the hang of it someday. I found I could run bcdedit if I started the command prompt running as administrator. I also noticed the first time I run EasyBCD after logging on, I get a UAC window asking if I want to run the program from an unknown publisher. I had not paid much attention to it before because I think I occasionally get something similar with XP. Running bcdedit made me glad I had downloaded EasyBCD. Thanks again -X=.

Thanks -X-. EasyBCD did the trick. But I'm still confused as to why I get the error message when I try bcdedit. Maybe that's because I don't understand "elevated" and UAC. I think I'm running as an admin. I use the account the Win7 installer created. Win7 tells me I'm a member of the administrator's group. But I still can't run bcdedit. What the heck is going on? EasyBCD runs okay but bcdedit can't access the data store. Very strange. By the way, when I installed EasyBCD it insisted on getting internet access. At least a box requesting it kept popping up and wouldn't take no for an answer. That's okay, I dialed up and it installed fine. I have been keeping Win7 rc off the internet as much as possible until I get an antivirus working. NOD32 version 3.0.667.0 doesn't work, although it works on the previous beta version of Win7. Edit: I'm running EasyBCD from a shortcut and running bcdedit from a command prompt.

I want to change the name of the Windows 7 entries in the O.S. selection menu that shows up at startup. And put the default back to XP. I believe I have to run bcdedit to do that. I think I did that with the previous beta version, but the rc version won't let me. I get the message "The boot configuration data store could not be opened. Access is denied." Are we really sure this is better than XP?

Thanks, that was it. I noticed there was an arrow in it's icon, but I didn't know what that meant. Now that I can see the contends, I see I had already put the WordPad shortcut into it. I had copied the shortcut and pasted onto the SendTo I saw in Windows explorer, but because I couldn't see the folder contents I assumed it didn't work. Oh man. This is going to take some getting used to.

I can see it in Windows Explorer. The security stuff says I have full control. But I can't access it. I want to put a shortcut to WordPad there.

I find I can put the $OEM$ folder anywhere if I use the OemFilesPath thing in the [unattended] section. I use a relative path and I was initially tripped up because I assumed the relative path was relative to the answer file. It turns out it's relative to the I386 (or whatever) folder. If you are making a CD, of course the answer file (winnt.sif) is inside I386 so there is no difference. But I have my answer file somewhere else. I found it helpful to look at the log. I think it is at %windir%\winnt32.log For anyone who isn't familiar with the OemFilesPath, there is another confusing thing about it. It isn't the path to the $OEM$ folder but a path to the folder that contains the %OEM% folder. In other words the path should not end with %OEM%.

I'll bet you have only one Windows OS installed on your machine. I've had three installed for many years and you can be sure they aren't all on the C partition. In fact I never install an OS on the C partition because I might want to reformat and re-install the OS. It's messier to reformat the C disk because that's usually where boot.ini etc. hang out. In the last few years I've encountered very few installers that insisted on using the C disk, and those were old or poorly done and probably not something anyone would want installed anyway. If you have multiple OS's installed you will soon learn not to pay much attention to the drive letter because each installed OS can assign different letters to the same partition. Also the OS setup disk and things like BartPE are apt to assign different letters. I use partition labels. They make more sense than letters and because they are actually stored on the partition, every Windows OS or setup disk will show you the same label for a given partition. Of course the OS does use letters but when I need to know the letter, Windows Explorer or Disk Management will show me the letter.