Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.basic.visual.misc > #1613 > unrolled thread

Where To Write My File

Back to article view | Back to comp.lang.basic.visual.misc

Contents

  Where To Write My File "Ivar" <ivar.ekstromer000@ntlworld.com> - 2012-11-04 21:21 +0000
    Re: Where To Write My File Jim Mack <no-uce-ube@mdxi.com> - 2012-11-04 16:51 -0500
    Re: Where To Write My File "DaveO" <djo@dial.pipex.com> - 2012-11-05 09:54 +0000
    Re: Where To Write My File Deanna Earley <dee.earley@icode.co.uk> - 2012-11-05 10:12 +0000
    Re: Where To Write My File "Ivar" <ivar.ekstromer000@ntlworld.com> - 2012-11-05 11:35 +0000
      Re: Where To Write My File "DaveO" <djo@dial.pipex.com> - 2012-11-05 11:59 +0000
        Re: Where To Write My File "Ivar" <ivar.ekstromer000@ntlworld.com> - 2012-11-05 12:17 +0000
          Re: Where To Write My File Deanna Earley <dee.earley@icode.co.uk> - 2012-11-05 13:43 +0000
    Re: Where To Write My File GS <gs@somewhere.net> - 2012-11-12 10:00 -0500
      Re: Where To Write My File "Ivar" <ivar.ekstromer000@ntlworld.com> - 2012-11-12 19:10 +0000
        Re: Where To Write My File GS <gs@somewhere.net> - 2012-11-12 17:08 -0500
        Re: Where To Write My File "Thorsten Albers" <gudea@gmx.de> - 2012-11-12 23:29 +0000
          Re: Where To Write My File "Ivar" <ivar.ekstromer000@ntlworld.com> - 2012-11-13 11:43 +0000
            Re: Where To Write My File Schmidt <sss@online.de> - 2012-11-13 14:43 +0100
              Re: Where To Write My File "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-11-13 17:07 +0000
                Re: Where To Write My File Schmidt <sss@online.de> - 2012-11-13 19:00 +0100
                Re: Where To Write My File "Ivar" <ivar.ekstromer000@ntlworld.com> - 2012-11-13 19:10 +0000
            Re: Where To Write My File "Mayayana" <mayayana@invalid.nospam> - 2012-11-13 09:08 -0500
              Re: Where To Write My File "Ivar" <ivar.ekstromer000@ntlworld.com> - 2012-11-13 19:16 +0000
            Re: Where To Write My File ralph <nt_consulting64@yahoo.com> - 2012-11-13 09:18 -0600
              Re: Where To Write My File "DaveO" <djo@dial.pipex.com> - 2012-11-13 16:41 +0000
                Re: Where To Write My File "CoderX" <coder@x.com> - 2012-11-15 13:38 -0500
        Re: Where To Write My File Deanna Earley <dee.earley@icode.co.uk> - 2012-11-13 10:19 +0000

Page 1 of 2  [1] 2  Next page →

#1613 — Where To Write My File

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'

[toc] | [next] | [standalone]

#1614

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

-- 
        Jim

[toc] | [prev] | [next] | [standalone]

#1615

"Ivar" <ivar.ekstromer000@ntlworld.com> wrote in message 
news:e%Als.206617$9W6.163405@fx08.am4...
> 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. 

[toc] | [prev] | [next] | [standalone]

#1616

On 04/11/2012 21:21, Ivar wrote:
> 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.

> 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 :)

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

-- 
Deanna Earley (dee.earley@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the 
group.)

[toc] | [prev] | [next] | [standalone]

#1617

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 

[toc] | [prev] | [next] | [standalone]

#1618

"Ivar" <ivar.ekstromer000@ntlworld.com> wrote in message 
news:wwNls.264609$Rc7.75012@fx04.am4...
> 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

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 

[toc] | [prev] | [next] | [standalone]

#1619

>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

[toc] | [prev] | [next] | [standalone]

#1620

On 05/11/2012 12:17, Ivar wrote:
>> 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?

Here's a link to the post on my local server:
news://news.aioe.org:119/k783ev$n0i$1@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.

-- 
Deanna Earley (dee.earley@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the 
group.)

[toc] | [prev] | [next] | [standalone]

#1621

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

-- 
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
  comp.lang.basic.visual.misc
  microsoft.public.vb.general.discussion

[toc] | [prev] | [next] | [standalone]

#1622

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$1@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

-- 
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
  comp.lang.basic.visual.misc
  microsoft.public.vb.general.discussion

[toc] | [prev] | [next] | [standalone]

#1623

Ivar brought next idea :
> 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...

-- 
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
  comp.lang.basic.visual.misc
  microsoft.public.vb.general.discussion

[toc] | [prev] | [next] | [standalone]

#1624

Ivar <ivar.ekstromer000@ntlworld.com> schrieb im Beitrag
<xQbos.1$kt5.0@fx08.am4>...
> 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...

-- 
Thorsten Albers

gudea  at  gmx.de

[toc] | [prev] | [next] | [standalone]

#1626

>"Thorsten Albers"  wrote in message 
>news:01cdc12d$87bcaa30$7a02a8c0@k8s8x...
>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!]

[toc] | [prev] | [next] | [standalone]

#1627

Am 13.11.2012 12:43, schrieb Ivar:
>
>
>> "Thorsten Albers"  wrote in message
>> news:01cdc12d$87bcaa30$7a02a8c0@k8s8x...
>> 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).

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


> 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

[toc] | [prev] | [next] | [standalone]

#1631

"Schmidt" <sss@online.de> wrote in message 
news:k7tiqj$m11$1@speranza.aioe.org...
>>
>> [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

[toc] | [prev] | [next] | [standalone]

#1632

Am 13.11.2012 18:07, schrieb Mike Williams:
> "Schmidt" <sss@online.de> wrote in message
> news:k7tiqj$m11$1@speranza.aioe.org...
>>>
>>> [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>

> 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

[toc] | [prev] | [next] | [standalone]

#1633

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.

[toc] | [prev] | [next] | [standalone]

#1628

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

[toc] | [prev] | [next] | [standalone]

#1634

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

[toc] | [prev] | [next] | [standalone]

#1629

On Tue, 13 Nov 2012 11:43:43 -0000, "Ivar"
<ivar.ekstromer000@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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.basic.visual.misc

csiph-web