My question is this: is it important that your application be a "windows" application? What are the benefits over a "console" application.
"console" applications are good for apps where you have a practical use of the app being hardwired to the presence of a console window only. So it's a nice default setting for developers, to have a console to print out to, take text input, and so on.
The issue is just that "console" applications, if launched not from a console (but from, say, Explorer), get a console window allocated to them at startup, even if there is no console IO.
If you want to make an UI app (for example, an alarm clock), obviously you want your users' experience to be about your UI only, and a console window popping up in the background would be quiet shocking for them.
In console apps, you can deallocate the console I think, but even then it flashes by quickly on the screen, giving the user a feeling that something is not right.
So the most straightforward thing for gui apps is to be compiled as "windows" application, and then to not use any console io at all (so, no access to current-output-port etc. at all, not even a (force-output) to it), because on such use a console window would be dynamically allocated anyhow. (There's some way to deallocate it just like above, though of course then it'd flash by at least just like above.) REPLeffect ought to have had some routine in his app that did that, and this is why the dynamic console window allocation he experienced was remedied by your suggestion of overwriting current-output-port with a dummy port..
Not completely obvious abstraction this console vs. windows application thing. How is it in Unix, GUI apps have their own stdin/out completely decoupled from the GUI workings, and generally it's piped to the app's console which may be the host terminal window of the X server, or /dev/null, sth like this.