Questions before moving on to FB

[Julcar]

1 / Can we manipulate a page opened in the default browser (get/set input value, get URL and title etc) natively, with a lib, which one ? Is it cross-platform ...

Maybe you are needing CURL or something like that, very likely you will need static linking to get the aimed cross-platform, and that will increase the size of your executable

[stephane]

Lazarus and Delphi are only large if you use the easy and portableframeworks. if you are willing to go to the bare metal, you can perfectly do small windows GUI development on winapi level, just like in FB. IOW it is a framework vs non-framework thingy, not a language A vs Language B thingy.

Now I'm really interested but could you please tell me what to look for in google because I didn't even know we could do this. The only thing I know to make applications lighter is to remove some dependencies, but that's it
I thank you because it really interests me because I wouldn't have to learn a new language and I know how to do what I want to do ...

[caseih]

Sure if you program Pascal without using any component libraries (perhaps using win32 directly), then FreePascal and FreeBASIC are about equivalent.

[Cretin Ho]

Lazarus and Delphi are only large if you use the easy and portableframeworks. if you are willing to go to the bare metal, you can perfectly do small windows GUI development on winapi level, just like in FB. IOW it is a framework vs non-framework thingy, not a language A vs Language B thingy.

One of the FPC sponsors used FPC to create router firmwares.

Doing so one will lost all of the RAD ability of Lazarus to boost the job and now it's really down to language A vs language B again since both now use the same Windows API.

[caseih]

Correct. And in that case, FB is a good choice.

[dodicat]

This is kind of like my deliberations with marcov recently relating to pascal.
I have been so used to using freebasic that I use pascal in the same way, a command line compiler, which I can use with a simple ide.
Thus I miss the whole point of lazarus, but unfortunately the freepascal forum is all about lazarus.
So between the two languages, the freebasic forum is much more helpful than the freepascal [lazarus] forum regarding the actual compilers.
Pascal has about the same degree of difficulty using the Win api as freebasic as far as I can tell anyway.
But the winapi is not a popular topic in freepascal.
Also freebasic has a big advantage of having built in graphics, which can be a handy substitute for winapi for small applications.

[Linuxbob]

My choice (FB) is that exe are very small instead delphi exe. Lazarus exe are biggers than delphi exe...

FB may not be the right choice, I will continue my investigations. Thank you all for your answers and advice

I have noticed that Lazarus files are bigger than Delphi, but it is a complete package. One does not require any of the runtime DLLs or other support files if you wish to deploy a program. The .EXE is enough.

[marcov]

Sure if you program Pascal without using any component libraries (perhaps using win32 directly), then FreePascal and FreeBASIC are about equivalent.

Roughly yes. There is even a book about the core api, and another one about GDI drawing. Good finds in 2nd hand shops (though I assume now harder to find then e.g. 10 years ago)

They are like Petzold with Pascal syntax and compilable projects on the CDs (for D6/7), roughly Win ME/Windows 2000 SDK era, iow just before Windows XP, but to get a quick introduction they are quite nice.

Doing so one will lost all of the RAD ability of Lazarus to boost the job and now it's really down to language A vs language B again since both now use the same Windows API.

Or simply don't needlessly make size the centre of the universe.

I have noticed that Lazarus files are bigger than Delphi, but it is a complete package. One does not require any of the runtime DLLs or other support files if you wish to deploy a program. The .EXE is enough.

The difference is slight or not even there depending on the version of Delphi. More modern unicode Delphi versions are much bulkier too.
But it is easy to make size comparison mistakes, because Lazarus debug info is bulkier on some targets.

This is kind of like my deliberations with marcov recently relating to pascal.
Thus I miss the whole point of lazarus, but unfortunately the freepascal forum is all about lazarus.

There are freepascal specific subforums too, but flow is higher in Lazarus related. Though in many topics logic can be easily separated from the GUI bits.

So between the two languages, the freebasic forum is much more helpful than the freepascal [lazarus] forum regarding the actual compilers.

Opinion, and IMHO false. The Lazarus forum is maybe slightly more business app oriented, with users having larger apps, but both forums have their weird and aggressive posters that can give first time posters the wrong impression.

Pascal has about the same degree of difficulty using the Win api as freebasic as far as I can tell anyway.

I do agree with that. There are accent and approach differences, but that depends on what you try to achieve and expect.

Pascal is easier with COM though, and many new APIs are COM. It is more VB like in that way.

But the winapi is not a popular topic in freepascal.

Non LCL, pure winapi apps might not be common, but Winapi is used a lot, and since the VCL originally was a GDI wrapper, many canvas stuff is nearly the same with a VCL sauce over it, and additional pure winapi code can be used to enhance it (albeit that makes it windows-only)

It is weird getting blasted in this thread about not being winapi enough, when usually the LCL gets flak for being to windows api like. (also on non windows)

Also freebasic has a big advantage of having built in graphics, which can be a handy substitute for winapi for small applications.

Free Pascal comes with Graph since before Freebasic existed.

P.s. I really don't understand the small EXE cult as primary guiding beacon for tool selection, specially not in these magnitudes (say between 100k vs up to 1.5MB for small programs and 1MB to 15MB for large ones, Lazarus is 15-20MB, but over 2-3 million lines of code. What do any of these sizes matter on even a 15 year old 160GB HDD ?). There are bigger and more important problems in programming, not in the least the actual goal of the application.

[Cretin Ho]

P.s. I really don't understand the small EXE cult as primary guiding beacon for tool selection, specially not in these magnitudes (say between 100k vs up to 1.5MB for small programs and 1MB to 15MB for large ones, Lazarus is 15-20MB, but over 2-3 million lines of code. What do any of these sizes matter on even a 15 year old 160GB HDD ?). There are bigger and more important problems in programming, not in the least the actual goal of the application.

This is personal preference. I know the strength of Lazarus. The binary it created is big but most of the time it's statically linked, so it doesn't need the runtime distribution like Visual C++. But plain C has it strength, too. You could download Drive Snapshot, and see what this very small executable fully working graphical application could do. Impressive, isn't it? I only give Drive Snapshot as an example. If the same application was develop in Lazarus, it should be 15MB in size. Given how simple the GUI of it is, a 15MB in size binary seems doesn't worth it. I would consider Lazarus seriously if my application GUI is very complex. But you know, most of the FB users here normally don't develop such complex GUI app. So they just use the right tool for the right job. FB application usually not much bigger than C application. Hope it helps.

[jj2007]

I really don't understand the small EXE cult

Lol, you haven't been on Assembly forums - some still fight for executables below the 1,024 bytes mark (which is difficult to achieve but possible). Old and wise as I am, I have accepted that my programs sometimes need a whopping 60kBytes, and 80 lines of source code, see screenshot below.

I get intolerant, though, when VS takes over a minute to load itself, only to inform me that the 5 year old C snippet that I found on the Internet cannot be converted to 'modern' C code. Or when a simple hello world FB proggie takes several seconds to be compiled with Gcc. Bloatware is also slowware, most of the time...

[Cretin Ho]

I really don't understand the small EXE cult

Lol, you haven't been on Assembly forums - some still fight for executables below the 1,024 bytes mark (which is difficult to achieve but possible).

These extremists are hackers. Normal people doesn't do that!

[jj2007]

These extremists are hackers. Normal people doesn't do that!

You forgot the [irony]irony tags[/irony] - some people might take you seriously, lol ;-)

[marcov]

P.s. I really don't understand the small EXE cult as primary guiding beacon for tool selection, specially not in these magnitudes (say between 100k vs up to 1.5MB for small programs and 1MB to 15MB for large ones, Lazarus is 15-20MB, but over 2-3 million lines of code. What do any of these sizes matter on even a 15 year old 160GB HDD ?). There are bigger and more important problems in programming, not in the least the actual goal of the application.

This is personal preference. I know the strength of Lazarus. The binary it created is big but most of the time it's statically linked, so it doesn't need the runtime distribution like Visual C++. But plain C has it strength, too. You could download Drive Snapshot, and see what this very small executable fully working graphical application could do.

Please read the above posts again. You can do pure winapi work with nearly any native code language. It is just tedious and saves a couple of MB. There is nothing C specific about it.

Impressive, isn't it?

Impressive waste of time, yes. It's like doing dishes with a tootbrush, and then being very proud on having done it with a children's toothbrush that is even smaller

I only give Drive Snapshot as an example. If the same application was develop in Lazarus, it should be 15MB in size.

I doubt it. A simple database app in Lazarus with say 10 screens, each with a grid is like 2MB. It does use the sqlite client lib as DLL though.

The whole of lazarus is 15MB, but that contains a complex editor widget (something like scintilla), 20 language highlighters, intellisense and refactoring for pascal, the designer, debugger and compiler interfacing, Delphi importer and another 50 things.

Given how simple the GUI of it is, a 15MB in size binary seems doesn't worth it.

If the GUI is simple, your 15MB size is inflated, but even if it is 5MB, who cares? It still fits 100.000 times on the cheaps new harddisk you can get. It is this bright mentality that I don't get ? And the arbitrarity of it? Why is 1MB ok and 5MB not? Is 2 MB still ok? 1.5 ? 1.3? Who determines this nonsense?

I would consider Lazarus seriously if my application GUI is very complex. But you know, most of the FB users here normally don't develop such complex GUI app.

What is the largest FB app with source ? Is there a list somewhere?

So they just use the right tool for the right job. FB application usually not much bigger than C application. Hope it helps.

Still don't get it why size is a relevant factor at all. Nearly anything you do (like just running windows upgrade) is heaps larger in logs and old files etc, and that isn't as big a time investment for the average programmer/user as programming.

Run disk clean if you are low on disk. Zip some used pics, whatever.

I really don't understand the small EXE cult

Lol, you haven't been on Assembly forums - some still fight for executables below the 1,024 bytes mark (which is difficult to achieve but possible).

These extremists are hackers. Normal people doesn't do that!

No they are not hackers. Hackers know what they are doing and work efficient. These are more script kiddies and lamers.

[jj2007]

Lol, you haven't been on Assembly forums - some still fight for executables below the 1,024 bytes mark (which is difficult to achieve but possible).

These extremists are hackers. Normal people doesn't do that!

No they are not hackers. Hackers know what they are doing and work efficient. These are more script kiddies and lamers.

Script kiddies will use QT (standalone exe: at least 8MB) or .NOT for their hello world proggies, because they are too dumb to study the internals of the PE format. What you call "lamers" are 99% people who like the challenge of tickling the last cycle out of assembly code, or solve the last Windows secret. Proud hobby programmers, not people who must code to feed their family. It's a bit like playing chess - completely useless and inefficient, but it's fun. My personal hobby is to demonstrate that hand-crafted assembly is often twice as fast as the code spit out by VC or GCC. Btw I fully agree that "Normal people doesn't do that!" ;-)

[caseih]

As always, use the whatever tool is appropriate to the job. Recognize that everything you do involves trade-offs. For example you can trade memory for speed, speed of development for speed of execution, speed of execution for the cost of future maintenance. Switching from Delphi to FB involves trade offs, mainly regarding the fact you need to do everything yourself that Delphi does for you currently. Many times I've seen individuals try new languages because of something trivial like executable size, and often they become disillusioned and critical of the new language. FB could well be a good fit for you, but your recent posts make me question that, as you've relied heavily on Delphi's components, for which you'll have to rely on third-party libraries with FB. And that brings the same executable size baggage that you had before. Plus the added difficulty of learning FB, it's runtime library, and the third-party library. Just trying to be realistic here.

I guess I must be a script kiddie, since I prefer Qt for anything GUI related, even hello world. Funny. I certainly don't care about the size of Qt. And I do nearly everything in Python (even heavy math!). If I shipped a hello world program with an installer it would probably be about 16 mb on Windows, shipping Qt with it. However on systems that already provide Qt, my executable can be a few kb. Any large library can be shared across the operating system with other programs. So even if I have dozens of Qt apps running, Qt is only loaded once. But I digress.

You might be able to hand-craft assembly to run faster than GCC-emitted code (some of the time but not all of the time), but that code is limited to the ISA and OS it was crafted for. GCC has been ported to many platforms. I can use the same basic code in many places. I have no interest in the internals of the PE format, nor do most programmers. In fact the PE format isn't even relevant to anything I do, and is meaningless on the platforms I develop for. To me the ease and speed of development is most important. Portability between platforms comes next (x86, ARM, RISC-V, Windows, Mac, Linux), ease of maintenance, and finally executable speed.

If you programmed for macOS in assembly, you'd be in a rather difficult position now that Apple is transitioning to ARM. There is a saying, "premature optimization is the root of all evil." If you a find a situation where you say, this is slow. I'll rewrite it in assembly language. Stop right there. Sit back and profile the program to make sure you know for a fact where the CPU is spending its time. Then take a hard look at how you're doing something and consider if there isn't a better algorithm or method of optimization. Often you can trade memory for speed and make huge gains. If after all these things you find a loop that's still too slow, then and only then you can try hand coding it in assembly.