Smaller Executable File

[Ronnie]

Hi - I am testing a program with 3 tabs and tried two methods to create an executable file.  The first approach was Liberty Basic, it create a file that was 1,200,000 bites (plus the dlls) and the second approach used LB Boost that compiled a file that was only 110,000 bites.  My question is how can I get the Liberty Basic program to compile smaller executable files?

One thing to note the LB Boost code flickers when running, so I can not use the exe.  Thank You...

If anyone is interested the follow is the code:

'<cursorpos> 4120
'tab control demo
'use dialog_popup windows to hold controls
'set parent of popups to be main program window
'when tab is clicked, use MoveWindow to move popups on and off
'if a graphicbox is used, use GetParent on popup
'if graphicbox is used, restore parent of popup at close
'doesn't work properly with type window_popup

nomainwin
'constants:
TCIF.TEXT = 1
TCIF.IMAGE =2
TCS.MULTILINE = 512
TCM.INSERTITEMA = 4871
TCM.GETCURSEL = 4875
TCM.SETCURSEL = 4876

tabID = 1 'current tab
oldTab = 0 'previously selected tab

struct TCITEM,_
mask as ulong,_
dwState as ulong,_
dwStateMask as ulong,_
pszText$ as ptr,_
txtMax as long,_
iImage as long,_
lParam as long

'initialize DLL
calldll #comctl32, "InitCommonControls", ret as void


WindowWidth=700:WindowHeight=410
UpperLeftX=int((DisplayWidth-WindowWidth)/2)
UpperLeftY=int((DisplayHeight-WindowHeight)/2)

BackgroundColor$ = "darkblue"
ForegroundColor$ = "red"
'example controls:
'first page


'Branch Label Event Handler
' Sample program. Pick a contact status
options$(0) = "Cold Contact Phone Call"
options$(1) = "Send Literature"
options$(2) = "Follow Up Call"
options$(3) = "Send Promotional"
options$(4) = "Final Call"

listbox #tab1.lb, options$(), [selectionMade], 20, 30, 200, 330
textbox #tab1.tx, 224, 30, 410, 330
Button #tab1.b1, "Button 1", [buttonOne], UL, 395, 370, 90, 24

open "" for window_popup as #tab1
print #tab1.lb, "font Ariel 12" ' font text box
print #tab1.tx, "!font Ariel 18" ' font text box

#tab1.lb "singleclickselect [selectionMade]"

'second page
Textbox #tab2.t2, 40, 40, 180, 30
Button #tab2.b2, "Button 2", [buttonTwo], UL, 40, 80, 85, 24
open "" for window_popup as #tab2

'third page
graphicbox #tab3.g, 0, 0, 350, 210
open "" for window_popup as #tab3

'main program window
WindowWidth = 700:WindowHeight = 500 ' whole window
open "Tab Demo" for window_nf as #1

print #1, "trapclose [quit]"
print #1, "font ms_sans_serif 12"

#tab2.t2 "Second Tab Page!"

print #tab3.g, "down; fill blue; color white"
print #tab3.g, "backcolor blue"
print #tab3.g, "place 30 50;\Third page!\Click Me!"
print #tab3.g, "flush"
print #tab3.g, "setfocus; when leftButtonDown [mouseClick]"

hwndParent = hwnd(#1) 'retrieve window handle
hTab1=hwnd(#tab1):hTab2=hwnd(#tab2):hTab3=hwnd(#tab3)

dim winTab(3) 'hold tab window handles in array
winTab(0)=hTab1
winTab(1)=hTab2
winTab(2)=hTab3

'because of graphicbox, get parent on third tab window for use later
hTab3Parent=GetParent(hTab3)

'set popups to be children of main program window
for i = 0 to 2
call SetParent hwndParent,winTab(i)
next

'move child windows
gosub [clear]
call MoveWindow hTab1, 20,40,650,410 ' first set up
CallDLL #user32, "GetWindowLongA",_
hwndParent As ulong,_ 'parent window handle
_GWL_HINSTANCE As long,_'flag to retrieve instance handle
hInstance As ulong 'instance handle


' Create control
style = _WS_CHILD or _WS_CLIPSIBLINGS or _WS_VISIBLE _
or TCS.MULTILINE
calldll #user32, "CreateWindowExA",_
0 As long,_ ' extended style
"SysTabControl32" as ptr,_ ' class name
"" as ptr,_
style as long,_ ' style
10 as long,_ ' left x
10 as long,_ ' top y
675 as long,_ ' width internal fram
450 as long,_ ' height
hwndParent as ulong,_ ' parent hWnd
0 as long,_
hInstance as ulong,_ ' hInstance
"" as ptr,_
hwndTab as ulong ' tab control handle

'set mask and fill struct members:
TCITEM.mask.struct = TCIF.TEXT or TCIF.IMAGE
TCITEM.iImage.struct = -1 'no image
TCITEM.pszText$.struct = "Introduction"
'TCITEM.txtMax.struct=len("First Tab")+1 'used when retrieving text, not needed here

'add first tab:
calldll #user32, "SendMessageA",_
hwndTab as ulong,_
TCM.INSERTITEMA as long,_
0 as long,_ 'zero-based, so 0=first tab
TCITEM as struct,_
ret as long

'add second tab:
TCITEM.pszText$.struct = "Second Tab"
'TCITEM.txtMax.struct=len("Second Tab")+1 'used when retrieving text, not needed here
calldll #user32, "SendMessageA",_
hwndTab as ulong,_
TCM.INSERTITEMA as long,_
1 as long,_ 'zero-based, so 1=second tab
TCITEM as struct,_
ret as long

'add third tab:
TCITEM.pszText$.struct = "Third Tab"
'TCITEM.txtMax.struct=len("Third Tab")+1 'used when retrieving text, not needed here
calldll #user32, "SendMessageA",_
hwndTab as ulong,_
TCM.INSERTITEMA as long,_
2 as long,_ 'zero-based, so 2=third tab
TCITEM as struct,_
ret as long

calldll #gdi32, "GetStockObject",_
_DEFAULT_GUI_FONT as long, hFont as ulong

'set the font to the control:
CallDLL #user32, "SendMessageA",_
hwndTab As ulong,_ 'tab control handle
_WM_SETFONT As long,_ 'message
hFont As ulong,_ 'handle of font
1 As long,_ 'repaint flag
ret As long

timer 300, [checkForTab]
calldll #user32, "SetFocus",hwndParent as ulong,re as ulong
wait

[quit]
timer 0
'because of graphicbox, restore parent to third tab window
call SetParent hTab3Parent, hTab3
close #1:close #tab1:close #tab2:close #tab3:end

[checkForTab] 'see if selected tab is the same
'as previously selected tab and
'change controls if tab has changed
timer 0 'turn off timer

'get the current tab ID
calldll #user32, "SendMessageA",_
hwndTab as ulong,_ 'tab control handle
TCM.GETCURSEL as long,_ 'message to get current selection
0 as long, 0 as long,_ 'always 0's
tabID as long 'returns selected tab ID

if tabID <> oldTab then 'change page displayed
oldTab = tabID 'for next check of selected tab
gosub [clear]
call MoveWindow winTab(tabID), 20,40,650,410
end if

print #1, "refresh"
timer 300, [checkForTab] 'reactivate timer
wait

[buttonOne]
timer 0
notice "First page."
timer 300, [checkForTab]
wait

[buttonTwo]
timer 0
#tab2.t2 "!contents? txt$"
notice "Textbox contents: ";txt$
timer 300, [checkForTab]
wait

[mouseClick]
timer 0
notice "Mouse clicked on third page."
timer 300, [checkForTab]
wait

[clear] 'hide all windows
for i = 0 to 2
call MoveWindow winTab(i), 3000,3000,550,410
next
return

[selectionMade]
print #tab1.lb, "selectionindex? xVar"


SELECT CASE xVar
CASE 1
c$ = "one"
CASE 2
c$ = "two"
CASE 3
c$ = "three"
CASE else
c$ = "none of the above"
'basic code
'goes here
END SELECT

print #tab1.tx, c$ 'str$(c)
wait


Function GetParent(hWnd)
calldll #user32, "GetParent",hWnd as ulong,_
GetParent as ulong
End Function

Sub SetParent hWnd,hWndChild
CallDLL #user32, "SetParent", hWndChild As uLong,_
hWnd As uLong, result As uLong
style = _WS_CHILD or _WS_VISIBLE
CallDLL #user32, "SetWindowLongA",_
hWndChild As ulong, _GWL_STYLE As long,_
style As Long, r As long
End Sub

Sub MoveWindow hWnd,x,y,w,h
CallDLL #user32, "MoveWindow",hWnd As uLong,_
x As Long, y As Long,w As Long, h As Long,_
1 As Boolean, r As Boolean
End Sub

 

[Rod]

The size of the Liberty .exe is pretty standard and includes the .dlls which run the code. You can’t really avoid this though with today’s download speeds and average file sizes the actual size is not a big deal.

I have not run the code but I see a lot of API calls. Perhaps more time invested in native code would provide rewarding results. There are demos of tab style controls, Alyce has some for sure.

If you have a problem with boosted code you need to ask on the appropriate forum because there are significant differences in how the code is compiled and run. We have our own set of bugs and workarounds, we don’t discuss Booster problem here, it would get too confusing.

If the code runs well in Liberty BASIC I would stress less about file size.

[cundo]

You could use a file packer, so pack your DLLs and SLLs and resources and then compress them using enigmaprotector.com/en/aboutvb.html for example. Result: one single exe.
Also a zipped version of your program will be smaller.

[Ronnie]

Hi Rod / Cundo - Thank you. Rod, I apologize. I understand about the third party software, and I only mentioned the program as a reference point.

Ronnie

[Carl Gundel]

Why does the application needs to be so small?

Sometimes people do ask about this. Ten years ago this still felt like a valid complaint, but nowadays it really doesn't matter very much unless you are trying to keep your applications on floppy disks, and who does this anymore?

For $10 you can buy an 8GB flash drive, and you can store thousands of Liberty BASIC applications on one of these. Even if you are still using an old computer, you still have gigabytes of storage on your hard disk.

If you are trying to share your software with others, an application size of a few megabytes is about the same as a single digital photograph.

So, is it cool that other compilers can create 100K executables? Yeah, sure. But how important a feature is this today? Not very important.

[Kuron]

Just because your EU's have resources available, does not mean you should waste them. The "bloat because you can" methodology is best left to Microsoft and their .NET initiative. Thankfully, LB's runtimes are much, much smaller than .NET's. LB's size is not really an issue today. And I say that as somebody who does not download bloated software due to the very limited 32GB hard drive (which is mostly filled by Windows 10) in my $75 Windows 10 hybrid. I would not think twice about downloading a program I needed that was made in LB.

Somebody mentioned Enigma Virtual Box. This works fine with LB, unfortunately Enigma Virtual Box has one issue. It does not actually compress your program's EXE, no matter what language yOu are using. i am looking forward to getting my belongings unpacked so I can dig out my copy of Molebox which would compress the EXE as well. Can't remember if it worked with LB, though.

There are two other free packers that work well with LB, and provide smaller distribution size than Enigma Virtual Box. They extract the files at runtime and then delete the files after the program exits. I used to have tutorials up for those two and Enigma Virtual Box. Unfortunately, thanks to GDPR, I am in between hosts and trying to find a solution that is GDPR compliant.

You can also try using an executable compressor on the LB runtime EXE and the DLLs. I have not tried this in years, but way back in time when the first 32-bit version of LB appeared, Neolite (which is no longer sold) would compress the runtime EXE, but UPX I can't remember if it had issues back then or not.

[Carl Gundel]

Jul 15, 2018 5:12:57 GMT -5 Kuron said:

Just because your EU's have resources available, does not mean you should waste them. The "bloat because you can" methodology is best left to Microsoft and their .NET initiative. Thankfully, LB's runtimes are much, much smaller than .NET's. LB's size is not really an issue today. And I say that as somebody who does not download bloated software due to the very limited 32GB hard drive (which is mostly filled by Windows 10) in my $75 Windows 10 hybrid. I would not think twice about downloading a program I needed that was made in LB.

Somebody mentioned Enigma Virtual Box. This works fine with LB, unfortunately Enigma Virtual Box has one issue. It does not actually compress your program's EXE, no matter what language yOu are using. i am looking forward to getting my belongings unpacked so I can dig out my copy of Molebox which would compress the EXE as well. Can't remember if it worked with LB, though.

There are two other free packers that work well with LB, and provide smaller distribution size than Enigma Virtual Box. They extract the files at runtime and then delete the files after the program exits. I used to have tutorials up for those two and Enigma Virtual Box. Unfortunately, thanks to GDPR, I am in between hosts and trying to find a solution that is GDPR compliant.

You can also try using an executable compressor on the LB runtime EXE and the DLLs. I have not tried this in years, but way back in time when the first 32-bit version of LB appeared, Neolite (which is no longer sold) would compress the runtime EXE, but UPX I can't remember if it had issues back then or not.

I agree that there's generally no good thing being wasteful about resources, but there is almost always a tradeoff to make.

I am not an expert assembly or C/C++ programmer, and I am not interested in being one.  I used to program in C many years ago and decided that it isn't worth it for me.  If it weren't for the Smalltalk language, Liberty BASIC probably wouldn't even exist.

So what's worse (or what's better), Liberty BASIC with a footprint of a few megabytes, or nothing?  ;-)

[Kuron]

Back in the day, Delphi was better (and easier) than C/C++ for Windows development. About the only C variants I ever liked were Pocket C for the PalmOS and SPIN which is what my HYDRA supports.

LB's footprint is minimal by today's standards. Fun comes in all sizes.

[Ronnie]

Carl / Kuron - Thank you for your responses. My madness for a small program may not make too much sense but, I am looking for a small footprint because I am trying to create (really recreate a small Menu/Interface Program)an interface for a CD with over 120 programs. The smaller the interface the more programs on the CD.

The Packer idea is good, but in the past some antivirus programs flagged some of my software that I had packed. Thanks again... Ronnie

[Kuron]

Ronnie I do understand. I very much want to keep things as small as possible and regularly work with platforms where everything has to fit into a few K of address space. Unfortunately, sometimes there is a trade off. In the case of LB, it is not bad in comparison to many of the other languages out there. It comes down to: you must use what best works for your needs. At the end of the day LB is just a tool.

As to AV software, I will repost something I said over a year ago on another forum:

The mafioso protection racket designed by AV authors with their false positives has become absurd.

These AV authors have literally made it almost impossible for an indie developer to exist. Something I have raved about for years, but it is getting increasingly worse over the years. Even if indie developers tell their customers the truth, that the program is fine and the AV company is wrong, the customers are still going to believe the multi-million dollar AV company and not run your software and bad mouth it for viruses.

As indie developers, we are expected to do the work of the lazy and incompetent AV authors and report false positives and hope and pray they safe list our program, which may or may not happen and may or may not require money changing hands. Self-proclaimed AV experts, have been running roughshod over indie authors for many years. The only ones who are not routinely dealing with false positives are the major software companies who do exchange some $$ with the AV authors.

I am amazed there have not been multiple class action suits against every AV author out there due to their continued false allegations that a program is or may be harmful when it is not.

Very hard to think about even trying to compete in today's software market...

[Ronnie]

Kuron - Thanks...