Registry Key and Values

When security settings are set in Windows XP, the following registry key is used:

The values are:

• ForceGuest=1: Use this value to force guests on
• ForceGuest=0: Use this value to force guests off

Actually, the purpose of the ForceGuest registry key is to turn on or turn off the "classic" Security Tab so administrators are able to change the rules in Discretionary Access Control Lists.  DACLs are associated with directories and files.  The default for some SKUs of Windows XP is to make the security tab in Windows Explorer go missing.  This has something to do with the "Guest" user being "forced" to logon in some peculiar way when a computer belongs not to a Domain but to a Workgroup.   It was decided 10 or 15 years ago that having a Guest logon to a Workgroup posed a major problem if the Security tab were to remain available by default.  So it was whisked away and the ForceGuest key was born with this lame "explanation."

This isn't a technical problem so much as another iteration of the inability of puzzler-style technologists to describe and explain what they decide to do and why.   Now, if I want the Security tab to appear, do I want to force guests on or do I want to force guests off?   I dunno.

Configuring Windows XP Mode Networking to Be a Presence on Your LAN

If you logon under James then using Windows Explorer,  open the folder

C:\Users\James\Virtual Machines

on the real machine (the one that hosts the virtual machine).  Right click on the shortcut to the VM and click on Settings.  Find Networking/Network Adapters in the table and change the setting on the virtual NIC to the name that matches the NIC hardware (e.g. RealTek) in the real (host) machine.  Reboot and perform IPCONFIG /ALL on the VM to see that the VM has been assigned an IP address on the same network as the real machine. (11/12/10)  

1) Verify that the processor of the physical computer has a supported version of hardware-assisted virtualization.

2) Verify that hardware-assisted virtualization and hardware-assisted data execution protection are enabled
   in the BIOS of the physical computer.

   (If you edit the BIOS to enable either setting, you must turn off the power to the physical computer and then turn it back on.
   Resetting the physical computer is not sufficient.)

3) If you have made changes to the Boot Configuration Data store, review these changes to ensure
   that the hypervisor is configured to launch automatically.

In my case I had no way of knowing whether my expensive server contains hardware for hardware-assisted virtualization (supported version or NOT).  It isn't printed on the system unit case.  It isn't reported by any of Microsoft's tools.

It turns out there is a BIOS setting that is DISABLED by default.  That means I must ENABLE it to run Hyper-V.  Presumably those computers that have it enabled take a performance hit.   But you won't find information on that.  

The phrase "the hypervisor is not running" refers to what?   A hypervisor is an operating system that hosts operating systems.  If it isn't running, what do I gotta to do get it running?  And what do I care if it is running or not?   That's a problem for Hyper-V to deal with.  

There is a note about BOOT.INI, which has transmogrified without notice into the Bootstrap Configuration Data store.  Apparently Hyper-V is dependent on one or more (we don't know which) settings inside the aforementioned store that is (are) responsible to launch the hypervisor automatically.

In an ideal world, this aside from Hyper-V would include by reference documentation that is specifically written to help people who are new to Hyper-V to use Hyper-V.  Alas, there is no such reference.  Pity.

It isn't always obvious that the black thing with the button is or is not a burner.

AndyC said:

earnshaw said:

*snip*

"Also new in Windows 7, you can map a network share to a drive letter and Windows 7 will not reliably recognize it in the command shell.   NET USE works reliably to do the same thing."

 

Elevated command prompts (and elevated processes in general) won't see drive mappings that were made un-elevated (and vice-versa). This is partially down to the mechanism used by Windows to perform elevation and partially down to the fact that relying on drive mappings being available in both contexts would cause a whole raft of compatibility issues when using over-the-shoulder elevation.

I withdraw my "thousand pardons."   If you change the Start In directory in a shortcut on the desktop, it works as it should.   If you change the same thing in a shortcut on the Start Menu, the change you make is IGNORED.  This is a capital BUG.   I expect a fix for this will appear within a week on Update Tuesday.   By the way, what is an "Over-the-Shoulder" elevation?

CannotResolveSymbol said:

Sven Groot said:

*snip*

Same here.  I tried it on Windows 7 before I posted to make sure that it works.

A thousand pardons.   I tried it AGAIN here and now it works.   After all, it SHOULD work.    

W3bbo said:

"So, what is the official received way to get the initial current working directory the way I want it in CMD.EXE?"

 

cmd /k "cd %1"

 

 

Excellent.  It works exactly the way I wanted it.  Thank you. 

CannotResolveSymbol said:

Sven Groot said:

*snip*

Or just set the "start in" directory of the shortcut you're using to open cmd.exe.

Or just set the "start in" directory...

That is the first thing I tried.   It doesn't work on Windows 7.

Also new in Windows 7, you can map a network share to a drive letter and Windows 7 will not reliably recognize it in the command shell.   NET USE works reliably to do the same thing.  

figuerres said:

Yeah seems silly for .net to have a limit like that.

 

I know that I have seen a few programs - one was a MSFT addon for VS that had issues with folder and filenames beeing to long.

very frustrating esp. when some of the problem came from folders with names that MSFT created!

 

today I would say that WIndows and .Net should drop the "MAX_PATH" limit and just warn that at some point a large name or path might not work.

 

but we should be able to have as many folders as we care to manage. to nest them as deep as we want. and to name files just about as long as we care to.

 

And I would drop the .xxx crap.  in place have a 32 bit int that id's the "file type" in a table and put that int in the files meta-data.

so we do not need .docx to have the pc know that it's a word file.

On the Univac 1108 operating system (before you were born) there were things called program files that contain elements.  Elements are symbolic, relocatable, absolute, and omnibus.  Symbolic elements are simple text files.  They have a maximum 12-character element name and a maximum 12-character version name.  Also included is a six-bit symbolic type so you can tell a Fortran program from a COBOL program.  Your idea of a 32-bit property in metadata is thus proven to work.   MSFT has been trying to hide the filename extension by making it disappear from Windows Explorer unless you decide not to go with the default.  Seems kinda lame to have a file type identifier be part of the name of the file.  Worked in the Windows progenitor operating systems.  But this is now 30 years on. 

Also, this arbitrary and capricious character limit obviously came about to cater to the needs of C language programmers who would routinely declare a static, one dimension array of characters to contain just about any fully-qualified filename that you are likely to encounter.  Just so Mister C Programmer could aim at something, a limit was established.  That was well before the advent of the native string class, which is far more natural to code with than arrays of characters that terminate in a NUL character.