LB Booster
« embedded resource file »

Welcome Guest. Please Login or Register.
Apr 1st, 2018, 03:32am



ATTENTION MEMBERS: Conforums will be closing it doors and discontinuing its service on April 15, 2018.
We apologize Conforums does not have any export functions to migrate data.
Ad-Free has been deactivated. Outstanding Ad-Free credits will be reimbursed to respective payment methods.

Thank you Conforums members.
Speed up Liberty BASIC programs by up to ten times!
Compile Liberty BASIC programs to compact, standalone executables!
Overcome many of Liberty BASIC's bugs and limitations!
LB Booster Resources
LB Booster documentation
LB Booster Home Page
LB Booster technical Wiki
Just BASIC forum
BBC BASIC Home Page
Liberty BASIC forum (the original)

« Previous Topic | Next Topic »
Pages: 1  Notify Send Topic Print
 thread  Author  Topic: embedded resource file  (Read 932 times)
ripvanwinkle
New Member
Image


member is offline

Avatar




PM


Posts: 1
xx embedded resource file
« Thread started on: Jun 29th, 2014, 04:13am »

I created a small program that uses a dll. When I create an exe of the program (with the dll embedded) and place it on the desktop and then run it, a copy of the embedded dll also appears on the desktop. Is there a way to prevent this behavior? Thanks!

User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 1348
xx Re: embedded resource file
« Reply #1 on: Jun 29th, 2014, 10:00am »

on Jun 29th, 2014, 04:13am, ripvanwinkle wrote:
Is there a way to prevent this behaviour?

I would first say that putting an executable on the desktop is never recommended, irrespective of the language in which it is created. Normally the EXE will be stored somewhere more appropriate (e.g. in C:\Program Files) and a shortcut to it placed on the desktop (and possibly also in the Start Menu). Creating such shortcuts is usually the responsibility of an installer.

So my preferred solution is to avoid the problem by not putting the EXE on the desktop in the first place! But if for some reason that is unacceptable your only alternative is to store your DLL not in the folder which contains the executable but instead in the temp folder. You can do that when you compile your program by using the Add Temp button instead of Add.

When your program runs you will need to specify the path to the temp folder when you OPEN the DLL (the GetTempPath API will return that string). You will also need to copy the DLL into the temp folder before you compile your program, in case it has been deleted from there.

Richard.
User IP Logged

ripvanwinkle
New Member
Image


member is offline

Avatar




PM


Posts: 1
xx Re: embedded resource file
« Reply #2 on: Jun 29th, 2014, 3:15pm »

Understand! Thank you for your quick and complete answer!
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 1348
xx Re: embedded resource file
« Reply #3 on: Jun 8th, 2015, 5:43pm »

A question has been asked at the LB Community Forum about embedded resource files (in the Global dim array question thread):

"I want the image to be compressed within the program. I am trying to put everything, including sounds, eventually inside a program efficiently."

Alyce has drawn attention to the Resource Hacker utility but of course LBB has a built-in mechanism for embedding resource files which automatically get extracted when the program is run. An advantage of the LBB approach is that the resources are available to the program as conventional files, but a possible disadvantage is that they are more easily examined by the end user.

Will somebody post a reply of the 'permitted' kind, i.e. that LBB provides an alternative solution, with a link to here?

Richard.
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 1348
xx Re: embedded resource file
« Reply #4 on: Jun 8th, 2015, 9:28pm »

on Jun 8th, 2015, 5:43pm, Richard Russell wrote:
a possible disadvantage is that they are more easily examined by the end user.

If this is a concern, there are a couple of approaches to making a resource file less easily snooped on:
  • The program can delete the file as soon as it's been used, so for example if it's a bitmap or sprite the program can LOADBMP it and then immediately delete the file. If this is done near the start of the program the file will exist only for a short time.

    Of course for this to work the program must be stored in a 'writable' directory, because the resource file will get extracted from the EXE, and then be deleted again, every time the program is run.

  • The resource file can be extracted to the temporary directory %temp% (or a sub-directory thereof). The user is unlikely to notice the appearance of a file there, or necessarily have any reason to think it is connected with a particular program. You might say the file is 'hidden in plain sight'.
Richard.
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 1348
xx Re: embedded resource file
« Reply #5 on: Jan 1st, 2017, 1:58pm »

I've received a query by email about the locations in which embedded resource files can be stored by LBB. Here are the options supported:
  • The 'current directory' (that is, the directory which contains your compiled EXE file). You can retrieve the path of this directory in your program as DefaultDir$.

  • A sub-directory of the 'current directory'; this may be nested to any depth. When your program is run for the first time this sub-directory will be created by LBB, if necessary.

  • The 'temporary directory' (that is, the directory identified by the %TEMP% environment variable). You can retrieve the path of this directory in your program using the GetTempPath API function.

  • A sub-directory of the 'temporary directory'; this may be nested to any depth. When your program is run this sub-directory will be created by LBB, if necessary.
If a resource file is found already to exist, and is identical to the file embedded in the executable, LBB will not attempt to replace it. This allows a program to be stored in a 'protected' location (e.g. C:\Program Files (x86)\) with admin privileges required only the first time it is run.

Richard.
User IP Logged

Pages: 1  Notify Send Topic Print
« Previous Topic | Next Topic »

| |

This forum powered for FREE by Conforums ©
Terms of Service | Privacy Policy | Conforums Support | Parental Controls