My program basically does nothing more than extracting the included PAK archive to a temp location & extracting the included files to their final destination and has basically nothing in common with Thinstall.
It was meant as reference for my observation of the "memory issue".
Same effect as in this small code:
Code: Select all
Result = CatchImage(0, ?small)
If OpenWindow(0, 218, 39, 530, 434, #PB_Window_SystemMenu | #PB_Window_TitleBar , "")
If CreateGadgetList(WindowID())
ImageGadget(0, 10,10,100,100,UseImage(0))
ButtonGadget(1,10, 10, 50, 20, "Click me")
EndIf
EndIf
Repeat
Select WaitWindowEvent()
Case #PB_EventGadget
Select EventGadgetID()
Case 1
Result = CatchImage(1, ?large)
EndSelect
Case #PB_EventCloseWindow
End
EndSelect
ForEver
Test1: IncludeBinary "c:\small.bmp"
Test2: IncludeBinary "c:\large.bmp"small.bmp is 1.37 MB and
large.bmp is 25.7 MB of size.
When _I_ run it, the programe consumes 3.2 MB memory RAM, until I click the button and the CatchImage loads the large bitmap, making the program to consume ~29 MB.
I don't know if this behaviour is the same on any platform (I'm using Win 2K/SP4) and to which extent one can include ressources without consuming too much (unused) memory in RAM or to which extent the god of volantile memories watches over reasonable usage...
...but, hey, it's an interesting topic and...
... - no offense meant - by my observations, IncludeBinary (upped with individually encrypted data probably?) seems to be a well solution for protecting own software to a certain extent.I think I've showed that the IncludeBinary command is only a solution for a very limited number of resources and then lacks some functionality
Maybe now it's time to ask the god of volantile memories... Fred? Fred? Can you hear me?
-




