Installers - why

[mm_FX]

I can fully appreciate what people are saying, but you'd really be surprised how many musicians cannot understand an operating system file-system. I know for the vast majority of people here it's trivial, but if you didn't have the OS knowledge you'd be lost without an installer.

[Sascha Franck]

Great. Now think outside the box of your spesific needs. You always rave about the multiple machine you have to setup and test. It doesnt concern 99% of the users here.

Yeah well - it might be my specific needs that I described, true. Still, there's quite some advances for almost everybody with "copy only" installations.
Sure, there's people who don't even know how to find their vstplugins directory - but that can be described in one line of documentation.
Add another line to describe how supplementory files (sample directories, whatever) have to be set up and everybody should be able to deal with it.

I've seen it more than once on machines I was called to service that files were all over the freaking place. Samples residing on your Windows partition (even if there have been multiple partitions) and so on. All that caused by people clicking "OK" on everything the installer brought up.
Having said that, usually all installers default to some directory on your C: drive, regardless whether it's samples or whatever.
Now, install some sample based things coming with large libraries on your C: drive and you'll most likely be running into problems very soon, be it because of lack of space or because of less than stellar performance.
Yes, this could be avoided by using proper installing routines, but it's not happening. There's no "Attention, sample content to be copied, if you can, please select a drive others than your system one", installers allways seem to default to C:.
Now, consider that's what all the pro-installer folks seem to be on about: No fuzz for less experienced users - then you should also consider that almost all of those will just click "OK" without changing directories. So their sample libraries (or whatever) will actually end up on C:, pretty much not the ideal place for them on systems with multiple drives and/or partitions.

A very fine example of how such things can be handled without installers is FXpansions DR-008. When you call it up for the first time it'll ask you for your serial and the place where you have the modules, presets and samples stored. After that it'll allways default to those directories.

As said before, another fine example is Energy XT. You can just define each and every directory yourself, regardless whether you're using it in standalone or VST mode. No installation required either, you just copy the directory to your system, start eXT and point it to the keyfile to have it registered. Perfect.

[mm_FX]

Sascha - we still get quite a few people who can't deal with that method. We use installers for everything now. Otherwise there's just too many possible unknowns when doing support. The funny thing is that installers aren't 100% either - Apple for example has an uncanny knack of breaking scripts with different OSX versions. Still, it's a better system for a commercial developer.

[core]

Installers are just fine. People who don't really know what's going on in the background are (more likely) able to get the software installed properly.
You just don't want certain users having to mess about with copying software to the right location. Self-extracting files would work for software that doesn't need regkeys or user preferences to be set at installation, otherwise I prefer installers.

And for users who do know what's going on, if you dislike having the installer on your system, just use the installer, make a copy of the installed files manually, then uninstall and you have your 'files only installation'.
Good way to check if you really DO know what's going on at installation ;-)

[Cryogenic]

As said before, another fine example is Energy XT. You can just define each and every directory yourself, regardless whether you're using it in standalone or VST mode. No installation required either, you just copy the directory to your system, start eXT and point it to the keyfile to have it registered. Perfect.

Yeah, then eXT 'installs' the ini-file in your Windows directory, without telling you.

[Sascha Franck]

Yeah, then eXT 'installs' the ini-file in your Windows directory, without telling you.

True. But even if I plan to just delete eXT one day, the left over ini-file won't do much harm to my system (if at all).

[Big Tick]

also: to all whom believe the registry isnt flat, please explain the magic involved here where it isnt possible to do exactly the same thing yourself?

ah i see, it isnt possible because YOU do not know how. time to learn.

Now ponder this: what would happen if every plugin did implement its own code for this ?
Answer: lots of wasted ram for code that implements something already handled by the OS.

Also, here's another story: I can't recount how many times (definitely several times a month) I receive emails asking for support regarding some of my older plugins (the ones without installers). Basically the emails say: "hello, I've opened the zip file but I can't see any dll file, can you help me ?". Although this is a well-known issue (the user system is configured to hide system files) and although this is covered in the FAQ (that most users won't ever bother reading), I still need to spend some time to handle this sort of request. A simple .exe installer solves this issue nicely, don't you think so ?

So my final view on this, for whatever it's worth: if you ever come across a vsti whose installer installs crap on your system, tell about it in the forums. Email the developer and tell him his installer sucks. As a user, do whatever you can to make sure the developper improves his install system. But keep in mind there are plugins out there, whose installers are clean of any spyware, won't leave anything around when uninstalling, won't create any icons or shortcuts... Given everything I've read above, I can't see any objective reason why you would dislike these ones too.

'Tick

[aciddose]

Now ponder this: what would happen if every plugin did implement its own code for this ?
Answer: lots of wasted ram for code that implements something already handled by the OS.

what, you mean 2k? wow you really are a bad coder :)

a good implementation should take very little processing, almost no memory or even no memory at all, be extremely simple, possibly a binary format, and the code size should be no greater than 2k in the greatest scoped implementations. you should examine the memory use of all your other structures before making such comments, please.

if microsoft cared at all about waste, they would have made code simmilar to mine or any other good quality code for such perposes that is portable and could be implemented in a quality library on many platforms. instead they built a poorly documented and faulty database into thier os. just looking at simple things like the windows registry makes me begin to question if any design was done by microsoft programmers at all. it apears they only wanted a quick fix and then only later realized that the good and simple solution would have worked from the beginning, while they are still trying to fix problems with thier database system today.

the windows registry is included for one perpose and by one perpose: lazy programmers. i suppose you wont be bothering to port your code to another platform? a shame.

i repeat, i did not question the usefulness of installers when helping idiots and other average user classes to get things working.

added:

if you're looking for quick and dirty, why dont you try this.

struct myconfig_header
{
long version;
long size;

//data here
char data[];
};

struct myconfig_1
{
myconfig_header head;

//data here
char scale1;
short something;
long another;
float whatever;
};

//scope
{
myconfig_1 config;
{} //members filled

{ //write
FILE *o = fopen(exepath + string("\myconfig.ini", "wb")
fwrite(&config, config.head.size, 1, o);
fclose(o);
}


{ //read
FILE *o = fopen(exepath + string("\myconfig.ini", "rb")
long size = fsize(o); //fseek, ftell, fseek macro
char *data = new char[size];
myconfig_header *c = (myconfig_header *)data;
fread(c, size, 1, o);
fclose(o);
switch (c->version)
{
case whatever:
realloc and rearange thus;
break;
}
memcpy(&config, c, sizeof(myconfig_currentversion));
}
}

welcome to the world of actual programming!

[DuX]

Me like , aciddose. I often wondered why developers don't use simple *.ini files for their settings? It would save me and other advanced users much time opening and editing that ini file with notepad instead of digging through the bloody registry... those who don't know what an ini file is wouldn't do it either way anyway , so only we "actual users" feel bad about it.

Cheers!

[aciddose]

well if someone used the 'quick and dirty' implementation using c structs that i just posted, you'd be going through hell even with a hex editor like hexworkshop to edit those, i doubt many people would be able. but a simmilar quality implementation using crc32 pointers and names (background=whatever.bmp) would work just as easy.

infact there is already an implementation built into the ms libraries for this:

void WRITECONFIG(char *section, char *key, char *cfgfile, char *data)
{
WritePrivateProfileString(section, key, data, cfgfile);
}

char *READCFG(char *section, char *key, char *cfgfile)
{
static char data[256];
if (GetPrivateProfileString(section, key, "", data, 256, cfgfile))
{
return data;
}
return 0;
}

very easy to deal with as well, and its easy to code your own portable implementation that works just the same (or you can get public source online)

[mojogigolo]

i prefer simple zipped dll files, but we shouldnt forget that not everyone who uses a vst is gonna be a pointy headed trenchcoat wearing kvr-style pedant, so devs probably need installers available.

[Big Tick]

FILE *o = fopen(exepath + string("\myconfig.ini", "wb")

Yes. Lovely. And how about exepath ? We want the path of the dll, not the path of the host.

i suppose you wont be bothering to port your code to another platform? a shame.

Indeed. I write highly non-portable code. Shame on me. Here is a sample, I would really welcome suggestions from a real programmer on how to port that to, say, a Mac. Will you enlighten me ?

Code: Select all

        movaps xmm3, _xmm_one
        movaps xmm4, xmm1 // _envdelta
        movaps xmm2, xmm3
        subps xmm2, xmm0; // 1-_sdata->_envvalue[i]
        cmpltps xmm3, xmm0 // (1<_envvalue) ?
        andps xmm4, xmm3 // envdelta or 0
        andps xmm2, xmm3 // 1-envvalue or 0
        movaps xmm3, _xmm_zero
        addps xmm0, xmm2
        movaps xmm2, _xmm_one_bool
        xorps xmm1, xmm4
        cmpleps xmm3, xmm0; // zero <= xmm0 , same as xmm0 > 0
        andps xmm0, xmm3
        andps xmm1, xmm3
        andps xmm2, xmm3
        ... (goes on and on, 82 Kb of it  actually)

'Tick

[kp]

I don't want portable code, I want platform optimal code.

[arguru]

Yes. Lovely. And how about exepath ? We want the path of the dll, not the path of the host.

Easy as just 1 win32 call.

Code: Select all

// dll buffer
char dll_path[_MAX_PATH];

// get library directory
GetModuleFileName(gl_hinstance,dll_path,_MAX_PATH);

[aciddose]

of course, no need to mention how to make that portable by writing classes for different platforms which use the same abstract interfaces or anything silly and clearly unoptimial or 'useless'.

you still use asm for full code? wow. actually my compiler generates faster code, and i can port my code to any other platform and it's compiler will generate optimized code for that platform. certain things need to be hand coded in extremely tight places, but..

good luck when you want to recode everything due to a minor architecture change!