hahaha! I admit I don't know enough to say how the lpt1 issue should be handled. Is there any Win32 call I can make that will help me avoid accidentally opening these magic files? No, because its entirely possible to open these magic files, you'll just find that "accidentally" your output has appeared at your
Hi printer, rather than on disk.
BTW, it appears that wget itself does not handle it. :-) I know, but my hope is that HsWget will :)
BTW, I guess wget should truncate the path at some number of characters.... Fortunately if we have FilePath == String, take n can be used, or more likely joinDirectories . take n . splitDirectories
Windows doesn't use UTF-16, NTFS does.
I was under the impression that NT's Unicode support was conceived when it meant UCS-2. So it uses UCS-2 and not UTF-16, which would mean that you could in principle encounter lone surrogate characters or something equally nonsensical. Yep, true, it uses UCS-2.
Windows has two sets of file system related functions, one for legacy 8-bit character sets, one for Unicode. What happens if I call the Unicode API on a FAT system that doesn't support it? Does it do a half-assed version of the locale specific encoding that we deem impossible and wrong here?
Of course :) And if you use the ANSI API's on a NTFS system you'll also get some dodgy encoding.
Ah, never mind, I get the strong feeling I really don't want to know all this. When even Windows 98 has been end-of-lifed we should rely on the Unicode API, if anything. Windows ME has not been end-of-lifed, and still has native 8-bit.
Thanks Neil