Part 3 Action "the GUI library"

[deltarho[1859]]

In the WinFBE package, by Paul Squires, are some examples using José's WinFBX framework.

Here is a Frame example with a few controls inside it. All I did was add a manifest.



I ripped out the comments from the source code to see what it would reduce to but kept blank lines for readability and ended up with 67 lines of code. The exe comes in at 45.5KB (32 bit) and 49.5KB (64 bit) using '-gen gcc -Wc -O3 Resource.rc' and is DPI aware.

Admittedly, we are talking Windows here but that should keep, what, half of the forum members busy. <smile>

[Munair]

If one expects an executable to stay below 500kb in today's world of GUI programming, then that expectation is generally misplaced, or one should refrain from using wrappers and expose the GUI library completely, which is impossible in cross-platform computing. Take the following example, quickly taken from zetcode.com. It demonstrates how to use GTK in FreeBASIC:

Code: Select all

' ZetCode FreeBASIC GTK tutorial
'
' This program centers a window on 
' the screen
'
' author Jan Bodnar
' last modified July 2010
' website www.zetcode.com

#include once "gtk/gtk.bi"

#define NULL 0

Dim As GtkWidget Ptr win

gtk_init(NULL, NULL)

win = gtk_window_new(GTK_WINDOW_TOPLEVEL)
gtk_window_set_title(GTK_WINDOW(win), "Center")
gtk_widget_set_size_request(win, 250, 150)
gtk_window_set_position(GTK_WINDOW(win), GTK_WIN_POS_CENTER)

g_signal_connect(G_OBJECT(win), "destroy", _
    G_CALLBACK (@gtk_main_quit), NULL)

gtk_widget_show(win)
gtk_main()

END 0

This code shows a window, nothing more, nothing less. The executable is 22.4kb. Great. But in principle this is only targeted at Linux and it doesn't allow easy coding. Component libraries that target multiple platforms use wrappers and require extra code to accomodate platform specific stuff. The advantage is that such a library allows you to program natively. The downside is that executables become quite large. For example, Lazarus doesn't produce an executable below 3MB. Xojo (REALbasic) easily starts at 5MB.

[Munair]

I am not a Linux guy but maintaining all these different distributions would drive me crazy. I see the IUP has about 12 different Linux packages.

It's not about distributions. It's about the desktop. Most distributions use either Qt or GTK for their desktop, or both if the required libraries are installed. So one doesn't need to maintain distributions. The only maintenance would indeed come from packaging specifics. Targeting Debian and derivatives would require DEB. Fedora/Redhat requires RPM, etc, but that isn't a big deal. And a general tar.gz file would do as well.

I have no real experience with IUP, but it looks like it isn't as extensive as GTK.

[jj2007]

But not Free Basic... unless you begin to add crap to it. See this application (FBPiano), made with my WinFBX framework. Size: 110 Kb.
http://www.planetsquires.com/protect/fo ... 2#msg31242

And it does a little bit more than just saying "Hello World" ;-)

...67 lines of code. The exe comes in at 45.5KB (32 bit) and 49.5KB (64 bit)

Yes, it can be done (in Windows, of course). Here is one more - work in progress, the final version will be under 100 lines of code, the exe has 54,784 bytes.


The app features a menu, static, edit, richedit, date+time, progressbar, trackbar, button controls, it can open the links to MasmBasic and MSDN, and the spreadsheet at the bottom can be edited and saved.

If one expects an executable to stay below 500kb in today's the Linux world of GUI programming, then that expectation is generally misplaced

That is very sad. Perhaps we need separate solutions then: Same syntax but lean and mean for Windows, QT-style for Linux?

[Munair]

But I do really mean that you have shown no sign of understanding Windows or understanding its security situation.

That's because you don't read. Among other things I referred to raw sockets, which you ignored, and dll injection, which you seem to trivialize as only a local threat. Install a good firewall with component management or even better, a separate manager, and you will see what processes can do and how vulnerable Windows is. I'm not sure about Windows 10 as I have not tested it thoroughly; my initial experience with not excepting the legal product key (error code 0xc0020036) was already enough for me.

In general, what I monitor on Windows with regards to processes (among other things):

- protection of physical memory
- process termination/modification
- global hooks
- rootkit/driver/service installation
- registry DLL injection
- raw sockets (preferrably disabled)

For the average user, it wouldn't be workable to monitor these things. They may be powerful features, but they could also be easily exploited and have been, given the extensive list of malicious software. I never use antivirus software because I do fine with monitoring processes, but in the earlier days I did and the virus definition files grew by the week. Not sure how large they are today. And not to mention the yearly subscription one is forced to purchase.

With Linux I never have any of these problems. Yes Linux has LD_PRELOAD, but the difference is that on Linux only the execution environment per user is affected and the user already has the same privileges so it doesn't make any difference. Moreover, installing software from known repositories will never put the system in danger. Additionally, open-source software is transparent and one knows what it does. Compare this to Windows executables that can be picked anywhere from the internet. Of course, there is the option to "run as administrator" but it can be used on the fly and many Windows users quickly resort to that option if an application complains about insufficient rights. It's like Russian roulette and you better have a good antivirus solution hoping it contains the latest threat definitions.

I stand by what I said before: Linux is superior in many ways. In my opinion a stable KDE desktop gives the user a much better computer experience than Windows; there are loads of options, free tools and apps, it's very user-friendly, very customizable, no need for antivirus, or firewall configuration, no yearly subscriptions. I could go on and on...

[Munair]

If one expects an executable to stay below 500kb in today's the Linux world of GUI programming, then that expectation is generally misplaced

That is very sad. Perhaps we need separate solutions then: Same syntax but lean and mean for Windows, QT-style for Linux?

No, I said the GUI world in general. Linux is much less bloated than Windows. But trying to develop a cross-platform programming solution will inevitably raise the size of executables.

Qt and FreeBASIC isn't an easy option.

[deltarho[1859]]

Linux is superior in many ways.

I am a Windows guy but I won't bother to dispute that because it is probably true. However, this thread is not about Windows versus Linux.

But trying to develop a cross-platform programming solution will inevitably raise the size of executables.

Me: Doctor, it hurts when I twist my arm, like this.
Doctor: Then don't twist your arm, like that.

That is very sad. Perhaps we need separate solutions then

Talk about 'standing out like a sore thumb'. <laugh>

the exe has 54,784 bytes.

You will need a Bloat metastatement, like PowerBASIC.

"#BLOAT allows the creation of artificially bloated program files on disk, in order to match or exceed that generated by competing "BloatWare" compilers. #BLOAT does not affect the memory image size (running size) of a compiled program."

"While #BLOAT adds no true merit to the technical efficiency of the compiled code, there are a number of reasons for its use, including:

1. To allow "BloatWare" programmers to feel more comfortable when using PowerBASIC.
2. To impress project leaders/managers with the volume of executable code created.
3. To allay the fears of uninformed customers who may mistakenly infer that "such tiny programs couldn't possibly do everything that..."
4. To make certain versions of a program more readily identifiable simply by examining the size of the file on disk.
5. To improve convolution of the contents of the executable disk image, because the bloat region appears to contain executable code.

Example: #BLOAT 1024 * 1024 * 4 ' Create a 4 MB EXE file"

Bob Zale had a sense of humour.

PS @jj2007 Add a manifest - it will only cost 2.5KB <smile>

[jj2007]

Bob Zale had a sense of humour.
PS @jj2007 Add a manifest - it will only cost 2.5KB <smile>

Yes, Bob was a very special individual ;-)
The exe has a manifest, and loads common controls version 6.16; without, exe size goes down to 52,736 bytes.

[St_W]

If one expects an executable to stay below 500kb in today's the Linux world of GUI programming, then that expectation is generally misplaced

That is very sad. Perhaps we need separate solutions then: Same syntax but lean and mean for Windows, QT-style for Linux?

As I already mentioned previously the Qt libraries have at least 20 MB (depending on which ones you need). 500 KB is really no bloat for a (platform independent) GUI application nowadays, irrelevant whether you're talking about Windows or Linux. I completely agree with Munair in this regard.

[Munair]

Linux is superior in many ways.

I am a Windows guy but I won't bother to dispute that because it is probably true. However, this thread is not about Windows versus Linux.

When speaking of GUI libraries, cross-platform discussions are unavoidable. I think the reason these discussions come up frequently is because Windows and Linux users tend to think differently, especially if it comes to runtimes and sizes. It is not something we can ignore when choosing a GUI library.

[jj2007]

As I already mentioned previously the Qt libraries have at least 20 MB (depending on which ones you need). 500 KB is really no bloat for a (platform independent) GUI application nowadays, irrelevant whether you're talking about Windows or Linux.

Of course it could be done! Use a simple common syntax, example (tested, of course):

Code: Select all

GuiParas equ "This is a full-fledged event-driven Windows application"
GuiMenu equ @File, &Open, &Save, -, E&xit, @Edit, Undo, Copy, Paste
include \masm32\MasmBasic\Res\MbGui.asm
GuiControl MyRichEd, "richedit", "sometext"
Event Menu
  If_ MenuID>=0 && MenuID<=7 Then MsgBox 0, Str$("You clicked menu #%i", MenuID), "Hi", MB_OK
GuiEnd

Fine for Windows, 44kBytes, works like a charm. Now, all you have to do is to use this syntax to create the code you need for Linux. Shouldn't be difficult for a seasoned Linux programmer, right? But don't dare to suggest that Windows users install megabytes of unusable crap on their machines. I hate mentioning this, but given the market share of Linux, this is an attempt of the tail to wag the dog.

And no, it's not "irrelevant whether you're talking about Windows or Linux". The problem is that "Linux", with it's 2.5% of market share, is a bunch of "distros" that have never agreed on a common GUI library that could perform at least in part what the Windows APIs have done smoothly for two decades. That is why we see these desperate attempts to create horribly bloated "frameworks" that are supposed to work "cross-platform". It's not because of Windows, it's because every tiny Linux "distro" is a "platform" that needs to reinvent the GUI wheel.

[St_W]

Of course it could be done! [...] Fine for Windows, 44kBytes, works like a charm. Now, all you have to do is to use this syntax to create the code you need for Linux. Shouldn't be difficult for a seasoned Linux programmer, right? But don't dare to suggest that Windows users install megabytes of unusable crap on their machines.

The question is not whether it is possible or not, because you can write a small GUI application for both Windows and Linux. The thing is rather that most people don't want to do that; they want cross-platform, easy-to-use GUI toolkits with abstraction layers to be as general/versatile und future-proof as possible. All that comes at cost of size and speed. Nowadays there's Windows, Linux, Mac OSX, Android, iOS, etc. and many people want their applications to run on all of these. When you are speaking of Windows users caring about size differences in kB that sounds dated. Note that software engineering is evolving rapidly and a large amount of knowledge gets obsolete after a relatively short time.

[jj2007]

When you are speaking of Windows users caring about size differences in kB that sounds dated. Note that software engineering is evolving rapidly and a large amount of knowledge gets obsolete after a relatively short time.

If a simple GUI application reaches 100k or 200k, OK. But if, for example, QT Creator needs SEVENTEEN seconds to load itself on my Core i5, and another SEVEN seconds to load a tiny hello world project, then this is a sign of crappy design. Double-click on mainwindow.ui, and WAIT another three seconds. Type something in the caption bar, and watch the characters appear, one by one, sloooooowly....

This is what happens when people try desperately to port their Linux software to Windows, without having the faintest idea how Windows works. And they need over one GIGABYTE of "tools" to make a hello world proggie build and run. No thanks. Therefore, seriously: Use a very simple, BASIC syntax, and let the Linux crowd decide themselves which "toolbox" they want to use to implement MessageBox(0, "A text", "A title", MB_YESNOCANCEL).

Re "a large amount of knowledge gets obsolete after a relatively short time": No, not on Windows. You can build perfect Windows applications just by reading the 20-year-old Petzold book. Some new controls have been introduced, but they are well-documented, follow the general rules of Win API development, and are rarely needed anyway. Do you have a link to the Linux documentation for e.g. an edit control? A date and time picker? A syslink or a listview...?

There is a hilarious thread at SOF: (C++) MessageBox for Linux like in MS Windows

[Munair]

The problem is that "Linux", with it's 2.5% of market share, is a bunch of "distros" that have never agreed on a common GUI library that could perform at least in part what the Windows APIs have done smoothly for two decades. That is why we see these desperate attempts to create horribly bloated "frameworks" that are supposed to work "cross-platform". It's not because of Windows, it's because every tiny Linux "distro" is a "platform" that needs to reinvent the GUI wheel.

Linux has nothing to do with it. Try a development environment that only supports Windows and MAC and you will have a bloated framework. Adding GTK support won't make much difference. I don't know from where you get the idea that the many Linux distros are the cause of bloated frameworks. Most distros use either Qt or GTK as the base for their desktop environment. You make it sound like there are as many GUI libraries as there are distros, which isn't true.

[Munair]

...when people try desperately to port their Linux software to Windows, without having the faintest idea how Windows works.

Actually, most porting is between Windows and MAC because these platforms are commerically interesting, meaning, developers can sell licenses.

Qt Creator is a development environment, so naturally it takes a bit before everything is loaded. Admittedly, Qt is not the fastest GUI library, but it is currently the best attempt to create cross-platform software with a close to native look. If you read about Qt's history you will know why the project came into existence. This was before the name Linux even existed. The targets were Windows, MAC and Unix.