Axis Network Cameras have a control interface which can be accessed by typing out a camera's IP address and pressing enter. There is a tab called applications which lets us upload and install pre built applications to our Axis Camera. Only applications with the extension of .eap can be uploaded, or rather the installer for an application. I'm wondering what are these .eap files and how would I export my project as an .eap file so I could upload it to my Axis Camera.
EAP files are simple tar.gz files. You can see the tar command in doMakeTheTar function in eap-create.sh script. So you can make your own eap files using tar.
Related
Sadly we dont have direct access to the internet in my company. We can handle automatically downloading and packaging VSCode itself using our internal chocolatey but but providing extentions is still a big problem. Partly because they install into the user directory.
Is there a way I can either:
a) Internalize vscode extentions, like a setting that points to an internal nuget server (much like the full visual studio gallery)
b) Place extentions on a pc in some system level location. Eg C:\ProgramData\VSCode\Extentions and then we can install extentions for all users on a given computer using chocolatey.
Private extension galleries are not supported as of VSCode 1.13 but we are tracking the feature request here: https://github.com/Microsoft/vscode/issues/21839
You can manually install and share extensions as vsix files though. See https://code.visualstudio.com/docs/editor/extension-gallery#_common-questions for details
I want to upload the VCD file through an through application A and need to install that uploaded files to other Cortana application B. How can I achieve that? Any answer would be appreciated.
Naveen,
I think instead of having a separate app, You can have a setting to upload VCD through application A itself. To say correctly, you should upload the VCD file through the app A and install it straight away from there. That would be more intuitive.
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.
I have developed a mostly HTML/CSS/jquery application in Aptana. Does anyone know the steps to take to convert this project to a .BAR file for use with the Blackberry Playbook simulator?
I'm guessing I need to package the project as an .airi file first, then use the Blackberry bbwp tool to compile? Has anyone had any experience with this process?
Thanks so much for any help.
This is a bit late I suspect but you have to download RIM's WebWorks package and follow all the necessary steps on their website. Basically, once you are as far as you are, you zip what you've got with a config.xml file and run their command line tool to turn it into a .bar file. Here's a little secret - a .bar file is actually just a .zip file by another name. If you change a .bar back to a .zip file you can treat it like any other zip file.
After you've done this, run the signing tool, (results and mileage may vary) and then push it out to the device with another command line tool. In the simulator you have to set it to "Development Mode" and get the IP address. You put the IP address into the command line tool and it will put it onto the device. You may have to restart the simulator for it to show up. If you can't get the signing tool to work you should still be able to put it onto the simulator.
Download WebWorks and get started here - http://us.blackberry.com/developers/browserdev/
You will need to sign up for a developer account to download it.
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).