Mirror of forum.nim-lang.org

7326 :: Creating Custom DLLMain using MSVC

• Chris3606 (orginal) [2021-01-02T22:55:04+01:00] view original

  Hi,

  I'm currently attempting to create a DLL with a custom DLLMain function in Nim. Based on this forum post , I created the DLL as follows:

  import winim/lean
  
  proc NimMain() {.cdecl, importc.}
  
  proc DllMain(hinstDLL: HINSTANCE, fdwReason: DWORD, lpvReserved: LPVOID) : BOOL {.stdcall, exportc, dynlib.} =
    
    if fdwReason == DLL_PROCESS_ATTACH:
      NimMain()
    
    return true
  Run

  This works fine when compiled with the standard MinGW backend (although I'm not entirely sure why NimMain is still exported from the resulting DLL since I haven't used .dynlib?), however I I decided to try it with using MSVC as the backend compiler and ran into an issue:

  
  PS> nim c -d:release --gc:orc --app:lib -d:useMalloc --nomain test.nim
  Hint: used config file '<...>\.choosenim\toolchains\nim-1.4.2\config\nim.cfg' [Conf]
  Hint: used config file '<...>\.choosenim\toolchains\nim-1.4.2\config\config.nims' [Conf]
  Hint: used config file '<...>\orcdll\nim.cfg' [Conf]
  ...............................CC: test.nim
  @mtest.nim.c
  <...>\nimcache\test_r\@mtest.nim.c(92): error C2375: 'NimMain': redefinition; different linkage
  <...>\nimcache\test_r\@mtest.nim.c(34): note: see declaration of 'NimMain'
  
  Error: execution of an external compiler program 'vccexe.exe /c --platform:amd64  /nologo /O2   /I<...>\.choosenim\toolchains\nim-1.4.2\lib /I<...>\orcdll /nologo /Fo<...>\nimcache\test_r\@mtest.nim.c.obj <...>\nimcache\test_r\@mtest.nim.c' failed with exit code: 2
  Run

  Based on previous experience with MSVC I'm guessing this has to do with calling conventions/name mangling, but haven't investigated fully. Wanted to ask, though, is this expected behavior when using --nomain? Is there a workaround?

---

• k0zmo (orginal) [2021-01-03T11:47:50+01:00] view original

  This is because the first declaration of NimMain that MSVC sees has no dllexport attribute. Try to declare it as follows:

  proc NimMain() {.cdecl, importc, exportc, dynlib.}
  Run

---

• Chris3606 (orginal) [2021-01-03T13:26:23+01:00] view original

  I'll give this a try later today. Out of curiosity, is there a reason NimMain is required to be exported from the DLL even even --nomain is specified. I can't imagine what benefit exporting it has in this case, particularly with ARC.

---

• k0zmo (orginal) [2021-01-03T19:26:58+01:00] view original

  --noMain only disables generation of the main procedure - WinMain, DllMain on Windows and main otherwise. Even with ORC you still have to "initialize" I/O and signal handlers (which is what NimMain does when you look inside the generated .c files). On non-Windows OS there's no such thing as DllMain so one has to invoke the NimMain manually - and to do this it needs to be exported.

---

• Chris3606 (orginal) [2021-01-03T20:54:48+01:00] view original

  Ah, that makes sense. Requiring an export that is in that case pointless on Windows feels a little odd, maybe even unsafe as it allows a user to potentially call it twice if DllMain is also doing it... But I guess makes sense as a side effect of supporting non-Windows platforms with the same compiler.

---

• jangko (orginal) [2021-01-04T04:46:39+01:00] view original

  this workaround works but it also rely on assumption about how the codegen works, may not works in the future.

  when defined(vcc):
    {.emit: "N_LIB_EXPORT N_CDECL(void, NimMain)(void);".}
  else:
    proc NimMain() {.cdecl, importc.}
  
  
  proc DllMain(hModule: HANDLE, reasonForCall: DWORD, lpReserved: LPVOID): WINBOOL {.stdcall, exportc, dynlib.} =
    case reasonForCall
    of DLL_PROCESS_ATTACH:
      when defined(vcc):
        {.emit: "NimMain();".}
      else:
        NimMain()
    ...
  Run

---