4th of March – Software distribution/Release Candidate of Vide

I have always, ALWAYS hated dynamic link libraries, dylibs, shared objects and any related entities.

There might have been a time where such things might have been sensible – to save some precious memory on your hard disk.

But even at the time when it MIGHT have been smart – I still always found them to be a major nuisance! Even more today.

In my opinion a program should be in as many relations as possible self sufficient (hardware drivers are an exception). One program should be placed in one directory and if I don’t want the program anymore – I delete that directory and thats it. No need for an installer or an uninstaller. One directory – that is it.

I do not want special settings in my home folder. I do not want a “document” folder. And I absolut certainly do not want “/user/home/Library/Preference” etc folder. And what the heck is “/AppData/Roaming/…” anyway? (or “…/Local/ … or “…/LocalLow/…”???)

If there is ONE application directory I always have the right version of all things I need, I don’t have to bother whether some obscure shared object in some even more obscure UNIX path has a version difference, or a link is not correctly set (UNIX/Linux is even more terrible since there are so many different directory schemes. Do I look in /opt/? in /shared/? in /home/lib? in what the heck? GO AWAY!).

I don’t want to use an obscure install manager, be it “app-get” or “brew”, or “ports” or whatever they are called. I wish to download a ZIP (or similar), unpack in a folder and RUN it. That way I KNOW what I downloaded, where it went and how to get rid of it.

Is that so much to ask for?

They invent containers, “dockers”, virtual machines but “they” are freaking not able to get rid of those damn shared things which after a couple of installed weeks/months/years are bound to cause trouble?

Than there are the hyper smart “dll” which don’t even CARE to be downwards compatible. Yes wow – now I have DLLs but I also must have all previous versions otherwise program xy does not run!
(mfcXXX.dll come to mind quickly here)

ARRRG!

Sorry for rambling.

Its just that always made me mad and right now even more so.

Since Java 10 or now 11 is not as downward compatible as IMHO Java should be.

I decided to change the Vide distribution. I will go BACK to Java 1.8. I reversed the changes I did for the new Java version – and will stay at Java 1.8 till it will not run on your machine anymore – and than there will be no more Vide.

In order to not get YOU my dear Vide users in all to much trouble I am going to use a Java feature called “native packaging”. This goes totally against the Java policy to be “the same on all supported platforms” – since the distribution is as the name suggests NATIVE to each operating system.

But the positive thing is – that the native packaging distributes the correct Java version WITH the application. That way I do not CARE what Java version you might have installed on your computer, Vide always uses its own version – which I provide.

And you know what – you will get Vide in ONE DIRECTORY, which will be totally self sufficient (apart from hardware drivers).

Right now I am building native packages for:

• Mac OSX (done)
• Windows 64 (done)
• Windows 32 (done – Windows XP compatible!)
• Debian Linux 64bit (done)
• Ubunto Linux 64bit (done)
• Ubunto Linux 32bit (done)

And will also do a non native packaging. If you have your own Java 1.8 installed or dare run it at your own risk with a newer Java – you can do so.

Due to the way Java native packaging works the directory structure is slightly changed. The “java executive” will always be kept in a subdirectory “Vide.app” (yes my main dev Environment is Mac 🙂 ). Due to the way Java works the working directory of an application can not be changed during runtime (I mentioned that somewhere before).

I implemented two mechanisms that might ensure that Vide behaves the same as before:

1. You can set a “VIDE_HOME” environment variable to point to your Vide directory.
2. Or if no “VIDE_HOME” was found, Vide searches the current directory structure for its “home”, going “up” all the way to “/”

I define the Vide home directory as the directory where all the Vide subdirectories reside (“log”, “system”, “template”, “serialize”, etc). Vide needs those directories at a known position to work.

You probably need not be concerned – I just thought to mention it.

Comand line parameters

I have not given thought to them. I have not tested the CLI yet – so don’t expect it to work!

Starting Vide

Each archive unpacks in a single directory called Vide2.11.xxx (xxx name of the operating system). In that directory all former subdirectories are listed and ONE executable:

• OSX: an application “Vide.app”
• Windows: a batch file “Vide.bat”
• Linux: a shell script “Vide.sh”

These files start Vide on your operating system respectively.

Not done yet

Not done any new documentation. Since a it is a Release Candidate mainly for testing out the native deployment thing. The other “new” or fixed stuff is also not properly documented. You may try them out – but they are as such not fully “supported” yet.

Release Candidate downloads

Not available. A new vide “full” version is available (or will be shortly).

1300MB?

Why that big?
Each of the above archives is a full Vide distribution with ONE native Java installment. With that I mean all other OS specific executables are as of now completely kept within the archive (every archive above has e.g. C-compiler binaries for all platforms…) This might change in the future.

Current memory distribution (roughly):

• 320MB Vide + java native
• 100MB C-Compiler stuff
• 120MB Vectrex “roms” + documentation/images (used for the starter)
• 70MB Codelib – various Vectrex sources as examples
• 200MB documentation (“library”) of various stuff (hardware/BIOS/assembler…)
• 22MB external tools (autotrace/potrace/…)
• 70MB Vide help (many images)
• 135MB external libraries in “lib” directory (this is only needed if you want to compile the sources yourself)
• 10MB overlays
• 160MB example projects in the projects folder
• 10MB samples for speech synthesis
• 25MB source code of Vide
• 20MB xml files (various data, and vectorlist/animations)
• … and some additional small stuff