Slashdot Mirror

That is why I love my 925, it only uses 95w, is whisper quiet, and takes any job I throw at it with nary a complaint. I mated it to an ultra cheap 4650 1Gb GPU and so far every game I've thrown at it has been nothing but high framerates and pretty picture, and you can't beat $700 for a PC with 8Gb of RAM, a Tb of HDD, dual burners and a quad. if your board can take one I highly recommend the 925 to future proof your machine. That 8Mb of total cache makes for a damned good video transcoder. Of course if you don't transcode you can get a Propus 2.6GHz for a cheap $99, and after building a couple for customers I can say for most jobs they are truly scary fast and quiet.

As for "speed and snappiness" even on the smaller AMD chips, have you thought about showing your customers one of these? With the free Junction Magic you can set the My Docs and program files to be on a larger HDD and leave the SSD for the OS. These puppies will max out a Sata II connection, and by moving the two most overfilled folders to a large cheap HDD you can get nice long life from the SSD and still enjoy the crazy OS responsiveness you get from SSD without having to break your wallet.

After setting a couple of these up for customers and seeing the truly insane speeds they were getting on even the lowest X2s and X3s I'm probably gonna pick up one for myself. I already would have but Valentine's day is right around the corner and that is one of the "Thou shall not" along with thou shall not forget her BDay or Xmas, and Thous shall not answer honestly if she asks if she looks fat in that dress. But I doubt ARM will get more than the "browser in a box" tiny niche because of the No Windows problem. Everyone just seems to love the new Windows 7 and folks that buy Win 7 for their new machine end up coming back and having me upgrade their second box to Win7 as well. Not having Windows will leave ARM to the cheap netbook niche IMHO.

There is a freeware tool available to do this - Junction Link Magic

Well, there are reparse points (http://msdn.microsoft.com/library/en-us/fileio/fs /reparse_points.asp), which can act like symbolic links, but they only work on directories. There seems to be a program called Junction Link Magic here to make them.

As the other replies said, like a hard link. But NT already has hard links (and symlinks)! There's even an API CreateHardLink to make them, so any Win32 program can do it. This program is a nice GUI to create symlinks: http://www.rekenwonder.com/linkmagic.htm ...and this one creates hard links: http://hermann.schinagl.tripod.com/nt/hardlinkshel lext/hardlinkshellext.html So it shouldn't be too hard to get a native version of ln, by doing something like using MinGW and replacing link(2) with CreateHardLink, and symlink(2) with the necessary FSCTL to make a symbolic link (a.k.a. reparse point)

More related links:
http://shell-shocked.org/article.php?id=284
and the nifty GUI tool:
Junction Link Magic

Now... creating symbolic and hard links in NTFS, and having the boot partition on a separate HD than your C:\Windows (C:\WINNT) directory, well those are options that you have to go without.

NTFS does support hard links for files. Use "fsutil hardlinks create" to do it. At least one person has made a GUI to do it too, check out Hard Link Magic. If you want to link a folder or drive, it's termed a junction point. Read the nitty gritty here. "mountvol" will do it for drives, "linkd" (from the Resource Kit) will do it for folders, and Junction Link Magic will do it thru a GUI.

Shortcuts are MS's version of symlinks, but there are important differences between the two.

Oh and you can't have your boot partition on a different drive than %WINDIR% because that's the definition of the boot partition: where %WINDIR% resides! I think what you meant is your system partition - which is where the boot files reside (Unintuitive? You bet!)...which can in fact be on a different drive than your boot partition. Anyone who has more than one MS OS on their PC can attest to that.

Any application on a given desktop can send a message to any window on the same desktop, regardless of whether or not that window is owned by the sending application, and regardless of whether the target application wants to receive those messages.

I can't share my work because of bandwidth problems, but it was indeed groundbreaking. Through raw HWND handles or Microsoft's (or my own version) of the WinFinder control found in Spy++, one is able to select any existing window in the system. Arbitrary messages can be sent or posted. One can draw pixels over windows, enable disabled controls (as often found in shareware), send text to edit controls (I developed a simple scripting language to automate this process), right/left/middle/double click at any position (useful in closing annoying dialogs, like the dialup reconnection message for those on 56k), and even move or kill any window one choses.

As for the vulnerability itself...its well worth the read. Basically, shellcode is injected into an edit box by removing the CEdit's length restrictions. This is a valuable lesson to all Windows programmers out there -- do not rely on a control's restrictions to validate data! Its as dangerous as using JavaScript to validate web forms. Always in all cases check for buffer limits in the application code.

Of course, not all flaws can be blamed on the application developer:

The final message that we're going to make use of is WM_TIMER. This is a slightly odd and very dangerous message, since it can contain (as the second parameter) the address of a timer callback function. If this second parameter is non-zero, execution will jump to the location it specifies. Yes, you read that right; you can send any window a WM_TIMER message with a non-zero second parameter (the first is a timer ID) and execution jumps to that address. As far as I know, the message doesn't even go into the message queue, so the application doesn't even have the chance to ignore it. Silly, silly, silly...

I've only skimmed the article, but this is the first documented exploit I've heard of in my half a decade of Windows programming. But its worth mentioning that these fundamental flaws have existed since Windows 95, and Foon is correct in that there's absolutely nothing Microsoft can do about it, except ditch the current Win32 API and start anew. Guess we'll have to wait until Longhorn. -sr