allen2

The dset report should give you more information than the binary of the tool itself. The password protected archive created by dset is protected with the password : dell.

Cmd alone should also close. You might need to run cmd /k if you want to keep the cmd windows open.

If it is for file sharing, there is least ftp but you'll need a tool to properly integrate it in the shell. Old IE (IE 6) and OS (2K,XP at least) could do this using iis ftp and typing ftp://login:password@remoteserver/reltive_ftp_path in an explorer windows would allow to browser the remote as unc path would.

There is something called restricted groups that you can enable through GPO that will most likely do exactly what you want without any need of user interaction.

Perhaps you might begin by : - explaining what is wrong exactly - exactly what you did and how you did it - post the exact model of your mainboard.

This fact is most likely due to at least 4 things: - most developers didn't need the x64 big registers in the first place (they were already using alternate ways) and most companies didn't want to spend money on this transition. - Microsoft and Intel didn't "push" it to the end users as it was done in the past. In the past every new computer was sold with windows 95 without the buyer agreement (that was illegal and there were many law suits). - Compatibility with older apps wasn't fully there and there was a lot of apps (much more than when windows 95 appeared). - There were also a lot less computers. Now computers are everywhere and replacing all of them or only their OS might be very expensive.

The cons: Some x86 might not work as x86 on x64 isn't fully compatible but those are rare exceptions (most of the problematic apps comes from those with drivers that doesn't exist for x64). Some drivers doesn't exist at all and you'll need a VM or equivalent. Some dos apps/games won't work unless run in dosbox. Etc... The pros: Your apps will be able to use natively all ram. You'll get a little longer support (1 year) as Windows 2003 x64 is using the same binaries the hotfixes and security fixes will work on XP x64. You'll begin the transition to x64 that will happen sooner or later.

It "should" work also for any other board based on the same chipset unless they changed the way it install. Most of the time you can still find solution to get drivers working for an officially unsupported OS by using those from another OS. Wifi should be independant. Also the lan drivers for XP taken from either intel or asus (choose the lan driver for windows 7 32bits but anyway the package seems to contains all os) should work on XP. The problem will be the usb 3 drivers as intel doesn't provide usb3 real drivers for XP but only null drivers (so usb3 ports become usb2). As for audio, the realtek drivers (provided by Asus for win7 again the package seems to support all os) should work. So the real problem is most likely, do you want to buy a mainboard and install on it an unsupported OS (for example linux isn't listed as a supported OS but it will most likely work perfectly (intel usb3 is supported under linux)) ?

Hum, intel is still supporting XP with 8 chipset series for its own boards: https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProdId=3683&DwnldID=23061&ProductFamily=Desktop+Boards&ProductLine=Intel%C2%AE+8+Series+Chipset+Boards&ProductProduct=Intel%C2%AE+Desktop+Board+DB85FL〈=eng

Did, you tried with diskpart ? Also, perhaps, you'll need to remove the existing partitions (be sure to make backups of the data stored there) and recreate a new partition scheme after a clean (it will wipe all from the select drive so be careful) from diskpart.

If you want to have your bios set to localtime then this should help.