Vintage Application Repository

[Broadwell]

Vintage Application Repository

What is this?

The VAR tool helps Windows 9x and Windows 2000 computers to get software easier. When the client has been installed, installation of another software is as easy as navigating to the executable, executing the following in a DOS prompt, and dealing with the installer published by the software vendor.

varm install Firefox

Just like apt-get.

I have just recently started the development of this tool, therefore bugs are everywhere. The code is hosted at GitHub: Repository of the repository

For slightly more information, please visit the GitHub repository. It contains a README.md file.

 

Please submit an Issue on the GitHub repository if you encounter any bugs or wish to suggest future features to VAR.

Edited May 15, 2016 by Broadwell

[pionner]

I just want to ask: In readme.md you say it's because of HTML5 browsers etc. that searching for apps is pain in the... and I agree (although Retrozilla makes this much better experience than some old Firefox or God forbid IE). So why not just create IE4 friendly website with download?

[Broadwell]

1 hour ago, pionner said:

I just want to ask: In readme.md you say it's because of HTML5 browsers etc. that searching for apps is pain in the... and I agree (although Retrozilla makes this much better experience than some old Firefox or God forbid IE). So why not just create IE4 friendly website with download?

There are three reasons why I started this project with a CLI (Command Line Interface):

• Flexibility of user interface: Using a front-end to back-end setup, I can use PHP and Ajax to have the user interact with a webpage, or use a GUI library in tandem with a socket library to have the user interact with system-native GUI.
• Compatibility with MS-DOS: I may enable support for MS-DOS on this project in the future.
• Scripting-compatible: VARM can be used in a script (batch for Windows) just like any other command, because it can be non-interactive.

Edited May 20, 2016 by Broadwell
Fix reasons

[jaclaz]

If I may,  I don't think that the question was about the reason why CLI was chosen over GUI, but rather about what was the reason/need to create a (seemingly very complex) Server/Client setup.

I just quickly checked the github repository, but it seems to me like you are making an "engine" for a "database" of some kind, but it is not clear (at least to me) where the contents of the "database" will (hopefully) come from, who will maintain them, etc., and (still IMHO) it is not like "Just like apt-get" sounds like a "feature" to be pursued or "ideal" tool that one would want/need to emulate.

I mean, isn't there the risk of falling in the classical xkcd standards trap? :
https://xkcd.com/927/

jaclaz

Edited May 20, 2016 by jaclaz

[Broadwell]

The database for now is located at My web server, and it is integrated into the configuration setup routine for the client. (look for http://broaderator.com/var in the python file and you will find out)

In addition, this set of routines is not necessarily limited to a server/client setup. A #todo scenario (in the future) would be a distributable CD with a repository directory containing exe binaries. The user can use varm.exe to interact with the CD contents. This is also going to be my intended scenario for MS-DOS users.

When I used "Just like apt-get", I didn't mean it as a feature to be pursued or emulated. It was just part of the explanation about how this application works.

[jaclaz]

Good , still it seems (to me) like an overlay of complication.

I mean, what is the actual issue with a "plain" .html page with links *like*:
MediaPlayerClassic v1.71 for Win2K - MD5=bac8c681f6525c56091ba3ea2ae0ac4c

or similar? 

jaclaz