Re: [fpc-pascal] Unicodestrings and Assign(File)
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 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. 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. > 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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FpProfiler patch to compile with fpmake
Hi, I'm not sure if anyone is actively watching the Mantis issues for FpProfiler, so I thought I'll mention it here: I submitted a patch to fix the compilation with fpmake from command-line. It's on http://bugs.freepascal.org/view.php?id=21991 Regards, Michalis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicodestrings and Assign(File)
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
Re: [fpc-pascal] Unicodestrings and Assign(File)
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 印場 乃亜 : > 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
[fpc-pascal] FPC and (minimal) telnet
I'm using the ltelnet unit to good effect in a special-purpose terminal emulator which doesn't merit e.g. Synapse, although since it's not part of the the fcl I'm having to build it specially. I find that if I try to use it to connect to the Hercules mainframe emulator it fails since the terminal type subcommand is not supported. If anybody else is using it (or if Ales is reading this) I'd be interested in any suggestions as to how best to add this facility (i.e. hardcoded internally, subcommands passed to a callback, etc.). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicodestrings and Assign(File)
Hello Jurgen, I'm assuming that everyone is aware of the solution for this. Every unicode file name still has ANSI-dos name (aka ShortName). You could write a function that would return a short name based on unicode name of a file. And pass the short name to Assign File function. thanks, Dmitry On Wed, May 9, 2012 at 11:46 AM, Jürgen Hestermann wrote: > Is it (already) possible to use Unicodestrings for file paths? > I was able to access long paths (with many hundreds of characters) > in the windows API functions FindFirstFileW (with Win32_Find_DataW > data type) but I failed to open such files with Assign(File)/reset. > Are they converted to (one byte) Ansistring internally? > Am I forced to use CreateFile or similar function to open such files? > > ___ > 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] Re: Unicodestrings and Assign(File)
On 13-5-2012 5:59, dmitry boyarintsev wrote: > I'm assuming that everyone is aware of the solution for this. > Every unicode file name still has ANSI-dos name (aka ShortName). > You could write a function that would return a short name based on > unicode name of a file. And pass the short name to Assign File > function. > > thanks, > Dmitry Hi Dmitry, Do you mean the ShortName as the 8.3 name defined on this page: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#file_and_directory_names ... it states "When you create a long file name, Windows may also create a short 8.3 form of the name, called the 8.3 alias, and store it on disk also." So it isn't compulsory to store the 8.3 filename - which is confirmed later on by: "8.3 aliasing cannot be disabled for specified volumes until Windows 7 and Windows Server 2008 R2."... implying it can be disabled in Win7 and 2K8R2 Looking at the GetShortPathName function http://msdn.microsoft.com/en-us/library/windows/desktop/aa364989%28v=vs.85%29.aspx ... the text itself only says the function can fail - not when it is likely to failx. Comment below does shed more light: "GetShortPathName fails to create a short filename if the file doesn't have a short file name."..."You can turn this option off by using the "System Policy Editor" (Poledit.exe). Certain file systems also don't support creation of short names by default" Or are you talking about a different way of getting a short name? Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Unicodestrings and Assign(File)
That's the one I'm talking about. thanks, Dmitry On Sun, May 13, 2012 at 12:52 AM, Reinier Olislagers wrote: > On 13-5-2012 5:59, dmitry boyarintsev wrote: >> I'm assuming that everyone is aware of the solution for this. >> Every unicode file name still has ANSI-dos name (aka ShortName). >> You could write a function that would return a short name based on >> unicode name of a file. And pass the short name to Assign File >> function. >> >> thanks, >> Dmitry > > Hi Dmitry, > > Do you mean the ShortName as the 8.3 name defined on this page: > http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#file_and_directory_names > ... it states > "When you create a long file name, Windows may also create a short 8.3 > form of the name, called the 8.3 alias, and store it on disk also." > So it isn't compulsory to store the 8.3 filename - which is confirmed > later on by: > "8.3 aliasing cannot be disabled for specified volumes until Windows 7 > and Windows Server 2008 R2."... implying it can be disabled in Win7 and > 2K8R2 > > Looking at the GetShortPathName function > http://msdn.microsoft.com/en-us/library/windows/desktop/aa364989%28v=vs.85%29.aspx > ... the text itself only says the function can fail - not when it is > likely to failx. > Comment below does shed more light: > "GetShortPathName fails to create a short filename if the file doesn't > have a short file name."..."You can turn this option off by using the > "System Policy Editor" (Poledit.exe). Certain file systems also don't > support creation of short names by default" > > Or are you talking about a different way of getting a short name? > > Thanks, > Reinier > ___ > 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
