Announcement

Collapse
No announcement yet.

Embedding a Dll

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Lance Edmonds
    replied
    Topic closed due to extreme length. If further discussions are warranted, please start a new topic but be sure to include a link to this topic in the first message.

    Thanks folks!


    ------------------
    Lance
    PowerBASIC Support
    mailto:[email protected][email protected]</A>

    Leave a comment:


  • Don Dickinson
    replied
    Actually, my "c-selfx" software does this. It is now free including source for download from dickinson.basicguru.com
    It bundles a bunch of files together into one exe. When executed, it extracts them all and launches the one you tell it to. When that one finishes executing it deletes all of the extracted files. It might be worth a look if you're trying to get everything into one exe. The source requires both pbcc and pbdll to compile.

    --Don

    ------------------
    dickinson.basicguru.com

    Leave a comment:


  • Michael Mattias
    replied
    But if someone has got it to work, I would also like to see it.
    I've posted here some thoughts on this a couple of times, but just in text format, not in terms of working code. (No, I do not have URLs and I'm not going to try to find them with this BBS search. Maybe POFFS can filter better).

    You say you would like to 'see' it; would you be interested in paying for working code? (I'm thinking about $100 US/copy).

    (As a non-believer, I could only approach this on a mercenary basis).

    MCM

    Leave a comment:


  • Borje Hagsten
    replied
    Seems like only solution is to dump the embedded resource DLL to disk in
    order for LoadLibrary to work. And LoadLibrary seems to be needed. Searched
    Google and saw some samples, but all does just this, saves the DLL as a
    hidden file on load and then deletes it at exit.

    Guess that's what those "bundle" programs also do, only they also use
    some sort of compression/decompression routines.


    ------------------

    Leave a comment:


  • William Burns
    replied
    Mike, I understand.

    And if you do get it working, I would love to see an example.
    Because in the past I started to try it and read something that made me
    think it wasnt possible, so I dropped it in favor of creating the DLL
    file first.

    But if someone has got it to work, I would also like to see it.
    (I like having more options)

    William

    ------------------
    "I haven't lost my mind... its backed up on tape... I think??"

    Leave a comment:


  • Mike Trader
    replied
    Will,
    I like leaving the declares the same and the concept is good, but
    think about this. The wrapper EXE cannot have the same name as the
    application EXE because it would have to replace itself. So Im
    shipping an app that goes "pooooof" at run time and disppears to be
    replaced with the real app. Messy, and begs questions from the
    client. I can just hear it now ... "What did I do wrong, the app
    you sent me dissapeared. Please send it again, and again and again"

    Apart from that, I have to do 2 compiles to ship one app,
    not so bad true, but undesirable.

    I fairly certain that what I want to do is EMBED the dang DLL and
    either pull it out at run time and use LOADLIBRARY, or better yet
    load it straight into memory. The former I can do I think, anyone know
    how to do the latter?


    ------------------
    Kind Regards
    Mike

    Leave a comment:


  • William Burns
    replied
    Mike, I think Borje's suggestion would work for you. I have used
    a similar method in the past. The advantage of this approach is
    that since the DLL will exist when the main exe is ran, you can leave
    your implicit declares the way they are. And since your first
    program that runs, has no dependencies on the DLL, you will not get
    the errors you were getting.

    Here is an example: (see my earlier post for a link to the inc file)
    Code:
    #COMPILE EXE
    #RESOURCE "MyResFile.PBR"
    #INCLUDE "MakeFile.INC"
    FUNCTION PBMAIN () AS LONG
      LOCAL zSysDir AS ASCIIZ * %MAX_PATH
      LOCAL NewFile AS STRING
      ' here you could have your program search to see if the files are already there, if so, just run the main exe
      IF GetSystemDirectory(zSysDir,%MAX_PATH) = 0 THEN
         MSGBOX "Failed to get Windows System dir",,"Error"
      ELSE
         NewFile = zSysDir + "\MYDLL.DLL"
         IF MakeFile("MYDLL",NewFile) <> 1 THEN MSGBOX "Failed to create MYDLL.DLL",,"Error"
         IF MakeFile("MYEXE","c:\MyProg.EXE") <> 1 THEN MSGBOX "Failed to create MYProg.EXE",,"Error"
         SHELL "c:\MyProg.exe"
         'here you could possibly use KILL to remove any unwanted temp files
      END IF
    END FUNCTION
    Of course it does add some overhead, and possibly places to break down,
    but if you dont want the setup program, this might be an option.


    ------------------
    "I haven't lost my mind... its backed up on tape... I think??"

    Leave a comment:


  • Mike Trader
    replied
    David,
    Ill take another look at it. Im sure I used it a while ago. from
    what i remember it was very cool. The only problem is I have to
    got thru all the setup EACH time i send out my app. Thats a pain.
    It does solve the problem of a single app that does not prompt
    the user like an installer tho ... Close but no Cigar

    Borje,
    If you come up with anything pls let me know.

    ------------------
    Kind Regards
    Mike

    Leave a comment:


  • William Burns
    replied
    Lance and Eric,
    I agree that their a lot of benefits to using a setup program.
    The program will show up in the list of installed apps, can be easily
    uninstalled by the control panel, custom dirs, etc...

    However, everyone is stating that a setup.exe is always the better option.
    And I have to strongly disagree. For example I often build utilities
    that need to be ran on hundreds of different PCs, but only once to make
    updates. It would be crazy to 1.)run the setup 2.) run the program
    3.) uninstall it. By embedding the file, I can run my utilities from
    login scripts, it will first check it the update was already done, if
    not it will create any needed DLLs, etc then run the update.(all in
    one step sometimes transparent to the user)

    So again, setup is better 99% of the time, but not always.

    William

    ------------------
    "I haven't lost my mind... its backed up on tape... I think??"

    Leave a comment:


  • Borje Hagsten
    replied
    You could pack both files into a one-file installation and give it
    similar name as the program. When user first time starts it as
    instructed, it unpacks the files silently, after which it starts
    the real program before exit. To wipe out all traces, real prog
    can look for installer at first run and delete it if there.

    Don't know if INNO can do this, but maybe you have access to more
    advance installer that can. I use Wise myself and there have used
    it's recursive search feature in upgrade package, so users can start
    it from anywhere, and it automatically searches/finds prog to update.
    Have had 0 calls for help with that one.

    Have unfortunately no answer to real question, about embedding a DLL,
    but the above way should be just as support free, or probably even
    more support free.

    Whish I had more time to play - question still is interesting and can't
    be impossible to solve. Probably even exist easy solution - but hard part,
    as always, is to find out that easy answer..


    ------------------

    Leave a comment:


  • David L Morris
    replied
    Mike

    [If anyone else has a better idea
    that does not require an installer and ships a single app that will run
    upon launch, lets hear it.]

    Again, I think you might ask Don Dickinson more of his C-Selx. It can be set to compile all
    dependent files into one exe and when it is started, it will expand all files, run the
    main program. It can also be instructed to delete all the dependent dlls and other files
    when the main program ends, so there is nothing left in the directory, apart from the
    original C-Self exe.

    It can also be set to not run after a termination date.

    I have tested these features and found it quite satisfactory, however, I am not a distributor
    of commercial software. I develop In-House applications.

    Regards,

    David


    ------------------

    Leave a comment:


  • Eric Pearson
    replied
    Mike --

    > I get the definate impression the Perfect Sync
    > dont want me to do this for some reason

    Nope, that's an incorrect impression.

    > I wanted to explore it, get it to work and then
    > decide - (with your permission of course Eric)

    You don't need my permission. You may distribute the Graphics Tools DLL according to the terms of the License Agreement which applies to the version of the product for which you have a valid license.

    We don't care whether you distribute the DLL directly, or put it in a SETUP.EXE program, or embed it in your EXE, or anything else, as long as you do it within the terms of the License Agreement. (I am being purposely vague because our licenses provide different rights for different products and versions. See http://www.perfectsync.com/SoftwareLicenseAgreement.htm for specific information.)

    But as Paul explained when you contacted [email protected] about this technique, we can't help you. We have never embedded a DLL in an EXE here, and we don't encourage people to do it -- meaning that we don't go around saying "Hey, try this!" -- so you're on your own. If anything, we have been trying to encourage you to use a technique that we could help you with. Nothing more and nothing less.

    Ok, I was also trying to encourage you to use a common, standard technique instead of an unusual one. But that was just a friendly suggestion from me personally, not "official" advice from Perfect Sync. I would have given you the same advice even if the DLL wasn't one of my company's products.

    -- Eric

    ------------------
    Perfect Sync Development Tools
    Perfect Sync Web Site
    Contact Us: mailto:[email protected][email protected]</A>

    [This message has been edited by Eric Pearson (edited November 06, 2002).]

    Leave a comment:


  • Mike Trader
    replied
    OK guys, I guess I'll have to explain a little more here since you are all jumping to
    HUGE conclusions incorrectly. The first thing I should mention is that I am
    shipping an INCOMPLETE app on a regular basis. Right now I am
    developing a SMALL app for a client (122k without splash screens
    and icons, 500k with) If I include the GrfxTools Dll and then
    compress the EXE using UPX, the grand total is 324k!

    Now you might say well thats alot of hassle, including the DLL as
    a resource, and compressing the whole thing, you might as well
    use INNO.

    Well, I wrote a wrapper, (available shortly as plug in for Jellyfish) based
    on an original idea by semen (thankyou semen) that handles this
    in two lines:
    'xResource GRFXDLL RCDATA DISCARDABLE Includes/GfxT_Std.DLL
    'xCompress
    EVERY time I hit the compile btn the resource is made and the
    resulting EXE compressed. I turn it off when developing but as
    you see its so simple to engage

    So now I have a very small app. And BTW most of my EXE/DLLs are
    small. My clients are usually NOT that technically savvy and require
    really simple obvious steps.

    I recently made an demo app that I sent to a bunch of clients as
    a demonstation of what could be done with Fibonacci analysis.
    It had a run time DLL in keeping with the logic we programmers
    accept as making sense.

    I did not use an installer because people are terrified of them. In the
    financial arena, a computer has a very different significance. If you
    earn a living with that machine it is treated very differently than your
    home computer. Some clients have both, but most use one and are VERY
    wary of installing anything in case it messes with the settings of something
    that is currently working. Just the visual of an installer taking over the whole
    screen is a bad idea in the first place (i forget if INNO does this).
    As you know the instant messenger apps are incidious. You cant shut em
    down, they plaster themselves everywhere and throw things in your face, is
    it any wonder people are gunshy. Nortom tools with its incessant reminders
    any app with the registration nag screens or what ever.

    It is a rare app that does JUST what it advertises
    and nothing more, so the assumtion is my apps installer will too. They dont
    have the time to go thru and find all the folders and shortcuts and launch items
    and remove them all. The UNINSTALL for the most part on most apps
    does not remove everything. People know this. they generally dont like
    installers unless it is from a very reputable source.

    So i zipped up both the EXE and the DLL and sent the Zip. Well you
    would be surprised how many people had problems with the ZIP archive
    when attached to an email. So i put the zip up on a website for download.
    There were still problems, fewer, but still problems with unzipping!
    Finally i put a link to the EXE and the DLL so they could d/l both.

    Well that was too hard for some of them. "whats a DLL", "Do I need it"
    "isnt that system stuff? wont it mess up my system" "your app doesnt run,
    should I try the DLL" I put the DLL in the MY DOCUMENTS folder,
    but the app still wont run" etc etc

    As you can imagine this wastes alot of my time in responding to these
    kinds of problems. The solution, for me anyway, is to just ship one file:
    MyAPP.EXE. No installers, no required DLLs, No zip files, just the APP.

    THIS WORKS 100% of the time
    At 324k size is really not an issue

    The next assumption you guys have made is that I have a finished APP.
    I do not I am developing an APP. At each major stage I send a copy
    to the client for review and feedback. Sometimes this is once a day. At
    the end of a 16hr day coding the last thing i want to do is switch gears
    and get my head into INNO to produce an installer. One option screen
    from INNO is one two many at that point I want to simply attach it and
    send it. over and over and over. Thats alot of time saved

    Also, I am sure my client does not want to run an installer every day to get
    the latest version. Im sure he has a folder all set up ready to drop it into. Its
    just so fast and hassle free. Download, double click, done!

    If I do upgrade to GrfxT_Pro.DLL then it is seamless to the client as it is
    included with the app and he will never know. There will never be any
    confusion about two Dlls in the folder and which one do i need etc etc.

    I am not in the business of educating clients as to waht is professional
    software approaces or not. I am in the business of providing solutions
    to financial problems. I dont care if it is not considered correct etiquete,
    I want my clients to run my app, they want to run my app. whatever it
    takes to accomplish that is fine with me

    I did not create the environment that I develop in, I am simply
    responding to it. This is my solution to an imperfect situation that
    works, guaranteed, 100% of the time. If anyone else has a better idea
    that does not require an installer and ships a single app that will run
    upon launch, lets hear it.

    As Paul put it so well:
    > somethings are better off small and simple
    I am just in a different environment. I had one client that has traded
    with DOS for 15 years. He wanted to convert it to windows. He
    has stuck with DOS because it works. He makes money with it. He is
    terrified of windows. He bought a new machine and when I had him
    on the phone it became apparent that he did not understand how to
    resize a window! It took me 2 hrs to get him to zip up his dos app
    and send it to me. He is prime example of it aint broke, dont fix it.
    He probably is a good candidate for an installer, but my point is
    sucessfull people in this field are often not at all technically savvy.

    I get the definate impression the Perfect Sync dont want me to do this
    for some reason, and I may end up not doing it if it really is alot of code
    to load an embedded DLL and get a pointer to a function within that
    DLL, but I wanted to explore it, get it to work and then decide -
    (with your permission of course Eric)

    So could someone give me an example of loading a DLL from resource
    into memory, and then getting a pointer to the functions now ... please...


    PS. How hard is it to get word wrap to work on this board?


    ------------------
    Kind Regards
    Mike

    Leave a comment:


  • John Schexnaydre
    replied
    Well Mike, I warned you that attaching the Dll as a resource
    would raise some posts

    For a simple one EXE program, where I may need the DLL, I've
    found this to work just fine with no issues on the unload and
    no need for a setup.exe. Other programs may well need them and
    of course then you should have one you like and use it.



    ------------------

    Leave a comment:


  • Lance Edmonds
    replied
    Check out ScriptMaker too... although it is no longer being developed, it adds a wizard-like GUI for creating and editing scripts. I'm not sure if it is still compatible with the latest Inno buils though... I've not updated for some time now as I have a combination of INNO [Extensions] and ScriptMaker that works well for me.

    ------------------
    Lance
    PowerBASIC Support
    mailto:[email protected][email protected]</A>

    Leave a comment:


  • Clay Clear
    replied
    Michael,

    Thanks for the hyperlink!

    However, your sample script was pretty much "greek" to me.
    I guess I'll have to do some indepth reading of the INNO
    documentation, then use it for test runs, until I understand it.

    Just reread your sample script. It now makes a lot more sense
    to me than the first review did.


    ------------------


    [This message has been edited by Clay Clear (edited November 06, 2002).]

    Leave a comment:


  • Michael Mattias
    replied
    Since you are going to Inno...which you will find at http://jrsoftware.org/ ...

    Here's a 'real' script with some comments you may find useful.

    (Names have been changed to protect the guilty.)

    (The funky capitlization comes from using the PB/IDE to do the search-replace of the guilty names)

    MCM


    Code:
    ; ** INNO SETUP SCRIPT FOR CLIENT Demo OF Desktop remittance
    ; CLIENT_SETUP_SCRIPT.ISS
    ; Created 11-05-02 MCM
    ; =====================================================================
    ; CREATE the directories needed ON the USER system
    ; =====================================================================
    [Dirs]
    ; programs AND support files
     NAME: "{app}\System"
    ; remittance files
    NAME: "{app}\Remittance Files"
    ; reports
    NAME: "{app}\Reports"
    ; CSV
    NAME: "{app}\CSV"
    ; =====================================================================
    ; Options FOR source files when creating setup.exe AND
    ; ON the USER system AT installation time
    ; =====================================================================
    [Setup]
    AppName=CLIENT Remittance Processing
    AppVerName=Demo-Vaporware
    AppCopyright=Copyright 2002 Michael C. Mattias Racine WI
    Uninstallable=yes
    AlwaysCreateUninstallIcon=yes
    DefaultDirName=C:\CLIENT
    DefaultGroupName=CLIENT Remittance Processing
    ; 'source' for unqualified files specified in [Setup] and [Files] sections of this script
    SourceDir=C:\Software_Development\pbwin70\work\CLIENT
    DisableProgramGroupPage=yes
    OutputDir="\Software_Development\pbwin70\work\CLIENT\setup\"
    OutputBaseFileName="CLIENT_setup"
    WizardImageFile="C:\My Documents\Tal Systems\Artwork\tal_lg_120x60.bmp"
    ; Tal Dark Green = RGB 108, 132, 80 = x'6C', x'84', x'50'
    ; Tal Light Green  = RGB 148 172 117 = x'94' x'AC', x'75'
    ; Inno wants "$bbggrr" (ERROR IN help file? should be $rrggbb ? NOPE OK)
    WizardImageBackColor=$75AC94
    ; ======================================================
    ; FILES SECTION USES SourceDir FROM Setup Section
    ; ======================================================
    [FILES]
    Source: "CLIENT.exe"; DestDir: "{app}\system"
    Source: "ddoc.exe"; DestDir: "{app}\system"
    Source: "ddoc32.dll"; DestDir: "{app}\system"
    ; BMP files used FOR watermarks AND logos
    Source: "CLIENT_logo.bmp"; DestDir: "{app}\system"
    Source: "CLIENT_wm.bmp"; DestDir: "{app}\system"
    Source: "CLIENT_brush.bmp"; DestDir: "{app}\system"
    Source: "bcbs_logos.bmp"; DestDir: "{app}\system"
    ; DATA files
    ; dummy report file
    Source: "CLIENT_report.txt"; DestDir: "{app}\system"
    ; Demo Remittance ANSI files
    Source: "C:\Software_development\Testdata\EDI_DATA\03900125.025"; DestDir:"{app}\Remittance Files"
    Source: "C:\Software_development\Testdata\EDI_DATA\835(3) and 997(2).txt"; DestDir:"{app}\Remittance Files"
    Source: "C:\My Documents\Clients\Prospects\CLIENT\RemitFiles\h8354010wiscout.txt"; DestDir:"{app}\Remittance Files"
    Source: "C:\Software_development\Testdata\EDI_DATA\HIPAA Compliant\PLB_TEST_FILE.EDI"; DestDir:"{app}\Remittance Files"
    [Icons]
    NAME: "{group}\CLIENT Remittances Demo"; Filename: "{app}\system\CLIENT.exe"; workingdir:"{app}\system"
    
    
    ; END OF INSTALL SCRIPT FOR CLIENT REMITTANCE DEMO

    Leave a comment:


  • Clay Clear
    replied
    Eric,

    You have completely humbled me, in a GOOD way. Because of what
    your last reply, and Paul's, and Lance's, said, I think that *I* will
    start using INNO. You are completely correct, and RIGHT, that I
    made false assumptions on software that I never even took for a test drive.

    I will move to INNO, if for no other reason, than what you said
    about it only requiring one script file. That would be ENORMOUSLY
    easier than having to rewrite the setup EXE, and the supporting
    files, etc., that I was previously using, from scratch. I am putting
    up a website and starting to distribute my public softwares again,
    after a 6 month hiatus.

    So, do you have a URL where I can go to download the INNO package?
    I already have my website (with Tripod <YUCK!!!> ), and as soon as
    I create the HTML's, I will start using INNO to package my public softwares
    and start uploading them.

    Thanks again, Eric. Your gentlemanly ways do you credit.


    ------------------




    [This message has been edited by Clay Clear (edited November 06, 2002).]

    Leave a comment:


  • Michael Mattias
    replied
    In this case I was saying that I think a SETUP.EXE-style program is a better solution than a main EXE with an embedded DLL, that's all
    Check-mark.

    MCM

    Leave a comment:


  • Eric Pearson
    replied
    Clay --

    [Hmmm... In the time it took me to compose this Clay edited his message and changed everything I responded to. No sense playing Dueling Edits, so I'll just post what I wrote.]

    First off, I'm not offended in any way. Different strokes for different folks!

    > Because of its need to be generic enough
    > to cover a wide range of possible setups,
    > INNO probably requires a LOT more setup
    > than my method. The only thing *I* had to
    > manually keep up-to-date was the plain-text
    > CFG file

    That's an incorrect assumption about INNO. All you need to update is a plain-text script file which tells INNO what you want it to do. A tool is available for building the initial file and from then on, making changes is a snap. (In most cases I simply update my program's files and click "Build" without changing the script.)

    > I find it very hard to believe that something
    > like INNO can do very many things that I could
    > not implement myself in my own setup EXE.

    Of course you can write your own SETUP.EXE! But I didn't think that's what we were talking about. I was expounding on the benefits of using a SETUP.EXE instead of trying to bundle a DLL with an application's main EXE. The benefits I mentioned would apply to ANY setup program, I just used INNO as an example. Mike wants to be able to send his users a monolithic EXE which is the actual program, not a setup program.

    > And, personally, I am TIRED of the many dialogs
    > you have to go through to simply install software
    > that uses something like INNO.

    INNO allows you to specify which dialogs are displayed. Nearly all of them are optional. Maybe all... I have never tried to strip one down that much.

    > I don't have any concrete evidence, but I find it
    > hard to believe that MOST end users even CARE WHAT
    > folder in the Start Menu is used by the software, or
    > what folder in the Program Files folder the software
    > uses.

    I (for one) appreciate the opportunity to choose the drive, at least. But with INNO you don't have to ask them if you don't want to.

    > I find very little USE for the dialog that asks,
    > "The specified folder does not exist.

    That too is optional with INNO. You're making a lot of assumptions about a program you haven't used.

    > I realized EARLY in my life that, just because
    > something is the "norm" and "standard" and "de
    > facto" standard does NOT mean that it is necessarily
    > the BEST standard.

    I agree 100%. But I'm not sure that doing something in a nonstandard way is necessarily virtuous either. In the case of something "routine" like an installation program, I appreciate it when a program uses a standard system. And if the first impression a new user has is "Ok, I know how to do this" that's generally a good thing. (Imagine what Windows would be like if every program "did its own thing". It would be like... Linux. {GD&R})

    > I personally use the DEFxxx verbs instead of
    > explicitly declaring my variables. I never, ever
    > use "#DIM ALL".

    Don't get me started!

    > I believe that your comments are purely SUBJECTIVE.
    > YOU may believe that they are OBJECTIVE, simply
    > because they are the "standard" beliefs.

    I'm not sure why you think I believe that. I do have strong opinions about certain things, and I do tend to tell people what I think, but I don't think I have a habit of claiming to be "absolutely right". At least I hope not!

    In this case I was saying that I think a SETUP.EXE-style program is a better solution than a main EXE with an embedded DLL, that's all.

    -- Eric


    ------------------
    Perfect Sync Development Tools
    Perfect Sync Web Site
    Contact Us: mailto:[email protected][email protected]</A>

    [This message has been edited by Eric Pearson (edited November 06, 2002).]

    Leave a comment:

Working...
X