微软 C 编译器的非常古老的实现提供的函数使用的名称与 POSIX/UNIX 世界中的名称相同和/或侵犯了用户的命名空间。请注意，其中一些是“侵权”，可能是在标准化发生之前（在 MS-DOS 时代）。
很久以前，Microsoft 决定将这些名称移动到为编译器实现保留的一组名称中。他们为图书馆里的许多名字都这样做了，即使严格来说他们可能不必这样做。似乎他们对所有非标准 C/C++ 的库名称都这样做了。请注意，这不适用于 SDK 中的名称 - 该组头文件和库位于编译器实现域之外，即使 SDK 与编译器一起分发也是如此。
为了与使用旧名称（没有下划线的程序）编写的程序兼容，Microsoft 提供了一个库 oldnames.lib，它实现了将旧名称（例如getch）链接到新名称 ( _getch) 的别名。这两个名称指的是完全相同的代码。因此，就使工作正常而言，您可以使用任一名称（尽管您可能需要设置您的项目以链接到oldnames.lib）。
如果您有使用旧名称的旧 Windows 代码，我认为最好只是链接oldnames.lib并完成。
对于新代码，我认为使用新名称（带下划线且不链接 oldnames.lib）可能会稍微好一些。旧名称已被 Microsoft 弃用，其他一切都相同的情况下，这可能会影响天平。而且，如果您最终将代码移植到 POSIX 系统或将 POSIX 代码移植到 Windows，则更有可能会提醒您注意可能需要注意的区域。这些函数可能看起来和大部分行为都类似于 POSIX 版本，但它们可能需要以稍微不同的方式使用 - 特别是在错误处理中。
或者，您可以尝试使用 PDCurses 之类的库，或者使用您自己的包装器来提供可移植性，具体取决于对您而言价值多少。或者，如果您真的希望在 Windows 上具有 POSIX 可移植性，Cygwin 可能是一种选择（Unix 服务仍然存在吗？）。
MSVC 和 POSIX 函数具有相同/相似名称的细微差别的一些示例：
getch()在 Windows 上永远不会回显字符，总是阻塞直到有输入，需要多次调用才能读取某些键，并且不能返回错误。这些行为与 POSIX 不同。
ungetch()在 Windows 上返回传入或EOF出错的字符。在 POSIX 上，它返回OKor ERR。