继续用cl呗
【 在 saynothing 的大作中提到: 】
: 十年前用过cl.exe和link.exe，现在msvc 2013/2017编译，都看不到编译命令。 都改成了msbuild
: 基于一个sdk，要编译各种变种版本，手动创工程嫌麻烦。 还是喜欢命令行那套（cygwin + makefile + 命令），不知道是否行得通。
: 望 各位大拿指点一二
: ...................
--
FROM 116.227.75.*

MSVC 里面带的 make 叫做 nmake

【 在 saynothing 的大作中提到: 】
: 十年前用过cl.exe和link.exe，现在msvc 2013/2017编译，都看不到编译命令。 都改成了msbuild
: 基于一个sdk，要编译各种变种版本，手动创工程嫌麻烦。 还是喜欢命令行那套（cygwin + makefile + 命令），不知道是否行得通。
: 望 各位大拿指点一二
: ...................
--
FROM 223.104.3.*

嗯嗯，那个sdk用纯c写的。低版本的64位上编译，比如win7，能在win8、win10上跑起来吗？

windows整不太明白，同样win7编译的binary拷贝到另外一台机器上就是不能运行（整个debug目录拷）。  早期低版本的vc6程序，xp下编译，win7/win10都能运行


【 在 javaboy 的大作中提到: 】
: 我就是只用cl + link，用一个windows版的make来调用。
: 用msbuild必须安装一个巨大的20gb的visual studio。。。而且不同版本不是很兼容，不是很友好。。。
:
--
FROM 112.17.247.*

跑不起来总会报些错误吧？
理论上说win7.8.10 区别不大，程序都可以运行的。
如果不能运行，99.999%的可能是你程序写的有问题。
【 在 saynothing 的大作中提到: 】
: 嗯嗯，那个sdk用纯c写的。低版本的64位上编译，比如win7，能在win8、win10上跑起来吗？
: windows整不太明白，同样win7编译的binary拷贝到另外一台机器上就是不能运行（整个debug目录拷）。  早期低版本的vc6程序，xp下编译，win7/win10都能运行
:
: ...................
--
FROM 223.104.3.*

默认是动态连接的，debug版本也是动态链接到debug版的msvcp*.dll之类的，目标环境缺这些dll肯定运行不了。

你可以改成静态链接的，就没这个问题。或者在目标环境上安装对应版本的VC++ redistributable package。

编译产物要在XP上运行，需要用xp toolset编译。默认安装的VC++ toolset是不支持目标环境为XP的。
不需要支持XP的话，无视这个好了。

某个OS API或者某个feature是否能跨win7/win8/win10，得具体分析了。

既然是特定于win平台，用*.sln工程是没啥问题的。
愿意用cmake也行，不过cmake针对visual studio上也是生成*.sln。

【 在 saynothing 的大作中提到: 】
: 嗯嗯，那个sdk用纯c写的。低版本的64位上编译，比如win7，能在win8、win10上跑起来吗？
: windows整不太明白，同样win7编译的binary拷贝到另外一台机器上就是不能运行（整个debug目录拷）。  早期低版本的vc6程序，xp下编译，win7/win10都能运行
:
: ...................
--
修改:z16166 FROM 221.220.169.*
FROM 221.220.169.*