I create simple CLI app on Elixir. Can i release my app and use it on the other PC without Elixir and Erlang? I read a few materials on the CLI and didn't find any release instructions.
You can try this (e.g. using Distillery) but it's not guaranteed that the distributed app will work on all other systems (even within the same OS). So, it's OK if you want to do this for one or two friends but it's a bad idea to publicly distribute your software in this manner.
Related
I'm trying to make a GUI frontend in iOS for a chess-like game engine where the API via std input/output. The API it adopts is called the Universal Shogi Interface. It allows decoupling of the GUI and engine so that one can swap out either component without much trouble.
This works fine when building and running via Terminal of course. I also know that I can create a macOS GUI for it by using NSTask but how would I incorporate such a program into an iOS app where NSTask isn't available?
Is there a way to spawn a subprocess in iOS which I can then connect UI buttons to send text commands to the subprocess? (and likewise, labels to read stdout from the program)
Or is would I have to go into the source code of the engine and connect call the functions themselves? That seems like it would defeat the purpose of having a GUI protocol in the first place. Or would I have to port the entire engine into Swift myself?
It isn't clear what you mean by "...the engine GUI protocol is to communicate with it via text commands via std input/output." GUI stands for "Graphical User Interface". A terminal based text interface is the exact opposite of a graphical user interface. It's a command-line interface. Do you mean that the API (not GUI) to the game engine is through a command line?
iOS dos not let apps spawn sub-processes of any kind. You can build third-party frameworks into your app, and those third party frameworks might have an API that takes commands in the form of text input.
It might also be possible to have a 3rd party app running at the same time and taking commands via a custom URL scheme, but iOS doesn't really support the kind of multiprocessing where this makes sense, unless maybe you're using the split-screen interface on iPads in iOS 10 & 11, and I'm not sure if/how well that would work.
Is there an api for chrome apps that would allow developers to read (and/or write) environment variables?
Thanks.
No. Chrome Apps are sandboxed, so they shouldn't be able to make those kinds of persistent changes to the system, and they are supposed to be portable across host operating systems, so system-specific concepts like environment variables are generally unavailable.
Sorry, no.
There is another question that is perhaps a little relevant: I want to create a native app that runs in all OS, and can run terminal commands
I'd like to see what kinds of API/framework calls are being made by an arbitrary iOS app. Is there some sort of mechanism or tool that I can use to do this?
For clarification, the term you are looking for is hooking. It can be easily be done on a Windows system.
Excerpt from Wikipedia:
ptrace is a system call found in several Unix and Unix-like operating systems.
Given the design of iOS running one app at a time, I don't believe you can do this. Plus your app will be running in a sandbox environment with each app having it's own virtual address space.
I have a CouchDB instance running on one machine, and thus with its own Erlang VM process. If I have another separate Erlang application running on that machine too, is it be better to share the same VM between CouchDB and my application, or is it recommended to start a new Erlang node?
While many would recommend decoupling these subsystems I would take the opposite approach. Erlang has a built in strategy to run many applications on the same release. If your applications talk to each other directly it might make sense for you to bundle them together into a release. This will make calls between the applications faster. Some will argue that all you applications now share the same fate should you need to take the system down for an upgrade that only one of the applications needs. This is a moot point with Erlang where you are distributing your applications across many nodes. Also most upgrades can be done with hot code loading.
There is no problem with running several VMs on the same machnie (at least recent OTP releases), however it is quite handy if you have all your applications on one Erlang node. Easier communication, dependency management, supervision, fault-tolerance - you get it for free in this case, not mentioning maintaining only one 'node' in source control system.
The problem starts with CouchDB. It does not have decent build system which let you use it as one of independent Erlang node applications. So in this case you need to have at least 2 VMs (one acts as Couch daemon, the other one hosts your application)
The situation is simple. I've created a complex Delphi application which uses several different techniques. The main application is a WIN32 module but a few parts are developed as .NET assemblies. It also communicates with a web service or retrieves data from a specific website. It keeps most of it's user-data inside an MS Access database with some additional settings inside the Registry. In-memory, all data is converted inside an XML document, which is occasionally saved to disk as backup in case the system crashes. (Thus allowing the user to recover his data.) There's also some data in XML files for read-only purposes. The application also executes other applications and wants for those to finish. All in al, it's a pretty complex application.
We don't support Citrix with this application, although a few users do use this application on a Citrix server. (Basically, it allows those users to be more mobile.) But even though we keep telling them that we don't support Citrix, those customers are trying to push us to help them with some occasional problems that they tend to have.
The main problem seems to be an occasional random exception that seems to pop up on Citrix systems. Never at the same location and often it looks related to some memory problems. We've p[lenty of error reports already and there are just too many different errors. So I know solving all those will be complex.
So I would like to go a bit more generic and just want to know about the possible issues a Delphi (2007) can have when it's run on a Citrix system. Especially when this application is not designed to be Citrix-aware in any way. We don't want to support Citrix officially but it would be nice if we can help those customers. Not that they're going to pay us more, but still...
So does anyone know some common issues a Delphi application can have on a Citrix system?
Does anyone know about common issues with Citrix in general?
Is there some Silver Bullet or Golden Hammer solution somewhere for Citrix problems?
Btw. My knowledge about Citrix is limited to this Wikipedia entry and this website... And a bit I've Googled...
There were some issues in the past with Published Delphi Applications on Citrix having no icon in the taskbar. I think this was resolved by the MainFormOnTaskbar (available in D2007 and higher). Apart from that there's not much difference between Terminal Server and Citrix (from the Application's perspective), the most important things you need to account for are:
Users are NEVER administrator on a Terminal or Citrix Server, so they no rights in the Local Machine part of the registry, the C drive, Program Folder and so on.
It must be possible for multiple users on the same system to start your application concurrently.
Certain folders such as the Windows folder are redirected to prevent possible application issues, this is also means that API's like GetWindowsFolder do not return the real windows folder but the redirected one. Note that this behaviour can be disabled by setting a particular flag in the PE header (see delphi-and-terminal-server-aware).
Sometimes multiple servers are used in a farm which means your application can run on any of these servers, the user is redirected to the least busy server at login (load balancing). Thefore do not use any local database to store things.
If you use an external database or middleware or application server note that multiple users will connect with the same computername and ip address (certain Citrix versions can use Virtual IP addresses to address this).
Many of our customers use our Delphi applications on Citrix. Generally speaking, it works fine. We had printing problems with older versions of Delphi, but this was fixed in a more recent version of Delphi (certainly more recent than Delphi 2007). However, because you are now running under terminal services, there are certain things which will not work, with or without Citrix. For example, you cannot make a local connection to older versions of InterBase, which use a named pipe without the GLOBAL modifier. Using DoubleBuffered would also be a really bad idea. And so on. My suggestion is to look for advice concerning Win32 apps and Terminal Services, rather than looking for advice on Delphi and Citrix in particular. The one issue which is particular to Citrix that I'm aware of is that you can't count on having a C drive available. Hopefully you haven't hard-coded any drive letters into your code, but if you have you can get in trouble.
Generally speaking, your application needs to be compatible with MS Terminal Services in order to work with XenApp. My understanding is that .NET applications are Terminal Services-compatible, and so by extension should also work in a Citrix environment. Obviously, as you're suffering some problems, it's not quite that simple, however.
There's a testing and verification kit available from http://community.citrix.com/citrixready that you may find helpful. I would imagine the Test Kit and Virtual Lab tools will be of most use to you. The kit is free to use, but requires sign-up.
Security can be an issue. If sensitive folders are not "sandboxed" (See Remko's discussion about redirection), the user can break out of your app and run things that they shouldn't. You should probe your app to see what happens when they "shell out" of your app. Common attack points are CHM Help, any content that uses IE to display HTML, and File Open/Save dialogs.
ex: If you show .chm help, the user can right-click within a help topic, View Source. That typically opens Notepad. From there, they can navigate the directory structure. If they are not properly contained, they may be able to do some mischief.
ex: If they normally don't have a way to run Internet Explorer, and your app has a clickable URL in the about box or a "visit our web site" in the Help menu, voila! they have access to the web browser. If unrestrained, they can open a command shell by navigating to the windows directory.