Mirror of forum.nim-lang.org

8897 :: Questions about creating dll with Nim

• rockcavera (orginal) [2022-02-11T00:35:48+01:00] view original

  I have a small package for creating dlls for use in mIRC - mdlldk. Faced with this situation, some questions arose about Nim and dlls, especially with regard to memory management.

  I'll explain first how the mIRC dlls work (or I believe they work with the little documentation). There are 3 types of procedures called by mIRC. Two have pre-established names: LoadDll and UnloadDll; are called automatically by mIRC when loading or unloading the dll, as can be understood from the names. The third type of procedure are the ones you access directly from mIRC through the /dll, $dll or $dllcall calls, to extend the language.

  The definitions in C are below:

  typedef struct {
    DWORD  mVersion;
    HWND   mHwnd;
    BOOL   mKeep;
    BOOL   mUnicode;
    DWORD mBeta;
    DWORD mBytes;
  } LOADINFO;
  
  void __stdcall LoadDll(LOADINFO*);
  
  int __stdcall UnloadDll(int mTimeout);
  
  int __stdcall procname(HWND mWnd, HWND aWnd, TCHAR *data, TCHAR *parms, BOOL show, BOOL nopause)
  Run

  Well, mIRC provides a pre-allocated memory pointer that you use to get information (parameter data) from mIRC and return it (parameter data and parms). There is also the LOADINFO object pointer that you can modify some BOOL types. So, in theory, there is no shared memory between the dll and mIRC (but mIRC shares it with the dll), because you copy into data and parms what you want to return to mIRC to analyze.

  The mIRC dll documentation is here, in case my speech wasn't enough.

  Now the questions that came to me are the following:

  1. when compiling the dll with --mm:refc (current default), should I link this dll to nimrtl.dll? Well, as I understand it nimrtl.dll is only needed when you have more than one Nim dll called in the same thread/program to avoid two garbage collectors. Would it be this?
  2. when compiled with --mm:arc I saw a forum post that possible question 1 would not exist and would no longer need nimrtl.dll. That's true?
  3. pretty much the same as question 2, but with --mm:orc, as I can't understand what the such cycles that orc collects would be, as I don't remember seeing a simple code explaining what it's these cycles, just read what Nim's default async system generates, but it's abstraction code that's hard to understand. So with orc the dll would need nimrtl.dll? (I would be very grateful if someone could explain didactically what would be a cycled code that arc doesn't collect).
  4. if compiling with --mm:arc|orc, is using -d:useMalloc for dll creation recommended?
  5. finally, is there any danger of some Nim memory manager (refc, arc or orc) touching the memory shared by mIRC with the dll? If so, a proof code would be interesting.

---

• Araq (orginal) [2022-02-11T07:42:53+01:00] view original

  All of your questions can be effectively answered with a simple "yes". You understand the situation quite well.

  My advice is to compile with --gc:orc -d:useMalloc, you don't need to worry about cycles and you don't need nimrtl.dll. Watch out though, it's often not clear which libc on Windows is used and some "mallocs" don't support DLLs well. Or to put it differently, it's best to ensure either of:

  • The malloc is the one the main application uses.
  • OR:
  • The memory management does not cross DLL boundaries. In other words, the DLL that created an object is also responsible for free'ing it. This is actually a fundamental problem that is not OS specific.

  How cycles are formed and how to avoid them should be its own reply.

---

• rockcavera (orginal) [2022-02-11T13:24:40+01:00] view original

  A long time ago I created a mIRC dll with C and I forgot to free a memory allocated with malloc and there was a leak. So, I believe that mIRC only controls the memory it allocates and the dll should be responsible for the memory it allocates itself.

  Thanks for the reply and advice.

---

• mratsim (orginal) [2022-02-11T20:58:43+01:00] view original

  I would love some foundational article about Nim for standalone DLLs / .so, ideally without having to call NimMain so that for library consumers they work like C libraries.

  This would be especially valuable for applications with a plugin system as well.

---

• Araq (orginal) [2022-02-12T08:09:30+01:00] view original

  NimMain is only required when you have top level statements in your program that need to run. (Assuming --gc:orc -d:useMalloc.)

---

• Prince213 (orginal) [2022-02-12T11:14:10+01:00] view original

  I'd wonder if these information could make their way to the documentation, presumably as a section in the Compiler User Guide. They're currently either missing or scattered in places.

---

• cblake (orginal) [2022-02-12T11:17:19+01:00] view original

  Of possible interest is some example code (sorry - not a foundational article) that I have for the run-time user configurable/extensible lc file lister, in particular extensions/lcNim.nim. { The example may be a bit more indirect than ideal in that it extends with a C callable thing, but the extension (for tests, anyway) runs a whole command to get its answer. } The same directory has an analogue version in plain C.

---

• kobi (orginal) [2022-02-14T15:00:55+01:00] view original

  mIRC? wow, you bring me back to the nineties!

---

• rockcavera (orginal) [2022-02-14T19:10:41+01:00] view original

  Truth. I started accessing IRC in 1999 with mIRC. And thanks to mIRC, around 2003/2004 I started programming, first in mIRC Scripting and then in Perl, PHP... Today I'm here with Nim.

  Good times.

---