Distributing lua51.dll and lua5.1.dll

[T3STY]

1) For those who don't know, if a DLL function has bugs, they can coorect those in the DLL source code and then update only one file, instead of rebuilding the entire application like it should be done with static libraries. This also can be a really GOOD motivation for leaving DLLs out of the exe.
2) OK, the user might want to explore the directory. So ? How could some DLLs (two precisely, i mean TWO) make the application ugly/unclean ?
3) Why does the user have to browse inside ?? Applications built in AMS are not meant for the user to go and findout whatever the application folder has inside; applications are meant to be applications! So the user might click the exe directly or a shortcut, and done.

[Centauri Soldier]

Since when are dll files viewed as "ugly" or clutter? Some people forget the prime maxim of building or designing anything..."Form follows function". Given this, the form of the dlls in the root directory should be of no concern provided that the application functions properly. And like Dermot pointed out, any dev that produces an app for public release can include shortcuts with it quite simply.

[Cybergraph]

But on a setup CD you cannot avoid this. User will see the root, and will also see a "dirty" root.
So it would be very nice, if the DLLs can be shifted to a subfolder like "Autoplay", where the appearance does not disturb.

This can be avoid in two ways:

1- In the root folder of the CD, you can create a folder called for example "Data", and autorun.inf file containing the instruction "open=..\Data\myprogram.exe where "myprogram.exe" could be the install program or a browser for the content of the CD, a presentation or anything else.
In this way, in the root folder the user will see only the "Data" folder and the Autorun.inf file.

2- To achieve more complex functions and possibilities, you could create an AutoIt script and place it in the root. The script can call anything you want in a subfolder (or you can have more AutoIt scripts that user can choose from, accordingly with their names), compile it as a .exe and place it in the root of the CD.
AutoIT compiled scripts don't need external DLL or other files.

[mystica]

@AutoPlayUser,

Well, why not just do what you 'should' be doing in the first place ... that is to say:

Compile your project as per standard HDD compile (ie. with dlls showing and all). Then package the whole project into a standard installer setup-package with Setup Factory (or equivalent). Leaves with you a single executable that can be distributed over the web, and when user opens, it creates a standard desktop-shortcut and program-files folder just like any other Windows program.

At the end of the day, it's no different to how any professional development is compiled and deployed.

[RizlaUK]

Don't get me wrong: I don't care if external files are being loaded at run time,
but is there a reason why they should appear in the root, next to autorun.exe and autorun.inf?

yes, there is a very good reason, one thats been explained several times in this very thread!!

[Iskander]

This is not the idea behind an autorun setup disk.
And a single packed exe is not a solution as well, since users have to browse for different contents on the disk.

One option would be placing any external files into a separate location on the disk and making this location browsable by the autorun application. There are ways out, really!

[AutoPlayUser]

create a shortcut...

This is not the idea behind an autorun setup disk.
And a single packed exe is not a solution as well, since users have to browse for different contents on the disk.

[Iskander]

I understand. Well, then just compile as a single packed executable... Alternatively, unless run directly from a laser disk, it is always possible, isn't it, to create a shortcut (manually or using an installation tool like Setup Factory).

[AutoPlayUser]

Don't get me wrong: I don't care if external files are being loaded at run time,
but is there a reason why they should appear in the root, next to autorun.exe and autorun.inf?

Again:
Acrobat users will rarely browse to the installation directory and look for that executable in all
those files listed there. They use a short cut on the Desktop or where else. And in most cases
they just double click the PDF. So there is no reason to browse to the installation directory.
They will never see all those files!

But on a setup CD you cannot avoid this. User will see the root, and will also see a "dirty" root.
So it would be very nice, if the DLLs can be shifted to a subfolder like "Autoplay", where the appearance does not disturb.

[Iskander]

IMHO not only Acrobat, but loads of other applications are installed with DLLs in the executable directory. They all stem from the idea that the user -- however dumb they might be -- will launch the application by opening the EXE file and not tampering with the libraries. I've seen really far more setups WITH dlls in the root dir than those without. I conjecture that developers have some strong reasons for that. From what I know, a statically linked LIB will not allow the application to start if it raises an error, i.e. if it cannot be linked by the linker. Inversely, a DLL, even if failing to link, doesn't bar the exe from starting. I guess, this may have been one of the reasons behind that.

[Dermot]

That's not an argument, that's a bad excuse.

It's not a bad excuse, it is the facts

If you had version 7.x of AutoPlay you should know, that you hadn't had any of those files.

I have been using AMS since version 3 and have seen lots of changes. Version 8 is by far the best version yet and if that means having 2 dll files visible, then I have no problem with that.

I don't understand why this concept was changed.

It was changed so that plugins could use the same instance of Lua as the main app.

BTW: Your comparisons doesn't really fit to this issue.

While you will never get in touch with the folder structure of your Adobe installation (or any other exe)
and actually see all those DLLs and additional files, users of the AutoPlay setup will do. They do not
use any desktop or Start menu shortcuts.

It fits perfectly. All my apps use shortcuts, just like any other app.

They insert their disk, the Explorer opens, they see autorun.exe .... and those ugly DLLs which haven't been there
before. It is a matter of a tidy root.

The advantages of version 8 far far out way an "untidy root". If you can't see that then you have no appreciation for what you can do with version 8.

and come on now, they're not ugly, they are quite cute

[AutoPlayUser]

No you can't get rid of them. What is disturbing about it? Pretty much every program you install uses dll files that are visible in the programs folder. If you build to a web exe then the user won't see them.

That's not an argument, that's a bad excuse.
If you had version 7.x of AutoPlay you should know, that you hadn't had any of those files.
I don't understand why this concept has been changed.

BTW: Your comparisons don't really fit to this issue.

While you will never get in touch with the folder structure of your Adobe installation (or any other exe)
and actually see all those DLLs and additional files, users of the AutoPlay setup will do. They do not
use any desktop or Start menu shortcuts.

They insert their disk, the Explorer opens, they see autorun.exe .... and those ugly DLLs which haven't been there
before. It is a matter of a tidy root.


In V7.x it was.... now, in 8.x it is not.



A better solution would be having these DLLs somewhere in the Autoplay subfolder (where user do not go), not directly in the root.

[T3STY]

amazing.. oh, and there are aso folders with much DLLs in each!!!

[mystica]

lol, when i first discovered PureBasic and how to compile a dll, i used to make my apps have some external files just to make it look like that ...

Funny you should say that. A few of my projects have 'dummy dlls' that i made with your old Bloat File Maker (not real dlls of course, just files filled with whitespace and named with .dll extensions) for the same reason. Kinda makes the whole thing look more 'professional' and 'complex'. Hahaha. The things we do for our egos, yeh?

Adobe Acrobat Pro v9.0 ... look at all those dlls, eh?

[RizlaUK]

lol, when i first discovered PureBasic and how to compile a dll, i used to make my apps have some external files just to make it look like that

when you see an app that does use dll's, it shows the developer has some skillsets to actually use then in the first place, lol