Comments on: 8.3 backward compatibility, or, why *.dpr returns .dproj files http://blog.excastle.com/2007/10/01/83-backward-compatibility-or-why-dpr-returns-dproj-files/ Life, .NET, and Cats Sat, 11 Oct 2008 09:12:59 +0000 http://wordpress.org/?v=2.5 By: Joe White http://blog.excastle.com/2007/10/01/83-backward-compatibility-or-why-dpr-returns-dproj-files/#comment-5731 Joe White Tue, 02 Oct 2007 14:00:00 +0000 http://blog.excastle.com/2007/10/01/83-backward-compatibility-or-why-dpr-returns-dproj-files/#comment-5731 Wow - that's cool. I didn't know about PathMatchSpec. <br> <br>Unfortunately, pinvoke.net doesn't show there being a managed API for it, and I'd rather not dip into P/Invoke because of the permission issues it raises (not runnable in partial trust, etc.) Wow - that’s cool. I didn’t know about PathMatchSpec.

Unfortunately, pinvoke.net doesn’t show there being a managed API for it, and I’d rather not dip into P/Invoke because of the permission issues it raises (not runnable in partial trust, etc.)

]]> By: Rob Kennedy http://blog.excastle.com/2007/10/01/83-backward-compatibility-or-why-dpr-returns-dproj-files/#comment-5730 Rob Kennedy Tue, 02 Oct 2007 12:56:00 +0000 http://blog.excastle.com/2007/10/01/83-backward-compatibility-or-why-dpr-returns-dproj-files/#comment-5730 Another way is to re-check the long name of the file against the mask as FindNextFile returns them. PatchMatchSpec will do it. <br> <br>I turn off short file name generation. The only program I've seen tripped up by it was Acrobat Reader's installer (version 5 or 6). It was a 32-bit self-extractor that invoked a 16-bit installer to install the 32-bit program. When the extractor created files in my temp folder, it wound up in a folder with spaces in it, which was unfindable by the 16-bit installer. <br> <br>And that's how 32-bit programs end up not supporting long file names, too: Take a 16-bit program that "knows" a file name can never be more than 12 characters, and simply recompile it with a 32-bit compiler. It's now calling the 32-bit FindFirstFile natively, but it still thinks the file name will fit in its 13-character buffer. Another way is to re-check the long name of the file against the mask as FindNextFile returns them. PatchMatchSpec will do it.

I turn off short file name generation. The only program I’ve seen tripped up by it was Acrobat Reader’s installer (version 5 or 6). It was a 32-bit self-extractor that invoked a 16-bit installer to install the 32-bit program. When the extractor created files in my temp folder, it wound up in a folder with spaces in it, which was unfindable by the 16-bit installer.

And that’s how 32-bit programs end up not supporting long file names, too: Take a 16-bit program that "knows" a file name can never be more than 12 characters, and simply recompile it with a 32-bit compiler. It’s now calling the 32-bit FindFirstFile natively, but it still thinks the file name will fit in its 13-character buffer.

]]>