There are many ways you can tackle this but what I would recommend is having one of the parts (GUI/Core) as the main application that does all of the initializations and starts the other part. I would recommend using the core for this.
Here's a sample architecture you can use, though the architecture you choose is highly dependent on the application and your goals.
Core runs first, performing initialization actions including starting the GUI, sets up the communication between the GUI (using pipes, sockets, etc), then waits for commands from the GUI. If the GUI signals to close, the core can perform whatever clean up necessary and then exits. With this scenario, the lifetime of the exe is controlled by the GUI.(GUI sends a signal to the core when the user hits the exit button to let the core know it should exit)
If the core starts the GUI, then it can set up the STDIN/STDOUT pipes for it and listen for commands on the STDOUT, while sending results on the STDIN. You can also take the server approach, having the core listen on a socket, and the GUI sends requests to it and wait for a response. With the server approach, you can have some sort of concurrency unlike the serial pipes, but I think it might be slower than the pipes (the difference might be negligible but its hard to say without knowing what exactly you're doing).
