does TFileStream use the same code as assign ? you could create a TFileStream instance and then use AssignStream to a regular file type and keep on using plain old read/write...
not tested here, but could be worth a try... 2012/5/12 印場 乃亜 <shir...@galapagossoftware.com>: > Hi, > > On 2012/05/12, at 18:31, Jürgen Hestermann wrote: > >> Noah Silva schrieb: >> > Thus, the only question would be whether you have to manually convert a >> > UnicodeString to a UTF8String or not. >> >> No, that would not help. Under Windows you can access long paths *only* when >> using special functions (i.e. FindFirstFileW instead of FindFirstFileA). And >> these functions need unicode (widechar) paths strings with a prepended >> '\\?\'. There is no other way to access long paths under Windows. Simply >> converting Unicode to ANSI may let me use most (but not all) Unicode >> characters but the paths would always be restricted to MaxPath (about 260) >> characters. Only when using API functions ending with a W I can access >> longer paths (up to 32000 characters) and these > > Ah, I forgot about that little detail. Given that, it doesn't really make > sense to use the *A versions at all in Windows (Unless you want to support > very old Windows versions). Thus the approach for Windows should be the > opposite of Unix, I suppose. UTF8 or ANSI gets converted to UTF16 and call > the *W functions. > >> string *must* be Unicode (widechar). So the RTL needs to be rewritten to >> allow Unicode paths handed over without conversion and then use Windows API >> functions with the W at the end. >> > I'm surprised this isn't available already. The 260 char path limitation is > pretty severe these days. > >> Because this is not the case (yet), I was wondering, whether it is possible >> to use other Windows API functions like CreateFileW and then somehow connect >> them to RTL file data structures so that I can replace "assign" and >> "reset/rewrite" by Windows API functions and then be able to use "readln" on >> such (text) files. >> > I'm sure it's possible somehow since those structures probably track the > Windows file handle, but it wouldn't be very portable or future-proof. > >> > Still, fixing Assign/Reset/Rewrite would be better than using Unix calls, >> > because you could submit a patch to save everyone else trouble in the >> > future. >> >> Yes, I would like to but neither time nor knowledge allows me to do that >> currently. > > I have the same time problem, but I will take a look at the source code, I > don't think it should be very difficult to figure out. > > Thank you, > Noah Silva >> >> _______________________________________________ >> fpc-pascal maillist - fpc-pascal@lists.freepascal.org >> http://lists.freepascal.org/mailman/listinfo/fpc-pascal > > _______________________________________________ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
