I wonder if there is a way of running an app in Xcode,
and then, without closing it, launching another instance of the same app.
I want to know this because I want to create a program for network communication
and need two instances to test how the program behaves.
The program is written in C++ using SFMLs network module.
Obviously, I can get the desired effect by creating a new identical program and running it, but it would be easier if they where the same (save me the copy/paste before each run).
I'm running Xcode 6.4.
I have never done this with XCode, but with any other IDE I would simply open the project twice, so two XCode instances are running, both on the same folder. That way you have "shared" code and your changes are automatically there when you recompile and restart both instances.
Related
I want to develop App with GUI, that can be run without showing GUI. How I can do it?
If it's possible would this App work on servers that do not have nothing related with GUI (ex: can I work with such App with ssh or so).
Any example please if it's possible.
Yes, it isn't always easy though and might not be worth it. The general idea is to write a console program that attempts to dynamically load the gui libraries and create a window. If that succeeds, it detaches from the console/controlling terminal and becomes a gui program. On Windows, this may pop up a console window briefly when the user double clicks the exe as it would be created first, then quickly destroyed.
You would want to dynamically load the gui with dlopen/LoadLibrary because the libs might not even be present on the computer you're running on, and if you rely on the system to load them at startup, your program won't run at all when they are missing. This is the most painful part - checking the return value of XOpenDisplay or CreateWindow or whatever is easy, and detaching from a console is easy (FreeConsole or fork). But first you need to get your program to actually start in the worst case scenario of no client side gui libraries at all.
If you're ok with ignoring that case - if the libs are present but the display isn't, you just handle it as a regular runtime error - then it isn't too hard at all.
We've got a fairly mature cross-platform game engine which we've had running on OSX for several years now without a hitch; we recently upgraded the game from SDL 1.2.15 to 2.0, and at some point in the conversion, I goofed something up and now we have a bizarre problem where the app launches just fine from the terminal, but when you launch the app from a double-click in the Finder, it just bounces once in the dock and just goes away.
We're baffled because insofar as I can tell, there's only a one-liner being printed in Console.app: Exited with code: 255 (naturally running from the terminal doesn't help here because we can't reproduce the problem there; the app runs fine when launched in a terminal).
So the only thing we can figure is it's either something we're goofing up in our main.cpp, or something we've hosed in how I set up the dylibs/frameworks. It's also possible that it's something to do with the working directory not being set right, but to the best of my abilities, I believe we're doing it right (regardless of your current working directory; the app attempts to forcibly set said directory to be in the Resources folder - this was necessary to get the game to launch, but I don't know if we're doing it wrong). This feels like a somewhat awkward fit for stackoverflow, for which I apologize, since it's not a simple "paste this code and ask what's wrong" job. I have two ways for you to reproduce it; firstly we are an open-source project, and you can get our source code (complete with a mac project file and all dependencies included in the repo, set up and ready-to-go exactly as I've perhaps erroneously created them), at our github page. The one change you'll need to do is open a file at the root level, named master-config.cfg, and remove the // comments from it (so the engine knows you want to launch a simple demo game shipped with the engine).
Alternately, I have a stripped down (~15mb zipped) binary you can directly download and try to run, if that's sufficient to diagnose the problem.
As said before, we're open-source, so we welcome any pull-requests for fixes!
You need to write a minimal Cocoa wrapper so that OS X will not SIGKILL you for not launching properly. I will give you a pull request with that wrapper.
I am having some problems with a app we are making with wxWidget/wxPython and PyInstaller.
We have compiled the app into a single exe for windows but:
1) On some machines it will not launch at all. It doesn't generate a error or anything in the app logs. It just stops almost immediately.
2) On some machines it will launch fine from cmd but not from explorer. again, same behavior. It just stops almost immediately. I don't even see it pop up in the process explorer.
3) On some machines it works just fine.
Are there any tips on how I can figure out what is going wrong? Is there a way to launch a exe with a debugger?
There are a few things you may want to look into:
Did you compile it as "one file"? I have heard that one exe may be blocked by some antivirus programs. It uses a few of hacks to get everything in one executable which may be considered malicious.
Did you compile it as Windows app (no console)? You may want to enable console and run it on machine where it does not run at all from console. That way you may see why it crashes.
I am looking for ways to enable silent auto updates for my windows application. The update process should be such that only the changed files are downloaded and replaced. So, I have planned to integrate it with my application. Considering the fact that renaming/moving a running executable (or its folder) is possible, Is it alright to use the application to update itself?. Is renaming/moving a running executable dangerous?. What are all the advantages of using a separate updater program over using the application itself to update it?
Thanks!.
I think the main disadvantage with allowing the application to update itself is that it makes it harder to be sure that all activity has stopped, for example that all asynchronous I/O has completed, all user interface elements closed, and all data flushed to disk. Typically, with a separate updater, the application process will exit before the update begins so that you can be certain nothing is happening that will interfere with (or be interfered with by) the update process.
If you're just trying to avoid having a separate build, you could design the application so that after downloading the new content it makes a copy of itself (or, if the updater component has itself been updated, extracts a copy of the new version of itself) in a temporary location and launches this copy in update mode. An application that decides at launch-time whether it is being an updater instance or a regular instance is easy to design and doesn't have the problem mentioned above.
The windows operating system will not let you overwrite an application which is running. You need another application to do that. One process I have is that I have my downloader application download files but if they are in use they are given the extension .update.
My application then when it starts looks for any files with that extension in the folder and sub-folders. If it finds one it will launch a patcher application and terminate itself. The patcher waits for the program files to become free and then moved the .update files over the top of the application files and restarts the application.
It takes a split second extra to launch when there are updates but the user doesn't notice.
In addition:
The advantage of a separate updater program is about modularity and cleanliness. You could reuse the updater software and its code is probably not core to what your application is doing. Plus unless you make it multi-threaded its going to impact the interactivity of your application whilst it working.
I've seen a lot of programmers go for the monolithic approach to deployment (with static builds), however modularity still has major benefits if you ask me.
I am making a download and installing application that must run multiple times at the same time. However, is it smart to do so? My application uses the /tmp directory to save temporary downloads. Each instance of the application needs its own dock icon, that's the reason I use multiple instances.
Is it dangerous to have multiple instances of the same application running at the same time? Why or why not? Thanks.
No, I cannot use Installer.app. And yes, it's about a Mac!
As long as you don't modify the same resources (without precaution) you're fine.
You can easily start several instances of (almost ?) any Mac app, via the terminal. For example, type this several times into the shell:
/Applications/Calculator.app/Contents/MacOS/Calculator &
Everytime you press enter you'll see yet another calculator open. It's only Finder/open that only start an app once.