Windows XP comes with RDP 5.1, Windows 2003 comes with RDP 5.2
You can download RDP 5.2 @
Remote Desktop Connection for Windows Server 2003 [5.2.3790]
RDP 5.2 has an auto-reconnect option that is very useful over a bad connection.

But one issue I've always had with it is that even after installing RDP 5.2 on XP, when you type "MSTSC" at a command prompt (which I very often do) RDP 5.1 is loaded. This is because the RDP 5.2 installer places it's files @
"C:\Program Files\Remote Desktop\mstsc.exe"
while the original RDP 5.1 files are still in your path @
"%WinDir%\mstsc.exe"
Naturally the RDP 5.1 client is run in this case.
So I fixed this annoyance with this little script.



Resources:
Remote Desktop Connection for Windows Server 2003 [5.2.3790]
fsutil

BTW, since I actually only use this script when building Windows 2000 systems (I only build servers), I think that on an XP system, you might want to delete the old v5.1 files in %WinDir% before creating a hard link to the new v5.2 files in %ProgramFiles%.

Many thanks for the easy way.

Is fsutil only available in Windows XP Professional or freely downloadable on MS ?

fsutil is included on Windows XP and Windows 2003, I don't recall where I downloaded a copy from or if I just copied the binary from Windows 2003 to Windows 2000. Looking at the version number of the file on my ISO it says build 2600, so I guess I just copied it from an XP system.
It works fine in Windows 200 though. I can't say if any other functions other than "hardlink" work in Windows 2000 though since thats the only function I used.

Nice, gonna have to add this to my unattended CD

Just tested out trying to install this on XP. The silent install ended suspiciously so I ran it manually. It said that it couldn't install because "the currently installed OS already runs a copy" (even though it's 5.1). I wonder why it can't just update the component.

Did you have the RDP 5.1 client open at the time by any chance?

I didn't think so, but I had been connecting to my home PC from work earlier in the day so that might explain it.

removed

Copying the files will work just fine, but the next time you upgrade the files in %ProgramFiles% you will have to copy the files to %WinDir%\system32 again.
Also it's a disk space issue, why have two copies of the same program on disk when one will do?

If you ever used UNIX a lot you know what I mean ;-) Us old timer refugees from IRIX are still stuck in the old (right) way of doing things...

...a copy of a Dilbert cartoon in which Dilbert, the long-suffering corporate software engineer, encounters a portly, bearded, hairy man of a certain age--a bit like Santa Claus, but darker, with a certain edge about him. Dilbert recognizes this man, based upon his appearance and affect, as a Unix hacker, and reacts with a certain mixture of nervousness, awe, and hostility. Dilbert jabs weakly at the disturbing interloper for a couple of frames; the Unix hacker listens with a kind of infuriating, beatific calm, then, in the last frame, reaches into his pocket. "Here's a nickel, kid," he says, "go buy yourself a real computer."
In the Beginning was the Command Line

removed

removed

I get the distinct impression that you have no idea whatsoever of what I was talking about.

Let me try to explain:
In the UNIX way of doing things, efficiency is paramount. That means not having duplicates of any files on your system if it can possibly be avoided. This of course was all born out of necessity when computers had only a few megabytes of RAM and disk space and efficiency was an absolute necessity. Today people just don't care if their installer drops a huge duplicate file in the system path, most people would never notice it anyway on a 100GB drive.
So unlike in Windows where there were traditionally no means to have one file be in two place at once, UNIX has two such ways of doing such things, hard links and symbolic links.
Hard links are simply a duplicate entry in the inode (FAT) table that describes where a file is. So a file could exist in many different directories at once and yet have only a single instance exist on disk.
Symbolic links are essentially the same thing but can span different volumes.

As to placing files in the system folder, it's one the (un)written rules that Microsoft frequently break that no files should be placed in the system folder. In the UNIX world few reputable software authors would dream of placing a bunch of libraries in the system folders, instead you create an environment variable that tells the system where to find your libraries. In fact more and more Windows system administrators are demanding that applications should not place any DLLs in the system folders. Guess who the biggest culprit to blame here is though? That's right, Microsoft, they can't even follow their own rules. If nobody placed DLLs in the system folder then DLL hell would never have existed. UNIX sysadmins just shake their heads and laugh at the very idea.

And as to the idea of just dropping in the two RDP 5.2 executables in the system folder and expecting them to just work when called on. Well this is Windows remember and don't you forget it!
This might work on XP but I'd doubt that it will work on a Windows 2000 system. The RDP client needs to be registered in the system so that RDP files can be acted upon if clicked on and so on. Somehow I doubt that the MSTSC binary is so smart that it contains all the logic to re-register itself if it notices that it's not correctly registered...

And if the next version of the RDP software installs to a different folder than it did before, that that doesn't say much for the talents of its install package creator. In fact the very fact that the 5.2 install does not correctly update the 5.1 version that's already on disk on an XP system really shows how badly this package is written.

And here is the Dibert strip in question.


-----------------------------------------------------------

Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.
Anonymous

removed

I ran modifype followed by makecab on the two 5.2 files.
Then i dropped both into into the i386 dir replacing the existing files.

Installs perfectly, works perfectly.

[all this on the RC1 of SP2 - build 2096]

Shark007

removed

Its this: http://unattended.msfn.org/xp/hacked_files.htm

removed

I think that we can agree to disagree and be civil about it.
I still don't think that you quite get the concept of hard links though...

removed