Embedding a Dll

[Clay Clear]

William,

The pleasure is all mine.

Also, good catch! And, you are correct, that you must use USING
if you specify the argument list when calling a function
with CALL DWORD. This is so the compiler has a reference to the
appropriate DECLARE so it will know the types, amounts, etc. of arguments
that the function uses.


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

[Mike Trader]

I have been erading Poffs to try and find an example of a DLL that
is compiled as a resource - RCDATA DISCARDABLE - and then loaded
into memory directly with LOADRESOURCE so that its functions
become available to the program.
I cant find any. So this is what I have that compiles but gives me
a GPF at run time.
GRFXDLL RCDATA DISCARDABLE
for resource

GLOBAL hRes AS DWORD, hLib AS DWORD, pAddr AS DWORD

FUNCTION PBMain AS LONG

hRes = FINDRESOURCE(BYVAL 0&, "GRFXDLL", BYVAL %RT_RCDATA)
hLib = LOADRESOURCE(BYVAL 0&, hRes)

'
'
'
pAddr = GetProcAddress(hLib, "PenColor")
CALL DWORD pAddr USING PenColor(%HIWHITE)


pAddr = GetProcAddress(hLib, "BrushColor")
CALL DWORD pAddr USING BrushColor(%HIBLUE)


pAddr = GetProcAddress(hLib, "DrawFrom")
CALL DWORD pAddr USING DrawFrom(50,100)


pAddr = GetProcAddress(hLib, "DrawRect")
CALL DWORD pAddr USING DrawRect(200,135)
any ideas?




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

[Clay Clear]

Mike,

I'm 99% sure that it simply cannot be done, as loading the DLL
into memory that is most likely very different than the "normal"
load that Windows does when a program needs to use it.

My suggestion is that you return to the original plan of extracting
the DLL and putting it on the HD. That way, you can use LoadLibrary, which
WOULD be a "normal Windows" loading of the DLL. I realize that
you're probably pretty frustrated and flustered after trying
to learn a "new" programming technique. But, the technique is
actually quite simple and straightforward, and if you can rise
above the bad emotions, then you can use logic to figure it out.
The way I learned how to do it, was I found source code from another
BBS member that showed it. So, I downloaded the code and analyzed it
until I understood it. Only THEN did I try to implement it myself.
Maybe a similar strategy will help you?

Anyway, I am not trying to "preach" to you. Am simply giving
you some friendly advice as somebody who's been-there-done-that.

Don't give up!


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

[Mike Trader]

Clay,
Thx, but no frustration here these forays into the unknown are
allways "interesting". I cant help thinking there must be a way
to load the DLL from resource into memory and get at the
functions. Its just a case of finding the address right.

But if all else fails then yes i can just drop it to the HD and load
it from there ...

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

[Clay Clear]

Oh, Mike, I think I noticed in your 2nd-to-last posting that your
line in your RC file is incomplete. The way it should be:

1 RCDATA DISCARDABLE "dllname.dll"

The first item can be either a numeric or name identifier. It is
the resource IDENTIFIER, NOT the actual name of the resource!
However, it CAN be the actual name of the resource, it's just
that that position is for the IDENTIFIER.
It is the last param, the one in quotes, that is the actual
name of the resource. The way I spelled it out assumes that
the resource file is in the current folder; if need be, you
can prepend the full path to the resource.

OK, as soon as I submit this, I'll go back and reread your posting,
to make sure I hadn't simply read it too quickly.




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

[Eric Pearson]

Going back to Mike's original question...

> I need to ship a single EXE, but that EXE
> requires a Dll (GRFXtools.Dll)

You have two basic choices:

1) Jump through hoops -- big hoops! -- and try to embed the DLL in your EXE. Or...

2) Use a Windows SETUP.EXE program. A setup program can contain as many files as you need (EXE, DLL, data, Help files, license files, README files, etc.) and it can handle details like the creation of a directory, the creation of Start menu, desktop and quick-launch icons/shortcuts, the addition of an Uninstall item in the Control Panel's "Add/Remove Programs" applet, and many other useful things.

IMO, trying to create a monolithic EXE that can be run from any directory is a hold-over from the days of DOS. In the Windows world it seems old-fashioned and, frankly, amateurish. (I'm not trying to be insulting, but that's the only word I can think of at this early hour. My point is that 99.9% of all professional Windows apps are installed by a SETUP.EXE program.)

Providing a SETUP.EXE file is very easy if you use a tool line INNO Setup (which is free) and it provides exactly what you asked for: a single EXE that you can ship to your users. The only difference is that the first time they run your program it will install itself cleanly and professionally on their system.

And in many cases the SETUP.EXE will be smaller than the EXE and DLL added together, because most setup programs use zip-like compression.

DLLs were not intended (by Microsoft) to be embedded in an EXE. People have found ways to do it, but why do it when the alternative is so attractive?

> Whats the common method for doing this

By a HUGE margin, the most common method is using a SETUP.EXE program.

-- 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).]

[Paul Dwyer]

Well,

While I see an advantage at times in have a single exe for tools and what not, I prefer that large programs are modularised and I use INNO setup like Eric. It also means that if you vendor (ie sql tools) releases a patched DLL to fix something for you then you can update just that DLL and not the whole program which is likely to get large if you are packing all your DLLs and reasources into it.

Seems like you are not achieving much extra with a single exe and may be paying in performance and opening yourself to more potential for bugs.

But like I say, it depends on what you are doing, somethings are better off small and simple

------------------
Paul Dwyer
Network Engineer
Aussie in Tokyo

[This message has been edited by Paul Dwyer (edited November 06, 2002).]

[Clay Clear]

Paul,

My setup EXE already contained the capability for the user to select
WHICH support files he wanted/needed to install. The setup EXE
never had to be modified to adjust for different/new/deleted
supported files embedded after I initially wrote its code. It was
all automated. If you're interested in the technique, I can reduplicate
the code and e-mail it to you, just so you can see the method it used.
However, the duplication would be different than the original, as I no
longer have the orginal source files. I dumped them for the sole reason
that I completely deleted my website, and no longer needed them.



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

[Lance Edmonds]

Folks, there are advantages to the user (<U>your</U> customer) for supplying a SETUP.EXE even if your actual app is just one EXE file...

• The end user can easily choose where it should be installed
  
• It's easier then explaining to technically-challenged users how to create a separate folder or where is the best place to install the app
  
• The user can be presented with a license agreement that they have to agree to before the install proceeds
  
• You can easily create desktop shortcuts to the installed EXE
  
• You can easily generate a log file of the install to assist in tech support problems
  
• The SETUP can add registry entries and even register COM components seamlessly
  
• Latter versions of Windows "track" the usage rate (although the "usage scale" is not very granular)
  
• The user gets an Uninstall listing in the "Add/Remove Programs" dialog

And there are probably other significant advantages too...

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

[Eric Pearson]

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).]

[Michael Mattias]

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

[Clay Clear]

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).]

[Michael Mattias]

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

; ** 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

[Clay Clear]

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).]

[Lance Edmonds]

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>

[John Schexnaydre]

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.



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

[Mike Trader]

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

[Eric Pearson]

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).]

[David L Morris]

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


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

[Borje Hagsten]

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..


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