Are you sure that impacts the API calls? Pretty sure that the File APIs are not impacted by this and will not do the translation (you must use the UTF16 paths for that).
That's what I heard when I was told about this setting, but I haven't tested it myself.
What do you mean by the "right thing"? GetModuleHandleW(NULL) always returns the executable's module handle, which is what you would have gotten from WinMain.
Does the target triple encode that? If not, adding a Swift driver flag seems reasonable.
1 Like
You don't need argc. Unlike C pointers, Swift's Arrays store their count.
No, the triple does not encode the application type. If we have a driver level flag, then we practically have everything - main is synthesized by the compiler, and it can synthesize the appropriate entry point then. The actual difficult problem: what should the drive flag be? The implementation is simple enough and having the flag basically enables the compiler to generate the appropriate entry point, so nearly all of the problem is resolved with that, but figuring out a good spelling is a challenge.
@AlexanderM - yes, I am aware that you do not need it on the Swift side, but to construct the array in the first place, you do need the count.
Something like -windows-subsystem ?
My concern with that is that I don't want it to become confusing with WSL (Windows Subsytem for Linux). I can at least throw up a patch and we can take it from there I suppose
Maybe that's a possibility. "Subsystem" has been the term of art for this for decades, though, and I think most Windows developers would recognize that as a build flag (and would understand that WSL runs Linux-targeted binaries).
Following the precedent being set by property wrappers and function builders for user-defined attribute types, @*Main attributes also seem like a great candidate for being replaced with user-definable types. At least for NSApplicationMain and UIApplicationMain, something like this design seems like it'd work:
/// Attribute for creating a UIKit entry point with a given delegate class.
@entryPoint
struct UIApplicationMain<AppDelegate: UIApplicationDelegate> {
func main(argc: Int32, argv: UnsafePointer<UnsafePointer<CChar>?>?) -> Int {
UIKit.UIApplicationMain(argc, argv, nil, AppDelegate.description as NSString)
}
}
/// Using the attribute triggers synthesis of an entry point as if:
///
/// int main(int argc, char **argv) {
/// UIApplicationMain<AppDelegate>().main(argc, argv)
/// }
@UIApplicationMain
class AppDelegate: UIApplicationDelegate { ... }
For traditional Win32, there are a bunch of different moving parts to get a message loop off the ground, so it isn't as clear what you'd decorate. There could be more flexibility in how argc and argv get handed to the entry point as well, to make it easier to use higher-level types like [String] to process them.
1 Like
Sure, I think that providing the variants would be perfect. See https://github.com/compnerd/swift-win32/blob/master/Sources/Application/ApplicationMain.swift for an example for what we could really do. I think that this would really be nice. I want to try to get the validation test suite passing before I start taking a stab at the @*Main.
1 Like