I'm testing with FPC/Lazrus on Windows now, but a simple program results in 11.5 MB size.
I have enabled -Xs, -CX, -Og, -O2 in the project->compiler options (Lazarus), but the size is still the same.
Anything else I should do?

Paul

Use
strip --strip-all $PROGRAMNAME.exe
after the compiling.

mfg
Michael

And if you want to shrink it more, try UPX.
http://upx.sourceforge.net/

mfg
Michael

> I'm testing with FPC/Lazrus on Windows now, but a simple program

results in 11.5 MB size.

> I have enabled -Xs, -CX, -Og, -O2 in the project->compiler options

(Lazarus), but the size is still the same.

And if you want to shrink it more, try UPX.
http://upx.sourceforge.net/

mfg
Michael

I've read that, but isn't it suppose to work within the ide instead of always start the cmd prompt and type in this ?
(or use a batch)
Will this work for WinCE also, cause this what I actually want to do?

Paul

I've read that, but isn't it suppose to work within the ide instead of always start the cmd prompt and type in this ? (or use a batch)

Project -> Compilersettings -> [Last Tab] -> Execute after (I hope this is right, i've only the german version here).

Will this work for WinCE also, cause this what I actually want to do?

Don't know.

hth
Michael

I have to use:

C:\FPC\2.2.2\bin\i386-win32\strip.exe --strip-all
D:\FreePascal\Projects\Test\Project1.exe,
anything else fails.

In my Dutch version here, after compling is on the top position in that compiler tab which is in fact before compling
Probably a translation bug.

After compling, I got "Oeps - debugger crash".

Ayway, the size was still 1116 kb for and empty program (button and a label) and the limit for my full program (Delphi) is 1 Mb There's still a long way to go ..
For Windows, it's not a problem (Delphi program), but I want it for WinCE and I have the same restrictions there.

Paul

So you get a 2 MB if you add two buttons and labels?

This won't get smaller unless you use UPX. So maybe you need to search another tool or framework (KOL) if you want smaller size.

For Windows, it's not a problem (Delphi program), but I want it for WinCE and I have the same restrictions there.

You cannot have both: a small size without debug info *and* a working debugger.

So you have to make up your mind:
A: an executable that can be started with the debugger: enable the debugging options (-g or -gl) and disable stripping (-Xs) in the linking tab

or

B: an executable that has a small size and can be released: disable all debugging options (-g, -gl, -gh) and enable string (-Xs) in the linking tab.

Vincent

Actually 1,16 MMb with 1 button and 1 label and a debugger crash as a bonus :-)

Paul

Yes, you should also disable -gl option (Display Line Numbers in Run-time Error Backtraces). This will give the most tangible size reduction compared to the options you have enabled.

In our previous episode, Paul said:

Actually 1,16 MMb with 1 button and 1 label :-)

http://wiki.freepascal.org/Size_Matters

Pretty normal for a lazarus app. If you want minimal size, see the winapi demo in the examples.

You cannot have both: a small size without debug info *and* a working debugger.

I do not need a working debugger.

B: an executable that has a small size and can be released: disable all debugging options (-g, -gl, -gh) and enable string (-Xs) in the linking tab.

I've done that and also (-Og, -O2 ), same result (also the debugger crash)

Paul

OK, you have a small size and a debuger crash. The debugger crash is ok, because you "do not need a working debugger".

Vincent

http://wiki.freepascal.org/Size_Matters Pretty normal for a lazarus app. If you want minimal size, see the winapi demo in the examples.

I have this doc printed and it wont be a problen on Windows for which I have the Delphi program.
I have not installed the WinCe version or crosscompiler, but it's the same there: if the size is always the same, I can't use FPC/Lazarus.

UPX is not an option, because our package is already packed with the exe, dll's and other files and the package has to be < 1Mb To have this, the program itself can have a max size of 1 MB.

Paul

----- Original Message -----
From: "Vincent Snijders"

OK, you have a small size and a debuger crash. The debugger crash is ok, because you "do not need a working debugger".

Indeed, only needed for testing but annoying though

Paul

Alternatively, write your WinCE program in pure assembly language. You should get fully function GUI apps at around 20-60 Kbytes. :-)

Gibson Research has a template setup for you:
http://www.grc.com/freepopular.htm

or for a more direct link
http://www.grc.com/smgassembly.htm

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

----- Original Message -----
From: "Graeme Geldenhuys"

Alternatively, write your WinCE program in pure assembly language. You should get fully function GUI apps at around 20-60 Kbytes. :-)

LOL, I don't think so: my Delphi program has only very basic GUI (fi chat) which is rarely used, it's mostly running without GUI, It has a pretty lage source code

Paul

If I understand correcly, it's the lcl that adds a huge part to the exe. Since I only use 1 small form, I could create it with api calls. But FPC for WinCE uses a crosscompiler, how do I have to implement this ? Are Windows api calls translated to ARM-calls ?

Paul

Take a look at http://wiki.freepascal.org/KOL-CE, this project was specially started to create a "framework" for creating very small .exe applications using Delphi and FPC.

Leonardo M. Ramé
http://leonardorame.blogspot.com

Paul wrote

If I understand correcly, it's the lcl that adds a huge part to the exe. Since I only use 1 small form, I could create it with api calls. But FPC for WinCE uses a crosscompiler, how do I have to implement this ? Are Windows api calls translated to ARM-calls ?

If you use a (cross-)compiler for ARM target processor, the generated binary will be indeed an ARM binary, of course (ready to run on an ARM under the selected target OS - WinCE in your case). If targetting WinCE OS, you can only use WinCE RTL and/or other units prepared for that target, so if the particular API isn't supported for WinCE (as opposed to other WinXX platforms), it simply won't compile.

Tomas

Hi Tomas,

This is bad news for me, I need control over the computer. The Windows version of the program uses a lot of api calls. Seems my only option is use Visual Studio :-(

Paul

In our previous episode, Paul said:

Note that wince's api is a subset of winapi. And that VS will suffer from that also.

----- Original Message -----
From: "Marco van de Voort"

Note that wince's api is a subset of winapi. And that VS will suffer from that also.

I know, but for a remote support system, I need to control the computer. For CE, it wil be very basic though.

Paul

Paul wrote

I know, but for a remote support system, I need to control the computer. For CE, it wil be very basic though.

What does "control the computer" mean? And how is that something that VS can achieve and Lazarus cannot?

On Fri, September 5, 2008 08:51, Paul wrote:

Hi Paul,

Similarly to Felipe, I don't understand why this should be a bad news for you or why this should mean that Visual Studio gave you something not available with FPC (or what that "something" was in that case)... It looks as if I either don't understand what you meant with the statement above, or that I didn't express myself clearly and you understood me differently (and that Marco's additional explanation regarding relation between Win32 and WinCE API hasn't helped to clarify that either).

Tomas

Paul, can you post an example of what do you want to do? a couple of API calls your Win32 app is calling?. Maybe we can help translating those calls to the WinCE version (I'm pretty sure the functions will work without changes).

Leonardo M. Ramé
http://leonardorame.blogspot.com

Hi Tomas,

It's clear that I can't call an api that doesn't exist on a specific platform.
I don't know how the crosscompiler works, maybe that's confusing me. If I use KOL, will all the api calls be translated to arm or do I have to use ARM api's directly ?

thanks,

Paul

On 6 Sep 08, at 11:08, Paul wrote:

Hi Paul,

OK, let's try to clarify this part. I've somewhat extended and updated the previously existing Wiki page about cross-compilation with FPC - see http://wiki.freepascal.org/Cross_compiling (especially the starting part). Feel free to ask if there are still unclear points.

If I use KOL, will all the api calls be translated to arm or do I have to use ARM api's directly ?

I don't know much about KOL, but if I understand it correctly, it's a framework (GUI library if you like) allowing the programmer to use Pascal classes for the various GUI elements. Implementation of these classes uses then the native API calls provided by the particular platform (Win32 or WinCE in your case). In other words, if using KOL, you don't use the API calls any case, you don't
need to care about whether the API calls are running on an x86 or ARM CPU, this is the job of FPC to generate proper binary code for the requested CPU (see notes about cross-compilation above).

Tomas

Hi Tomas,

thanks for your explanation, but that's not what I needed to know

I know KOL uses api calls (used it years ago), but I prefer to create my forms, buttons etc. directly with api calls myself to keep the exe size as small as possible.
My problem is: how should I write api call's for a different target platform , how are they interpreted by the crosscompiler, C-style or pascal-style...?

thanks,

Paul

PS: my Mac installation keeps giving me a headache. After removing and installing, adding all folders manually, I got it running and could even run a small program.
Next day, I get a OS-message that Lazarus is not a regular mac application and is now blocked (OS X 10.5)

Paul wrote

After removing and installing, adding all folders manually, I got it running and could even run a small program. Next day, I get a OS-message that Lazarus is not a regular mac application and is now blocked (OS X 10.5)

Can you please give the exact error message you get (in Dutch is ok), because I've never heard of any error message stating "This application is not a regular Mac OS X application and is now blocked" or similar.

Please be more specific, because otherwise it is very hard to help. For an interesting essay on this, see http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

Jonas

In our previous episode, Jonas Maebe said:

Please be more specific, because otherwise it is very hard to help. For an interesting essay on this, see http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

Hehe, I really like the bit in red at the bottom.

"U kunt het programma lazarus.app niet openen, omdat het niet wordt ondersteund door deze architecture"
translated:
"You can't open program lazarus.app, because it's not supported by this architecture"

Paul

This issue is mentioned for a certain version of OpenOffice at http://qa.openoffice.org/issues/show_bug.cgi?id=93289

Apparently there the reason was that the name of the binary in the info.plist of the application bundle no longer referred to a valid application. Since, afaik, the Lazarus application bundle (= the Lazarus icon) contains a symbolic link to the binary (outside the bundle) rather than the binary itself, did you perhaps move or copy the Lazarus application elsewhere and try to start it there? With any other application this would work (as it should), but it won't with the way Lazarus is currently packaged.

Try creating an alias instead (hold cmd and option and drag the icon elsewhere), and starting that.

Jonas

On 8 Sep 08, at 9:34, Paul wrote:

Hi Paul,

.
.

Let's assume that the used API calls would be those provided in unit Windows (the Win32 version if targetting i386-win32, or the WinCE version if targetting arm-wince). As long as these API calls are available on the given platform, you simply call them from the Pascal code using syntax defined in the interface part of unit Windows. Technically there's no difference between the native compilation and the cross-compilation, you just need to pass the right source code to the compiler with the right parameters specifying your target platform. The compiler automatically ensures that the right calling convention is used (as specified in unit Windows if referring to the API calls) and embeds the API calls into the machine code created for the target CPU. I'm not really sure what do you mean with "C style or Pascal style" - if this refers to calling conventions, they are the same for arm-wince as far as I know. Your source code would be obviously written in Pascal. The proper Pascal declarations may be found in the source code of unit Windows (interface part), but they should be mostly identical to those available with Delphi (in case you used that before).

Hope this helps

Tomas