I wonder if is possible to package into an executable in VA Smalltalk. Posts on this subject seem to have contradictory or old information. The README from Instantiations comments about splash screen and other resource tweaks for client installs, but is not clear about making an executable application for distribution.
In that case:
Does generating an exe file implies stripping an image?
Is the image bootstrapped, i.e. built from scratch?
so here is my attempt to give a short answer.
You do ship several components when you deploy your application as a runtime:
Your stripped down image (VA ST has a very powerful tool called Packaged Image Browser for this task)
The Virtual Machine (a .exe on Windows). You can customize this exe to display your splash screen or your window icon.
A number of additional files that are needed by the VM and/or your image. These are pictures, message catalogs, additional DLLs etc. VAST has an exhaustive list of which files you have to ship if you use some feature of the product in the VAST documentation
So there is no mechanism to bundle VM and Image together and turn them into a single .exe file, like in Dolphin Smalltalk and maybe more. What you ship is usually a Directory with a few subfolders in it.
There's no way to embed the image (.icx file) into the executable (.exe file) with VA Smalltalk. The best you can do is have an exe file for the VM and your own custom icx file for the image plus a .ini file for configuration. The "Make Executable" option in the organizer creates these files for you but you still have several files.
Here is a good resource for starting out making runtimes.
Although, as mentioned, you can "Make Executable" from the option menu, my experience is based on the runtime packaging.
Related
Background
I have an Android app which uses native ARM64 executables (essentially GCC toolchain, extracted to app directory (/data/data/%package%/somePath) on the first run) to do some work. Due to Android 10 changes files in /data/data/.. can't have executable permission anymore.
Confirmed workaround
The workaround is to make executables look like shared libraries (libsomething.so) that are extracted by Android to /data/app/%package% dir with android:extractNativeLibs="true" in AndroidManifest.xml and are allowed to have executable permission. Symlinking might be useful to mimic the previous files structure.
The problem
The problem is that all the executables (aka new "shared libs") are packed into android apk with zip compression ratio (as apk is essentially just a zip file) which could be better if it's archived with 7zip for instance and together weight more than 100Mb which is app limitation on Android (for apk files).
The question and the proposal
How can i split the executables into a small part (that goes into /data/app/%package% and a large part (or just existing executable in /data/data/%package%)? The idea is that small executable just "loads and runs" a regular one. The benefit it that regular executable is compressed with 7zip and it makes apk size much smaller due to 7zip used with a better compression ratio.
I've been looking into direction of using of UPX but having no experience with it (note i will have to prepare executable on Mac machine (or Linux with VM or Docker) to run on Android ARM64). Also i've been thinking about creating of 7z sfx but it seems to be tricky (again, it have to be created on x86_64 and run on ARM64). Also I've found some similar QA (which recommends memexec() or fexecve()), but I'm not sure what's the optimal way to go.
Ideally I'd love to have some tiny "universal" ARM64 executable (or be able to compile it from the source code with Android NDK) that just accepts cmd and a regular executable path.
PS. App bundle and dynamic delivery modules as high-level alternatives are undesired for different reasons.
PPS. UPX did not work out of box for Android 10 (seems to be security issue).
I cannot manage to install Squeak and Pharo Smalltalk on Mac OS X 10.9.
as general a smalltalk system is composed of three elements; a VM, an image(if any changes to image then a changes file), and a sources file.
on squeak page
I have downloaded all in one linked file, but it does to include an .image or .sources. it includes a .app. on the page this is mentioned to be the VM on mac, and it is mentioned to include all files one require. anyway double clicking does not launch smalltalk.
on pharo page
similar promise but does not launch again. it says download that file it includes everything necessary and just run the executable. but it includes .image .changes and .sources files in sub directory of /Pharo2.0.app/Contents/Resources.
Am I doing something wrong?
UPDATE:
for squeak I have also found the .image .change and .sources files in some sub directory of the all-in-one. Should i, both for pharo and squeak, move these files to the same directory with the .app file.
UPDATE:
i have tried so. no change.
UPDATE:
because it is not signed upon first launch i modify settings to launch it authorizing as admin user one time. no problem with that.
The first time you run the Squeak all-in-one, you need to right-click the app and choose "open". Then you will get a dialog that let's you run it. If you just double-click you get the same warning dialog, but without the option to run it.
This is because the Squeak app is not signed with an Apple developer key.
You also can to change the run permission in System Preferences (Security Preferences), from "Map App Store" to "Anywhere".
The problem emerged from the fact that the application I had downloaded from Squeak or Pharo websites were not executable in my computer.
Issuing a change mod add executable command from terminal solves the problem for each one.
chmod +x /path/to/smalltalk/squeak/or/pharo/apps
I am new to Adobe AIR. Please help
I want to Add status icons over file icons in Explorer, like Dropbox or SVN. I am developing anappliation like dropbox in Adobe AIR for MAC and Windows.
I think it is common for both OS Mac and Windows both OS support AIR so i have choice this tool.
I have two queries.
Add status icons over file icons in Explorer, like Dropbox or SVN.
Folder watcher you have and idea about that and any class and utility for that.
Personally, I don't think AIR is the correct solution for this. Although it would be possible to poll a directory and compare its last known structure to its current one, I imagine this would be very inefficient in both Actionscript 3 and Javascript.
Languages such a Java in their latest major release have utilities for directory monitoring 'out of the box' and have the benefit of being able to delegate these tasks to different threads.
To give another example something like TortoiseSVN which monitors directories and dynamically changes the icons is written in C++.
I'm developing an "installation" like cocoa application wich needs to take care of some http request, some file system reading, copying files to /usr/share, set up cron (not launchd) and ask some information to user.
I discarded PackageMaker since I need more flexibility.
Currently everything is going well, but on my last installation step, I need to:
Delete my previously installed application folder (if exists). It's always the same path: /usr/share/MY_APP
Create again the application folder at: /usr/share/MY_APP
Copy application files to /usr/share/MY_APP
Update a cron job
It's very important that /usr/share/MY_APP keeps protected with administrative privileges, so a regular shouldn't delete it.
What would be the best approach to implement those steps?
BTW, I'm using Xcode 3.2.
Thanks a lot!
Carlos.
Between the preflight script, the postflight script, and perhaps an Installer plug-in for the custom UI, I see no reason why you can't do all of this in PackageMaker.
Note: “Installer plug-in” is a little misleading. The user does not have to install the plug-in somewhere as a separate step; you include the plug-in inside your package, and Installer will use it from there.
The relevant document is a ReadMe file in a sample code project. There's also an Installer plug-in project template in Xcode since 2.0.
Also, an Installer plug-in won't get used if the user does a command-line installation. Of course, they can't install from the command line at all (which includes remote installation onto an office or lab full of machines) if you write your own custom installer.
By the way: Why /usr/share? What are you putting there? There may be a better way to do what you're really trying to accomplish.
I have a Windows CE device that we are deploying, but we have complete control of the software installed on it.
This is not a typical Windows Mobile device, this is a headless device that the user will not interact with. I know that on PDA-style WinCE devices, the .cab file is the preferred application distribution method.
However, on a headless device, we will be writing some type of upgrade/patch server that will ping a server for updates, download them, and auto-install when they are available.
Do I still want a .cab file, or is a .zip (or even something else) better?
What are the requirements for a .cab file - what kind of restrictions / requirements might get in the way and be an annoyance? What are the benefits?
I'd stick with CAB as a package since even headless devices can use the CAB extraction tool. If you ZIP it, then you have to add a ZIP support library and app. CAB also has the ability to add registry entries and define far more disparate target locations than a zip (I want x.dll in \Windows but prog.exe in my program folder - try that with a ZIP).
One thing to keep in mind is that wceload (the CAB extractor) uses a UI by default, so you're going to want to use things like the /noui switch for it.
If you're true headless this may not be an issue (not done that in a long while) but a fairly common "headless" configuration has display support and either the display simply isn't hooked up or is something like a NOP VGAFLAT driver. This allows you to run a shell and have access to all the nice shell APIs, but adds to the challenge that GWES will render dialogs onto the non-existent display.
OpenNETCF also has a CAB Installer SDK that you can use to completely remove any UI with by creating your own installer app. This may or may not be useful depending on the how and when the install happens (through HKLM\Init or otehr for example).