Windows 7 to XP FIle Sharing Problems

Recently, I had serious issues with trying to enable file sharing between my newly-installed Windows 7 laptop and my Windows XP SP3 desktop.

Windows 7's Network and Sharing Center

I have a home wireless network, where my Windows 7 laptop, on wireless, normally shares files perfectly well with my Windows XP desktop. Inexplicably, one day the capability to share files via wireless ended; I couldn't even ping my XP desktop from my 7 laptop let alone browse its file shares, whether by computer name or IP address. And yet, over a wired connection, file sharing performed flawlessly!


Here's a list of what I tried:

• Updated drivers for network hardware.
• Disabled Windows Firewall on both machines.
• Verified internet connectivity from the laptop.
• Ensured both PCs share the same workgroup name.
• Verified connectivity over wireless, from the laptop to the router.
• Completely reinstalled the TCP/IP stack on the Windows XP computer.
• Deleted and recreated routes using the ROUTE command on both computers.
• Reinstalled the Link Layer Topology Discovery (LLTD) responder on the XP box. 
• Followed Microsoft's docs on enabling File and Printer Sharing under Windows 7.
• Verified that shared folders on both PCs had proper permissions.
• Removed remnants of Norton Internet Security with the Norton Removal Tool from the XP box, which I'd long since uninstalled but remnants of which still remained.
• Followed Microsoft's steps for sharing files among different Windows versions, including rerunning the network setup wizards for each respective operating system.

In spite of all these steps, I still couldn't even ping the XP box from the 7 laptop, and I couldn't see the XP box from the 7 laptop in the network, although I could see, but not access, the 7 laptop from the XP box.

The solution turned out to be unexpected.

A few years ago, I replaced the factory firmware of my venerable Buffalo WHR-HP-G54 wireless router with DD-WRT, a free, open-source, Linux-based firmware which can be applied as a drop-in replacement for the manufacturer firmware, and can expand the features of your router to boot.

The firmware, as with most anything in IT, is evolving, and it'd been some months since I'd last updated the version of DD-WRT; it was v24 SP1 from around August, 2010, whereas the newest version is v24 pre-SP2. Some other DD-WRT users had reported issues sharing files on their own networks. DD-WRT itself has an option under Wireless => Advanced Settings called AP Isolation, which allows you to prevent wirelessly networked devices from interacting with one another, and presumably with wired clients, via the router (in my case, this option has always been disabled).

At this point, my options were exhausted, so I took the plunge and updated the DD-WRT firmware. Even though the latest version is technically still in beta, it seemed worth a shot; I've never had trouble since first installing DD-WRT, and the fact that it allows you to preserve your existing settings without wiping the router's NVRAM made it even more appealing.

The result? It worked! Suddenly, rather than being met with the dreaded System Error 53 when attempting to map a network drive letter from the laptop to the desktop or trying to browse to a shared folder via Windows Explorer, I got a prompt asking me to authenticate to the XP box using my credentials, and finally regained access!

If you haven't updated your router's firmware in a while, it might be worth a shot, particularly if you use DD-WRT as I do and have perhaps encountered what might be a bug in your current version of the firmware. 

If you still have the factory firmware, I'd strongly suggest you consider replacing it with DD-WRT or another like Tomato, which can not only offer your router and network more stability and performance, but also unlock features that the manufacturer might not even offer in their own relatively anemic firmware. 

Running an Ancient dBASE IV Database from Removable Media

I needed to run a particular DOS application from CD, USB, or other removable drive.

This particular application is a database of local community service agencies built in dBASE IV, allowing the user to search among service providers or do keyword searches of available services.

It's nice because the contact and services information for hundreds of agencies could fit neatly on a 3.5" diskette, but not so nice because it's a DOS-based app. The app for my purposes needed to be able to run from CD or USB flash drive, the goal being to be able allow the user to easily assess and play around with its features, and have a functional replica to use in refactoring its functionality into a more up-to-date database and user interface platform. That, and the fact that the computer to use for testing has no 3.5" diskette drive installed.

In the interests of time, I decided to create a batch file to execute the app. One twist, however, is that the app must run from the C: drive, because it's hard-coded to reference the primary hard drive in a PC.

I decided to create a batch file which would perform the following steps:

1. Create a new folder on the temporary file area of the C: drive.
2. Copy all files from the removable media to the new folder.
3. Execute the DOS app.
4. Upon exit, delete the folder from the C: drive.

The app would be running from within a DOS command prompt under Windows XP. One quirk, as CPU clock speeds have increased over the years, dBASE IV has issues which prevent it from executing normally on its own. Specifically, dBASE attempts to perform some temporary file housekeeping based on the system clock, and on any system faster than oh, 133 MHz or so (at least in my testing), dBASE would fail to launch.

Thankfully the utility IDXFIX proved to be the magic bullet for this little problem, my thanks to Gary White, creator of this, wherever he may be. This utility just needs to be run prior to dBASE to set up shop for it and presumably intercept and handle requests dBASE makes when trying to interface with the clock.

Here's the batch file, an explanation follows.

@ECHO OFF
CLS

md %temp%\myProg
xcopy *.* %temp%\myProg /s /e /v /y
cd %temp%\myProg\dbase
idxfix /I
dbase.exe %temp%\myProg\db\myDB.prg
idxfix /U
cd %temp%\
del %temp%\myProg\ /s /q
rd %temp%\myProg\ /s /q

Now on to the explanation.

@ECHO OFF
CLS

• Just tells the command prompt to not echo commands, and to clear the screen. In a way redundant, but this is habit from when I had to write batch files more frequently, and it does make testing a little cleaner.

md %temp%\myProg

• This simply looks at the %temp% environment variable, which in Windows XP references the folder on the Windows install drive where temporary files are stored. By default this references a folder under C:\Documents and Settings\<userName>\Local Settings\Temp. I just changed this on the target system to a folder I created named C:\TEMP, for simplicity and to avoid any potential issues with long file names with this old DOS application.
  

xcopy *.* %temp%\myProg /s /e /v /y

• This uses the command-line xcopy program to copy the entire file and folder structure from the removable media to the temporary file area on the C: drive. The parameters tell it to copy subdirectories, include empty subdirectories, verify the results, and automatically overwrite any existing files.
  

cd %temp%\myProg\dbase

• Change directory to the dbase subfolder copied from the removable media. This is the folder where the dBASE executable, dbase.exe, lives.

idxfix /I

• This loads the IDXFIX utility into memory as a TSR, short for Terminate and Stay Resident. The utility's execution doesn't stop any further actions in this particular instance of the command prompt, but still hangs out in memory to serve whatever purpose, in this case ensuring dBASE can execute properly.

dbase.exe %temp%\myProg\db\myDB.prg

• This executes the dbase.exe executable and tells it to load the file myDB.prg, which represents the database application.
  

idxfix /U

• When the batch file gets to this point, the user has quit dBASE. Thus, we unload the IDXFIX utility from memory.

cd %temp%\

• Ensure we've changed to the temporary folder, so that our focus is NOT inside the folder or any subfolders of our copy of the database application. If this were the case, the next steps to remove the application files and folders from the target computer's hard drive would fail.
  

del %temp%\myProg\ /s /q

• Deletes files contained in the database application folder. The /s parameter ensures all files in all subfolders are deleted, while /q tells the delete operation to not ask for confirmation. We know what we're doing!
  

rd %temp%\myProg\ /s /q

• Removes the folder and all subfolders. Another option would've been to utilize the DELTREE executable, but DEL serves the purpose just fine as it's integrated into the XP command prompt, whereas DELTREE is a separate executable we'd need to store on the removable media.

In summary, this batch file has enabled us to run this ancient DOS-based database application comfortably from within a Windows XP command prompt. It sets up shop for itself on the C: drive, executes and enables the user to use the full functionality of the database, then wipes traces of itself from the hard drive upon exit.

This is a task which in a way seems rather pointless. However, these steps have enabled us to take an old DOS database application which previously could only run from a 3.5" diskette, and essentially make it portable so that it can now be run from any removable media.

If during some natural disaster or other crisis, someone needed this particular database to view on a laptop with no wifi handy, these steps would enable this accessibility.

A Problem Sharing Files via Remote Desktop

While on vacation, I'd left a PDF on my home computer which I wanted to browse on my laptop on vacation. It's about 75 MB, not exactly feasible to email.

Both machines run Windows XP, however, and I figured I could use its ability to bring the resources of my laptop, including its hard drive, to the remote session on my desktop at home. I opened Remote Desktop, expanded Options, then clicked on Local Resources, and checked so that sharing all available drives was enabled.

No such luck, at first. Although I could see the laptop's CD-ROM drive present as \\TSCLIENT\D its hard drive, which should've been there as \\TSCLIENT\C was nowhere to be found! My laptop is a machine I normally use at work, and is part of their Active Directory and various group policies. I'm not privy to what the group policies specifically secure, but my guess was that some policy setting might be responsible for making my drive inaccessible via the remote session.

After some thought I remembered an old friend from the DOS days, the SUBST utility.

When diskettes were popular, some developers hard-coded their software specifically to look for the A: drive, with no option to select another. This was fine if you had a newer PC with a 3.5" drive as A:, but what if you'd upgraded some old clunker which had an older 5.25" drive as A:, and a newly installed 3.5" as B: instead? You'd be stuck having to crack open the case and swap around the drives... if not for SUBST.

I decided to try SUBST here to see if I could bring my laptop's hard drive to the remote session, masquerading as a different drive letter on \\TSCLIENT. Thus, I opened a command prompt and entered the following from my laptop:

SUBST Z: C:\

This basically tells your computer to use a given substitute drive letter Z: to represent drive C: which is somewhat similar to using symbolic links in the *nix world. I opened My Computer, and now I could see a Z: drive, and clicking it brings up an Explorer window with the exact contents of my C: drive.

Now, I open Remote Desktop, and open a session to my home computer. Lo and behold, drive Z: appears in the remote session as well! I could then Paste my PDF file from my home machine to my laptop and browse it happily. Of course, this copy process takes a LOT longer than it might over a normal, unencrypted connection, but it gets the job done, and sometimes that's all that matters.