我的google-fu关于这个问题的弱点...（编辑/扰乱：_毕竟不是问题，见下文）
为了提供一些上下文，我正在使用Nim开发一个小的便携式程序。有时候，我想在win32上使用getch()（使用旧的Windows XP）......
Nim医生说：
proc getch(): char {.raises: [], tags: [].}
从终端读取一个字符，阻塞直到输入。该字符不会打印到终端。这不适用于Windows。
...所以我最终使用了：
proc getch(): cint {.importc: "_getch", header: "<conio.h>".}
这对我的需求很好。但是后来我尝试使用dynlib编译指示代替：
proc getch(): cint {.importc, dynlib: "msvcrt.dll".}
在运行时失败：could not import: getch。没有魔法，符号应该以下划线开头！但是，_getch甚至`_getch`在Nim中是非法的。
（注意：据称CRT中有一个getch，但MS告知它已被弃用，我们应该使用_getch代替。）
为了确保，我尝试使用Nim不知道的libc符号：
proc atoi(s: cstring): cint {.importc: "atoi", header: "<stdlib.h>".}
和
proc atoi(s: cstring): cint {.importc, dynlib: "msvcrt.dll".}
这两种情况都适用; atoi（显然）不以_开头。
在这种情况下，我现在可以使用header pragma，但这是一个我可能会再次遇到的一般问题，因此我的问题是：
如何使用_ pragma导入以dynlib开头的符号？
最好的是同一{. .}中的另一个pragma，而不是调用工具链时的标志，但此时任何提示都是受欢迎的。我正在寻找一种不依赖于外部库或其他语言的解决方案。
干杯。
（Nim 0.13.0）
编辑：（如果其他人遇到同样的问题）
好的，所以我正在追逐错误的问题。正如@flyx所评论的那样，importc: "symbol"可以与dynlib一样使用header。问题是，我曾经尝试过，并且因为错误的原因而解雇了这个组合（因为Nim仍然处于严重的发展状态，有时我不得不猜测......这次不幸）。
事实上：
proc getch(): cint {.importc: "_getch", dynlib: "msvcrt.dll".}
proc kbhit(): cint {.importc: "_kbhit", dynlib: "msvcrt.dll".}
对我不起作用。不是在编译时，而是在运行时。
那仍然没有：_getch直到我按Ctrl-C它才会返回（也许这就是为什么它首先没有在Windows上实现！）并且在_kbhit上有一个循环我需要杀死任务。
proc getch(): cint {.importc: "_getch", header: "<conio.h>".}
proc kbhit(): cint {.importc: "_kbhit", header: "<conio.h>".}
干活。
但是因为现在我成功测试了
proc atoi64(s: cstring): clonglong {.importc: "_atoi64", dynlib: "msvcrt.dll".}
我可以说下划线不是问题。
答案 0 :(得分：1)
使用：
proc getch(): cint {.importc: "_getch", dynlib: "msvcrt.dll".}