Bootstrap to the future

[UPDATED – Sept, 22 2014 – changed Constants]

This rabbit hole is deep! And dark. I discovered winject.c can’t handle two string injects on a msvc compiled file (blank.exe). We already knew it can’t handle MingW compiled exe’s which is what led me into the rabbit hole.

I did manage to convince exerb to call my code for RT_STRING’s but I don’t know what I need to do to make it work properly and I can’t use winject,c for a base case anymore because I want something better.

Since no one cares about blank.exe and msvc, and I have to rewrite stub.c to handle which website and package (of many arch’s and versions) to download, I could define my own Shoes unique resources [user defined] and load them when the stub runs and write them from Shoes packager I also have to be aware of what Linux makeself can do. I want

  1. SHOES_APP_NAME – the name of the app
  2. SHOES_APP_CONTENT – the contents of the app’s shy
  3. SHOES_SYS_SETUP – optional, if exists it’s full Shoes exe to install first if Shoes isn’t already installed. Download and install Shoes if SHOES_SETUP doesn’t exist and Shoes doesn’t exist
  4. SHOES_SYS_SITE – the website (probably a cgi script) to download the closest Shoes3.2 from.
  5. SHOES_DOWNLOAD_SITE – website w/o http://, ie
  6. SHOES_DOWNLOAD_PATH – path to cgi script ex: /public/select/win32.rb
  7. SHOES_VERSION_NEEDED – a gem like string filter (defaults to newest version avaliable. This is sent as part of SHOES_SYS_SITE request url. No guarnatee that the website will do what you ask

In my New World Order, SHOES_APP_CONTENT is always a a Gziped ( via RubyGems) tar ball. It will always be expanded in a temp directory. There will always be two files inside. There is the install.rb script in that temporary dir – Packager will create a simple one if there isn’t a custom install.rb specified when packaged by the user.

The simple install script is a Shoes app (possibly using the Shoes just intalled to run it). It’s job is to unzip/untar the second file (a .shy like thing) in the temp dir and copy it to the user’s choice of directory and run any OS specific things to create menus or shortcuts, symlinks, registery entries to the ‘copied’ app and other ‘stuff’. That installer could also check if there is a third file in the temp dir, call it ‘shoes-{app}-gems’ Another tarball to be unwrapped/installed by the Shoes-app installer (think Shoes.setup only smarter). It could contain the C compiled binary gems that the Shoes app needs but are not availale in the normal gems repositories. (ie, no compiler on the host). I’m not sure how well that gem stuff would work, but it’s early in the spec process and reality will bite back.

Yes, I am aware that evil can be inflicted this way. That’s also true for any Shoes app or ruby gem. There is a reason for tar balls inside tar balls. Linux makeself only allows one binary when packaging and its a hack for Shoes hack to find it. Two is out of the question. OSX may have a similar issue. Either one could derail my Windows plan.

Leave a Reply

Your email address will not be published. Required fields are marked *