Where To Write My File

[Ivar]

Hi All

Been very quite here recently, hopefully a few VB6 gurus are still
monitoring?

I have an app that writes compressed files to users chosen location.
This compression was done internally by the app itself but it was a bit
slow.
So I downloaded a dll file that does just as good a job but sooo much
faster.
What I would like to be able to do is have this dll stored in the resource
file of the exe and create it as and when needed.
Every end user (and they are all idiots! Example via phone call: Me 'Click
the start button' User 'Where's that?', Me 'Bottom left', User 'You mean the
button with ctrl on it?) has the exe file in the Programs folder or Programs
x86 folder.
The dll file needs to go to the System folder or the App.Path folder in
order to work.
Both of which the exe file cannot write to
how can I Get my app to write the dll file to app.path folder or
Write it to the system (not system32) folder or
Modify the API declare so the dll will work if in a writable folder.
may be a registry entry or something
Really, end users can just about replace the exe file with an updated one
via 30 mins of phone call.
There is no way I could survive the stress of sending each end user a dll
file to put on their hard drive.
P.S. I only ever distribute the exe file, The App never needs installing.

Any Ideas?
Ivar

User 'Hi, How do I [Simple Question]
Me 'The same way I told you yesterday'
User 'Yeah - but I forgot'

[Jim Mack]

Post by Ivar
I have an app that writes compressed files to users chosen location.
This compression was done internally by the app itself but it was a bit
slow.
So I downloaded a dll file that does just as good a job but sooo much
faster.
What I would like to be able to do is have this dll stored in the
resource file of the exe and create it as and when needed.

This won't work on any system with even moderate anti-virus monitoring.

Just use an installer, and put the DLL into your app folder. Try Inno
Setup -- it's simple and free and follows all the standard rules.

[DaveO]

Post by Ivar
Hi All
Been very quite here recently, hopefully a few VB6 gurus are still
monitoring?
I have an app that writes compressed files to users chosen location.
This compression was done internally by the app itself but it was a bit
slow.
So I downloaded a dll file that does just as good a job but sooo much
faster.
What I would like to be able to do is have this dll stored in the resource
file of the exe and create it as and when needed.

You can copy the file to a Resource file as a "Custom Resource" then use
something like this to write it to disc:

Public Function ExtractFromResource(ResName As String, NewFileName As
String, Optional bnSilent As Boolean = False) As Boolean
Dim fBuff() As Byte
Dim ff As Integer

fBuff = LoadResData(ResName, "CUSTOM")
ff = FreeFile
On Error GoTo ErrBadPath
Open NewFileName For Binary As #ff
Put #ff, , fBuff
Close #ff
On Error GoTo 0
ExtractFromResource = True
Exit Function

ErrBadPath:
If Not bnSilent Then MsgBox "Error writing to selected path, check your
permissions", vbExclamation, "Write Error"
ExtractFromResource = False
End Function

However as Jim pointed out, depending upon where you try to write the file
any anti-virus software is going to take objection to such behaviour.
(The above code is just a starting point, it need testing for existing file
and again to ensure the file was actually written, although that could
easily be in whatever calls this routine)

Regards
DaveO.

[Deanna Earley]

Post by Ivar
Hi All
Been very quite here recently, hopefully a few VB6 gurus are still
monitoring?
I have an app that writes compressed files to users chosen location.
This compression was done internally by the app itself but it was a bit
slow.
So I downloaded a dll file that does just as good a job but sooo much
faster.
What I would like to be able to do is have this dll stored in the
resource file of the exe and create it as and when needed.
Every end user (and they are all idiots! Example via phone call: Me
'Click the start button' User 'Where's that?', Me 'Bottom left', User
'You mean the button with ctrl on it?) has the exe file in the Programs
folder or Programs x86 folder.
The dll file needs to go to the System folder or the App.Path folder in
order to work.
Both of which the exe file cannot write to

Does it NEED to be in that path or is it just that the Declare Function
in VB only looks in those paths?

If you extract to the temporary folder, you can call LoadLibrary() on
the new path and that will then be used by the VB Declare calls.

Alternative, just install it as normal. I can't think of any reason why
not to do this.

Post by Ivar
Really, end users can just about replace the exe file with an updated
one via 30 mins of phone call.

Not if it's in Program Files, as they can't write to it without doing
silly things like agreeing to delete system executables :)

Post by Ivar
There is no way I could survive the stress of sending each end user a
dll file to put on their hard drive.
P.S. I only ever distribute the exe file, The App never needs installing.

A setup will make this MUCH easier on them and you and it comes down to
"Run this, click "Next" then "Install".

[Ivar]

Thanks to Jim and Dave for the replies so far.

I found the following lines of wisdom in MSDN:
If you do not specify a path for libname, Visual Basic will search for the
file in the following order:
Directory containing the .exe file
Current directory
Windows system directory (often but not necessarily \Windows\System)
Windows directory (not necessarily \Windows)
Path environment variable

So:
Extract file from resource file and write it to
Drive\Users\UserName\Appdata\ProgName
Change the Current Drive to The Drive of Users\UserName\Appdata\ProgName)
Change the current directory to Drive\Users\UserName\Appdata\ProgName

VB then finds dll in the second place it looks. Seems to work OK. In exe and
VB IDE.

I don't use any antivirus software, Being so file has .dll extension will
this cause any problems?
May be someone with VB6 and antivirus software can test this for me?

Thanks for reading

Ivar

[DaveO]

Post by Ivar
Thanks to Jim and Dave for the replies so far.
If you do not specify a path for libname, Visual Basic will search for the
Directory containing the .exe file
Current directory
Windows system directory (often but not necessarily \Windows\System)
Windows directory (not necessarily \Windows)
Path environment variable
Extract file from resource file and write it to
Drive\Users\UserName\Appdata\ProgName
Change the Current Drive to The Drive of Users\UserName\Appdata\ProgName)
Change the current directory to Drive\Users\UserName\Appdata\ProgName

Hi

Rather than doing the Change Drive and Change Directory stuff, you'd
probably be better off using the LoadLibrary call as suggested by Deanna.

Regards
DaveO

[Ivar]

Post by DaveO
Hi
Rather than doing the Change Drive and Change Directory stuff, you'd
probably be better off using the LoadLibrary call as suggested by Deanna.
Regards
DaveO

Could be a very good idea, I will look in to it, however:
I see no posting from 'Deanna'. Am I missing a posting?

Ivar

[Deanna Earley]

Post by Ivar

Post by DaveO
Hi
Rather than doing the Change Drive and Change Directory stuff, you'd
probably be better off using the LoadLibrary call as suggested by Deanna.
Regards
DaveO

I see no posting from 'Deanna'. Am I missing a posting?

Here's a link to the post on my local server: news://news.aioe.org:119/k783ev$n0i$***@speranza.aioe.org

I basically said Extract to a temporary file and LoadLibrary() it.

Or just create an installer which makes it much easier all round.

[GS]

There's some confusion with your explanation! What do you mean when you
say "how can I get my app to write the dll file..."?

A DLL needs to only reside in the App.Path to use it. Your app needs
only to declare the function[s] it wants to use. So now your app
distribution includes 2 files: exe & dll! Easy to zip and email, but
you could upload it to a web server where others can download the
update files.

Note that the DLL doesn't have to be *registered* on the system to use
it!

HTH

[Ivar]

Hi Garry

Did you miss the bit that says "P.S. I only ever distribute the exe file,
The App never needs installing."

I don't want (because half of them cant) end users to install, far to
complex a thing to do.
All sorted now, the dll file goes to Appdata\Local\ProgName and all is
working fine.

Thanks for you reply

Ivar

I still see no posting from 'Deanna'
I wonder if there are other replies I'm missing?

"GS" wrote in message news:k7r2v6$am3$***@dont-email.me...

There's some confusion with your explanation! What do you mean when you
say "how can I get my app to write the dll file..."?

A DLL needs to only reside in the App.Path to use it. Your app needs
only to declare the function[s] it wants to use. So now your app
distribution includes 2 files: exe & dll! Easy to zip and email, but
you could upload it to a web server where others can download the
update files.

Note that the DLL doesn't have to be *registered* on the system to use
it!

HTH

[GS]

Did you miss the bit that says "P.S. I only ever distribute the exe file, The
App never needs installing."

I did not miss that part. A zip file isn't an installer and so my point
is if users can copy 1 file to a location then surely copying 2 files
to a location isn't too complex. Since a zip utility allows you to
choose the location to unzip to, it just make sense to me to distribute
2 separate files. (I wish my apps had so few!<g>)

All sorted now, the dll file goes to Appdata\Local\ProgName
and all is working fine

Glad you got it sorted...

[Thorsten Albers]

Post by Ivar
All sorted now, the dll file goes to Appdata\Local\ProgName and all is
working fine.

Could you please give me the name of your program? I need this in order to
let it never make itself comfortable on any of my hard disks or hard disks
of my friends...

[Ivar]

Post by Thorsten Albers
Could you please give me the name of your program? I need this in order to
let it never make itself comfortable on any of my hard disks or hard disks
of my friends...
Thorsten Albers

ooooo, That is so unfair :-(
The program used to be called 'The Program' until the first client I demo'd
it to saw one of it's functions and said 'Wow, That's Magic'. Since then the
program has been called 'Magic'.
It's a very specialized piece of software used by outsource payroll
processing companies, useless to anyone else.
One of my rules on software development is to have no external references
except what's in winders. No ActiveX, No Dlls. So all the user controls and
objects are within the compiled exe.
Sometimes I have to re invent the wheel to achieve this, and it can make
things very hard work. Try getting a vb6 app to write .xls files without
Excel being installed or pdf files without any of Adobe's Dlls. It's
probable that all computers where "Magic" Exists have these references, or
may be not. I don't take the chance.
So: As I said in the first post, the internal compression algorithms in the
App were good, but just to slow, so I downloaded someone else's DLL file,
referenced it and all works well and so much faster. The problem was how to
get it to work on clients PCs without baffling the PC Illiterate end users
because of Winders protection of system directories. Problem Now Solved.

Ivar.

Me: Now Click The Reports Button.
Client: Which one's That?
Me: The One With Reports Written on it
[True!]

[Schmidt]

Post by Ivar

Post by Thorsten Albers
Could you please give me the name of your program? I need this in order to
let it never make itself comfortable on any of my hard disks or hard disks
of my friends...
Thorsten Albers

ooooo, That is so unfair :-(

Just a little bit ;-) ... (only, to underline a point I think).

Post by Ivar
One of my rules on software development is to have no external
references except what's in winders.No ActiveX, No Dlls.

A rule, I never really understood - but which seems to be
common... I also don't like Setup-Programs, but that does not
mean, that one has to follow the "all-in-one-single-Exe" rule
slavishly - there's regfree mechanisms out there, which can
help even with ActiveX-Dlls (SxS+Manifests or DirectCOM.dll)
or OCXes (SxS+Manifests), which allow you an XCopy-Deployment
of your "Binary-Set" in a Zip-File - or in a Folder on an USB-
Stick or whatever).

Post by Ivar
So all the user controls and objects are within the compiled exe.
Sometimes I have to re invent the wheel to achieve this, ...

That's exactly the point - and as it seems, you now broke your
own "rule" for the sake of more performance.

IMO there's no "shame" in admitting, that ones own "Magic"
Software-Solution (no pun intended) has a few dependencies,
not of "your own making". Dependencies are perfectly normal -
they are the norm - the Win-System-Directory is full of them ...
there's always 3rd-party-Dlls, which are required to make
your own solution work on a given OS.

So, what it boils down to is "ease of deployment".
A single executable obviously being the easiest way...
but as GS already pointed out, a Folder (contained in,
or "draggable" from a *.zip-File) works nearly as well
on the customer-side with regards to XCopy-deployment
(saving yourself a lot of development-time, or as in your
case, also offering better performance - at the small cost
of two additional Mouse-Operations on the customers end -
dragging a Folder from a *.zip instead of an executable -
and creating a Desktop-link manually).


Olaf

[Mike Williams]

[Ivar said] One of my rules on software development is to
have no external references except what's in winders. No
ActiveX, No Dlls . . . So all the user controls and objects
are within the compiled exe. Sometimes I have to re invent
the wheel to achieve this, ...

[Olaf Schmidt said] - and as it seems, you now broke your
own "rule" for the sake of more performance.

Actually I don't think he did break his rule, Olaf, or at least he did not
break his own interpretation of that rule. As far as I can gather from his
various posts the OP has embedded the DLL file into his compiled exe (as a
resource I imagine) and at runtime his code is extracting the DLL and saving
it to a specific folder which is available for writing on the machine on
which his exe is running and he is then using LoadLibrary so his code can
use it from the location to which his exe saved it. This enabled him to
still send just a single exe file to his customers. At least that's what I
think he is doing . . . and I'm sure you'll have a few things to say to him
about that ;-)

Mike

[Schmidt]

Post by Mike Williams

[Ivar said] One of my rules on software development is to
have no external references except what's in winders. No
ActiveX, No Dlls . . . So all the user controls and objects
are within the compiled exe. Sometimes I have to re invent
the wheel to achieve this, ...

[Olaf Schmidt said] - and as it seems, you now broke your
own "rule" for the sake of more performance.

Actually I don't think he did break his rule, Olaf, or at least he did
not break his own interpretation of that rule.

Ok, he at least broke the "I always need to make my own wheel"-part
of the rule (by inexplicably using an established, well-tested and
fast *.dll, labeled with the attribute: "not invented here")... ;-)

But the NIH-syndrome is common among Devs (I'm addicted myself). <g>

Post by Mike Williams
As far as I can gather from his various posts the OP has embedded the DLL file
into his compiled exe (as a resource I imagine) and at runtime his code is
extracting the DLL and saving it to a specific folder which is available
for writing on the machine on which his exe is running and he is then
using LoadLibrary so his code can use it from the location to which his
exe saved it. This enabled him to still send just a single exe file to
his customers. At least that's what I think he is doing . . . and I'm
sure you'll have a few things to say to him about that ;-)

Not really (anymore)...
I was aware what he apparently did, to keep up with this
"self-enforced rule"... but Thorsten already commented about
the technique of "magically appearing Dlls, popping up
out of nowhere in some folder".

This is non-transparent behaviour from a Users point of view -
and also prone to trigger AntiVirus-Software ... all in all
not really recommendable.

Olaf

[Ivar]

Hi Mike, Glad to see you still visit this NG.
I still remember how much your waffling on about GDI helped me and many
others all those many years ago.

I suppose a better interpretation of my rule is that a single exe file
should be able to run on windows just by running the exe file.
You are spot on about what I'm actually doing, except one bit.
The DLL (by Jean-loup Gailly) is in the resource file as a compressed Custom
file, When the exe requires it the exe will de compress with the exe's own
de compress routine and write the de compressed bytes to the AppData
Directory. So In theory, the dll does not exists as a dll file until it's
put on the hard drive.
I don't use any anti virus at all, I have not distributed the new exe file
as yet, will anti virus throw wobblies?
Not having the slightest clue on what AV software actually does (except for
how annoying it is), can they pick up what can be a dodgy file being written
to the hard drive.
I don't want to be in the situation of people having their PCs throwing up
worrying Msgs when running this software.


Olaf Said:
Ok, he at least broke the "I always need to make my own wheel"-part
of the rule (by inexplicably using an established, well-tested and
fast *.dll, labeled with the attribute: "not invented here")... ;-)

Yes I tried The Roll my own Compression and it's been working for Years but
was becoming so sloooooow People were becoming bored :-)
It now takes less seconds that it did minutes.

[Mayayana]

| One of my rules on software development is to have no external references
| except what's in winders. No ActiveX, No Dlls.

I can appreciate that, but I also agree with Deanna
and Garry. The whole point of an installer is convenience.
Even more so for non-tech. people. Most people are
not capable of downloading your file, putting it somewhere
safe, then putting a shortcut on their Start Menu.

I once read an article about a software company that
couldn't figure out why so many downloads were not
translating to sales. It turned out that 2/3 of the people
downloading couldn't find the file after they'd downloaded
it. :)
Though I think that problem is actually caused, in
large part, by treating people as stupid. Browsers have a
set location for download. A lot of software has a set
location for saving files. Typically that location is either
the user Documents folder or the program folder, neither
of which is known to the the person using the PC. And
since XP it's nearly impossible for an average person to
even find their Documents folder. If programs defaulted
to asking where the file should be saved then people
would know where they'd put it.

I don't know if this will help at all, but I have straight VB
code for creating CABs and extracting from them. That could
allow you to add CAB compression without an extra library.
And speed shouldn't be an issue, since cabinet.dll does most
of the work.

http://www.jsware.net/jsware/vbcode.php5#cab1

See download #2. I use it in an MSI unpacker program
that gets a lot of downloads. It's been very dependable
and runs on all Windows systems, requiring only cabinet.dll,
which is a system file.

[Ivar]

Hi Mayayana

Thank you for you reply.
Looking at that web page makes me thing Dam, I wish I'd seen that last
month.
I had a little play, I may do some serious testing if all is not well with
the current set up

Ivar

[ralph]

On Tue, 13 Nov 2012 11:43:43 -0000, "Ivar"
<***@ntlworld.com> wrote:

Another major feature, though oddly seldom mentioned, of providing an
"Installer" for even the most most trivial application is the ability
to also "Uninstall" cleanly.

-ralph

[DaveO]

Post by ralph
On Tue, 13 Nov 2012 11:43:43 -0000, "Ivar"
Another major feature, though oddly seldom mentioned, of providing an
"Installer" for even the most most trivial application is the ability
to also "Uninstall" cleanly.
-ralph

"But. But. Now you are just being silly, my applications are all perfect,
nobody would ever want to uninstall them"*

*Anon, but many developers seem to think like that.

DaveO

[CoderX]

Ugh. I've known a few of them. Hateful people.

Post by DaveO
"But. But. Now you are just being silly, my applications are all perfect,
nobody would ever want to uninstall them"*
*Anon, but many developers seem to think like that.

[Deanna Earley]

Post by Ivar
Hi Garry
Did you miss the bit that says "P.S. I only ever distribute the exe
file, The App never needs installing."
I don't want (because half of them cant) end users to install, far to
complex a thing to do.

Sorry, I fail to see how

Post by Ivar
run, next, install, finish
copy this file to this location, you will get various overwrite
prompts. Oh, and make sure you agree to the UAC prompt, and make sure
that it hasn't gone into the compatibility files folder, then turn
off the flag that says the file is unsafe as you just downloaded it
from the internet or email