Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Where To Write My File
18 views
Skip to first unread message
Ivar
Nov 4, 2012, 4:21:13 PM11/4/12
to
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'
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
Nov 4, 2012, 4:51:09 PM11/4/12
to
> 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.
> 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.
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
DaveO
Nov 5, 2012, 4:54:47 AM11/5/12
to
"Ivar" <ivar.eks...@ntlworld.com> wrote in message
news:e%Als.206617$9W6.1...@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
>
> 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.
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
Nov 5, 2012, 5:12:49 AM11/5/12
to
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
> 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
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.
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.
"Run this, click "Next" then "Install".
--
Deanna Earley (dee.e...@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.)
Ivar
Nov 5, 2012, 6:35:56 AM11/5/12
to
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
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
Nov 5, 2012, 6:59:57 AM11/5/12
to
news:wwNls.264609$Rc7....@fx04.am4...
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
> 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
>
> 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
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
Nov 5, 2012, 7:17:43 AM11/5/12
to
>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:
>
>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?
Ivar
Deanna Earley
Nov 5, 2012, 8:43:25 AM11/5/12
to
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.
GS
Nov 12, 2012, 10:00:55 AM11/12/12
to
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
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
Ivar
Nov 12, 2012, 2:10:20 PM11/12/12
to
Hi Garry
Did you miss the bit that says "P.S. I only ever distribute the exe file,
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...
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...
GS
Nov 12, 2012, 5:08:42 PM11/12/12
to
Ivar brought next idea :
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...
> 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
> App never needs installing."
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
Thorsten Albers
Nov 12, 2012, 6:29:10 PM11/12/12
to
Ivar <ivar.eks...@ntlworld.com> schrieb im Beitrag
<xQbos.1$kt...@fx08.am4>...
let it never make itself comfortable on any of my hard disks or hard disks
of my friends...
--
Thorsten Albers
gudea at gmx.de
<xQbos.1$kt...@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
> working fine.
let it never make itself comfortable on any of my hard disks or hard disks
of my friends...
--
Thorsten Albers
gudea at gmx.de
Deanna Earley
Nov 13, 2012, 5:19:56 AM11/13/12
to
On 12/11/2012 19:10, Ivar wrote:
> 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
> 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.
> run, next, install, finish
is "far too complex" compared to:
> 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
Ivar
Nov 13, 2012, 6:43:43 AM11/13/12
to
>"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
>let it never make itself comfortable on any of my hard disks or hard disks
>of my friends...
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
Nov 13, 2012, 8:43:45 AM11/13/12
to
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).
>
>
>> "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 :-(
> One of my rules on software development is to have no external
> references except what's in winders.No ActiveX, No Dlls.
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.
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
Mayayana
Nov 13, 2012, 9:08:58 AM11/13/12
to
| 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
| except what's in winders. No ActiveX, No Dlls.
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.
ralph
Nov 13, 2012, 10:18:14 AM11/13/12
to
On Tue, 13 Nov 2012 11:43:43 -0000, "Ivar"
<ivar.eks...@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
<ivar.eks...@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
Nov 13, 2012, 11:41:28 AM11/13/12
to
"ralph" <nt_cons...@yahoo.com> wrote in message
news:jeo4a8dpsm4dk9eua...@4ax.com...
nobody would ever want to uninstall them"*
*Anon, but many developers seem to think like that.
DaveO
Mike Williams
Nov 13, 2012, 12:07:10 PM11/13/12
to
"Schmidt" <s...@online.de> wrote in message
news:k7tiqj$m11$1...@speranza.aioe.org...
>>
>> [Ivar said] One of my rules on software development is to
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
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
>> the wheel to achieve this, ...
>
> 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
Nov 13, 2012, 1:00:26 PM11/13/12
to
Am 13.11.2012 18:07, schrieb Mike Williams:
> "Schmidt" <s...@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
> "Schmidt" <s...@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.
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 ;-)
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
Nov 13, 2012, 2:10:27 PM11/13/12
to
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.
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")... ;-)
was becoming so sloooooow People were becoming bored :-)
It now takes less seconds that it did minutes.
Ivar
Nov 13, 2012, 2:16:01 PM11/13/12
to
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
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
CoderX
Nov 15, 2012, 1:38:20 PM11/15/12
to
Ugh. I've known a few of them. Hateful people.
"DaveO" <d...@dial.pipex.com> wrote in message
news:k7tt7o$co1$1...@dont-email.me...
"DaveO" <d...@dial.pipex.com> wrote in message
news:k7tt7o$co1$1...@dont-email.me...
0 new messages