Rethink the way DLLs are created under Windows

[Ekopalypse]

PR #23961 introduces an "hidden" main entry point for DLLs created in Vlang and raises some concerns about the impact on DLL behavior and developer practices.

From a DLL developer's perspective, this change affects the ability to control the lifecycle of the library. In particular, it removes the guarantee of deterministic initialization, which is essential for setting up global states, allocating critical resources, or integrating with external systems. For example, initializing logging systems, configuring memory pools, or registering COM objects may now become more difficult or require workarounds that may not be as robust or reliable.

While I understand the intent behind the PR - to streamline or improve the loading of DLLs - the current implementation seems to displace some core functionality that developers rely on.

There seems to be a need to rethink an alternative design that allows library developers to retain explicit control over initialization.

[!NOTE] You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote. Other reactions and those to comments will not be taken into account.

[huly-for-github[bot]]

Connected to Huly®: V_0.6-23000

[JalonSolov]

The simplest change would be for V to continue as it is now, creating a DllMain() to handle calling C._vinit(), etc.

However, it should first check to see if the V code exports a DllMain() of it's own, in which case it wouldn't generate one.

The proper way to define a DllMain() as well as the need to call C._vinit() should be documented properly, but the user would be free to do any other initialization they wish.

This would give "the best of both worlds"... if you aren't concerned about initialization, but just want a DLL to work, then what V does now saves you worrying about it.

If you do want the extra control, creating your own DllMain() would allow you to do so.

[kbkpbot]

Or we can make a checker for this, When user create a v dll under windows, the checker will check for DllMain() defined in user code. If no, it just issue a error and force user define it. :)

[Ekopalypse]

@kbkpbot Does this mean that you want to revert the creation of the DllMain function by V internally and then the user code is responsible for it again? Yes, that works. But a) documentation and b) the initialization of V ( and maybe Böhm ) must not change is needed.

[JalonSolov]

The smiley at the end implies he was joking. At least I hope he was.

V is billed as "Simple". It is not "Simple" to require everyone to learn how to properly write a DllMain function.

If you don't care about how it works, but simply want DLLs created with V to work, then what V is doing now is the correct thing to do.

However, just as V has more advanced features for when you need them, there should be a way to write your own DllMain without V interfering.