Command prompt is shown when you launch <appName>.exe

[h4cky]

Hi,

As per request from @compnerd I'am moving the discussion about the issue described here, original link: How can I get rid of the command promt window presented with my SwiftWin32 app? to here.

Summary (for those don't wanting to visit Swift Forums): Every time when i manually launch .exe it is presented above Command Prompt window - which i don't whant there :)

Versions of installed software:

• VS Community 16.10.0
• Windows SDK 10.0.19041.0
• MSVCv142 - vs 2019 c++ x64/x86 build tools (Latest)
• Swift 5.4.1

If you think any other information will help, ask away

Regards,
h4cky

P.S: Interesting thing which I just saw and remembered.
after checking out swift-win32-application as my template on first swift build it shows the following error:
'Application' D:\Developer\sw32a\swift-win32-application: error: product dependency 'SwiftWin32' in package 'swift-win32' not found
which i solve in the following way in Package.swift:

1. adding name: "SwiftWin32" on .package in root dependencies array

dependencies: [
    .package(name: "SwiftWin32", url: "https://github.com/compnerd/swift-win32.git",
             .branch("main")),
  ],

2. and changing the dependecies array on my .executableTarget

      dependencies: [
        "SwiftWin32"
        // .product(name: "SwiftWin32", package: "swift-win32"),
      ],

current swift build output:
build.log

[compnerd]

Hmm, the product dependency is important (would you like to create a PR against the swift-win32-application template to fix the issue or should I just do it?) but separate..

The expectation is that there would be no console window. How were you launching the application? I think I may have just not realized that a console window is created because I always launched the application from the console.

[h4cky]

1. i will create PR at some point, first i would like to try to understand why it happens.
2. as of how I am launching the executable, double click on .\.build\x86_64-unknown-windows-msvc\debug\Application.exe
3. I built swift-win32 few minutes back and even without my changes, Command Prompt is still presented when you double click on the executable. tested executable paths:
   -- cmake: \build\bin\UICatalog.exe
   -- swift build: .build\x86_64-unknown-windows-msvc\debug\UICatalog.exe

[compnerd]

Okay, I've definitely not been exercising the launch from explorer, which explains how this got through. Thinking more about it, it seems quite reasonable. A quick validation on this project shows that this is in fact, behaving "as expected" (as per the definition of Microsoft rather than as per my intention).

The problem here is that the entry point is being used for identifying the subsystem, and mis-categorizing the application as being a Windows CUI application rather than a Windows GUI application. Unfortunately, the entry point for the application is not entirely under the control of this framework (ignoring @main handling), the user defines the entry point and invokes ApplicationMain(_:_:_:_:). This largely means that there isn't much that I can do from the framework side, which is really rather disheartening. I suppose that we will need to document that for the case where the user opts to define the entry point rather than using the @main attribute.

For the case that the user uses the @main attribute, the user doesn't define the entry point, but will still result in the application being marked as a CUI application as the entry point that is generated is still named main.

[compnerd]

@h4cky would you mind testing with compnerd/swift-win32-application@ac42bea ? I think that should avoid the console window. It is not exactly ideal, and it seems like this is a good item to bring up on the forums as a generalization that should be made available through the driver (and SPM). It is likely to require some sort of evolution proposal, but now that we know what features Swift needs to provide, taking a request for changes to Swift seems reasonable to discuss on the forums.

Thanks for reporting this issue!

[compnerd]

CC: @yostane - this might be a good thing to document, if you feel up to it :)

[h4cky]

@compnerd

[275/278] Compiling Application AppDelegate.swift
<unknown>:0: error: unknown argument: '-entry-point-function-name'
[276/278] Compiling Application SceneDelegate.swift
<unknown>:0: error: unknown argument: '-entry-point-function-name'

[compnerd]

Oh, bleh, that seems like it might be a 5.5+ thing. That is really rather unfortunate. For pre-5.5, I think that there is very little choice other than:

@_silgen_name("wWinMain")
func wWinMain(_ hInstance: HINSTANCE, _ hPrevInstance: HINSTANCE, _ pCmdLine: PWSTR, _ nCmdShow: CInt) -> CInt {
  return ApplicationMain(CommandLine.argc, CommandLine.unsafeArgv, nil, nil)
}

You would also need to add:

linkerSettings: [
  .unsafeFlags(["-Xlinker", "/SUBSYSTEM:WINDOWS"]),
]

to the targets in Package.swift.

[h4cky]

Oh, bleh, that seems like it might be a 5.5+ thing. That is really rather unfortunate. For pre-5.5, I think that there is very little choice other than:

@_silgen_name("wWinMain")
func wWinMain(_ hInstance: HINSTANCE, _ hPrevInstance: HINSTANCE, _ pCmdLine: PWSTR, _ nCmdShow: CInt) -> CInt {
  return ApplicationMain(CommandLine.argc, CommandLine.unsafeArgv, nil, nil)
}

where do I place this?

[compnerd]

That should be possible to add to the same file as the application delegate.

[compnerd]

@h4cky compnerd/swift-win32-application@d3e5306 should give you a more instructive example of what I was trying to explain.

[h4cky]

@h4cky compnerd/swift-win32-application@d3e5306 should give you a more instructive example of what I was trying to explain.

That's the desired effect. Thanks!!!

I suspected that I am missing some import ;)

[yostane]

CC: @yostane - this might be a good thing to document, if you feel up to it :)

Hi, thanks for the suggestion, I'll try to take a look :)

[compnerd]

I was keeping this open for the fact that the demo applications (Calculator and UICatalog) needed the changes applied to them, but I've created new tasks to track them. I'll cover the documentation via the project board. I'm going to close off this issue. Thanks for reporting this @h4cky!