Re: [fpc-devel] Linux ELF executable file size
On Sun, 6 Jan 2013, Leonardo M. Ramé wrote: Here's an interesting article about getting the smallest possible ELF executable size: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html Well. It actually works on the latest 64-bit kernels as well :-) but the standard file util have some problems with it: home: >file a.out a.out: ELF 32-bit invalid byte order (SYSV) Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Linux ELF executable file size
Here's an interesting article about getting the smallest possible ELF executable size: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html Leonardo M. Ramé http://leonardorame.blogspot.com___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)
On Sun, 6 Jan 2013, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: IMO resource strings are for display purposes, so that UTF-8/16 encoding is expected by an OS API. AFAIR Win32 string resources are stored in UTF-16, You are very much wrong. Not really. I was talking about Win32 resources, not about what FPC makes from resourcestring. The discussion is about unnecessary conversions in *FPC resourcestrings*, not about win32 resources. Why you brought up the Windows resourcestrings was (and is) a mystery to me. From your statement, I assumed that you probably thought FPC stores it's resourcestrings as win32 resources. It does not. To start with, resource strings are not stored as Win32 resources. Secondly, they are stored in the code as an ansistring. The resource string of the above example is stored as: .globl _$PROGRAM$_Ld2 _$PROGRAM$_Ld2: .ascii "Something\000" .balign 8 .short 0,1 .long 0 .quad -1,15 .globl _$PROGRAM$_Ld3 Thirdly: in my apps, no UTF-8/16 encoding is expected by the OS. If it were, I would have used widestrings instead of ansistring to begin with, and in that case I would not have made any remark... I don't know which OS you're using, but the WinAPI uses UTF-16 throughout. I use both windows and Linux. You are mistakenly assuming that I am using Windows GUI calls or so. There is no GUI. Probably the only call that cares about codepage is FileCreate(), and that is not done using resource strings. For the rest, all is done using FileWrite() and sendto()/recvfrom(). Both do not care about encoding. They transfer bytes, that's it. So I use ansistrings throughout. And hence, resourcestrings being stored in unicode format would cause totally unnecessary conversions. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)
Paul Ishenin schrieb: 05.01.13, 23:54, Michael Van Canneyt пишет: You are very much wrong. To start with, resource strings are not stored as Win32 resources. I personally think that resources should be stored in their native formats where is possible. This will allow to change them using software designed for that environment. For example for windows there are many resource editors which can replace icons, bitmap and string resources too. It would be nice to have this ability also for binaries which FPC do. On OS X resources are also stored different from what FPC do currently - they are stored in application bundles as I know, so they can be edited by external programs too. Point taken :-) But I'm not sure about nowadays use of native resources. Even on Windows most programs nowadays don't use Windows resources for their menus, dialog boxes etc. any more. I've used the Delphi ResourceWorkshop for some time, to tweak some third party programs and even Windows itself. This will be almost impossible with current software. Try e.g. to set the Windows menu color to yellow, what I did for a long time, and you'll find out that the Explorer and many other Windows tools don't honor that setting. Or you'll find that these system settings have been removed at all, replaced perhaps by themes? So I'm not sure about the use of native resources, nowadays. How should a multi-platform application handle a string or graphical (icon...) resource, so that it can be designed on one platform, and be shown on all other platforms without modifications? With graphical resources I'd use a single internal (FPC) format, which is converted by the widgetset for use on the target platform. String resources may require more adjustments than only a translation, to match the different semantics of other languages - independently from the target platform. That's why I'd suggest UTF-8 encoding for resource strings, what doesn't affect program logic because AnsiString still can be used. The *encoded* AnsiStrings require that the coder knows about the best encoding of every string, when he wants to reduce the number of implicit string conversions. Using AnsiString(CP_ACP) may be a reasonable decision for use in a program with *very* limited usage (one country, one language, one target platform...), but FPC should support programs with a broader audience as well. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)
Michael Van Canneyt schrieb: IMO resource strings are for display purposes, so that UTF-8/16 encoding is expected by an OS API. AFAIR Win32 string resources are stored in UTF-16, You are very much wrong. Not really. I was talking about Win32 resources, not about what FPC makes from resourcestring. To start with, resource strings are not stored as Win32 resources. Secondly, they are stored in the code as an ansistring. The resource string of the above example is stored as: .globl _$PROGRAM$_Ld2 _$PROGRAM$_Ld2: .ascii "Something\000" .balign 8 .short 0,1 .long 0 .quad -1,15 .globl _$PROGRAM$_Ld3 Thirdly: in my apps, no UTF-8/16 encoding is expected by the OS. If it were, I would have used widestrings instead of ansistring to begin with, and in that case I would not have made any remark... I don't know which OS you're using, but the WinAPI uses UTF-16 throughout. I suppose that other OS also use some Unicode string representation, for lossless representation of texts of all languages. The dual W/A interface of Win32 is due to the stripped-down Win9x versions, which require Unicode extensions for supporting more than CP_ACP. But now we are in 2013, with Unicode being present everywhere. So the conversion really would be 100% totally redundant. It may look so to you... Why then do you use resourcestring instead of ordinary string constants? Another note and question, about multi-lingual resources. Windows resource scripts (.RC) allow for multi-lingual stringtables. In my recent research I learned that the resource compiler extracts the requested language from the script, and stores only these strings in the resource file (.RES) and application (.EXE, .DLL). That's why resourcestring was added to Delphi. How does FPC support the same? (.PO files?) DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
