请教STOCKFUNC转为64位使用的问题

羊洋

我原来使用STOCKFUNC的32位，正常编译且在PEL内正确运行的，由于开始使用参数优化功能需要更多内存，所以需要换成64位，但发现编译成64位，PEL无法正常调用DLL。

具体步骤：
1、我使用VS2019打开官方范例的DSP文件（因为VS2019是最后一个支持读取官方范例中的DSP格式的版本），按照提示升级版本后，编译提示错误是“/Zl和/Gy-”命令行选项不兼容，我就在STOCKFUNC的属性设置”C/C++——代码生成——启用函数级链接否（/Gy-)“改为”是（/Gy)“。然后原错误消除，新的错误是”C2338，windows headers require the default packing option", 我就在STOCKFUNC的属性设置”C/C++——代码生成——结构成员对齐1字节（/Zp1)“改为”默认设置“，于是正常编译32位通过。

2、我在32位金字塔，新建一个序列模式的PEL公式，里面只有一行：AA:"STOCKFUNC@MYMACLOSE"(10);，就是使用官方的MYMACLOSE函数，来计算10日均线，一切正常。

3、我点VS2019上的 Debug x86框，点击打开配置管理器，在“活动解决方案平台”下拉x86，然后选择“键入或选择新平台”，我选了x64，下面的框我是“选择从此处复制设置x86”及“创建新的项目平台”
（具体可以见2张截图）

4、继续在这个64位环境编译，是第3张图的编译信息，“若要更正此问题，请确保 $(OutDir)、$(TargetName) 和 $(TargetExt) 属性值与 %(Link.OutputFile) 中指定的值匹配。”，其实还是会产生DLL的，只不过是在原来32位的debug目录出现，并没有在64位的debug目录出现。但我还是Stockfunc属性——配置——链接器——常规——输出文件，原来是“.\Debug\StockFunc.dll”，我现在拉右边框，改为“从父级或项目默认设置继承”。
这时候，编译就没有什么错误信息了（见第4张图）。

5、我把新生成的64位DLL拷贝到64位金字塔里面，新建一个序列模式的PEL公式，里面只有一行：AA:"STOCKFUNC@MYMACLOSE"(10);，就是使用官方的MYMACLOSE函数，来计算10日均线。
可是这时候，PEL公式就不正常了。
调用我写的PEL公式，就是把公式名字加载了，但是没有均线显示。但是32位版本上的同样方法，是正常的。

想问下这应该如何解决？

羊洋

我刚才在VS2019里面，使用创建向导，创建一个新的DLL项目（名字就叫DLLCHECK1），向导是自动生成了一个dllmain.cpp和pch.cpp及对应的.h默认文件，我把这4个官方生成的文件排除掉，然后将StockFunc的4个文件加入到新项目中。

编译时候说找不到pch.h，我就在配置——C++——创建预编译头和使用stdafx.h，于是编译一点错误都没有，直接生成了DLLCHECK1.DLL，我拷贝到金字塔32位，继续使用那个MYMACLOSE的函数，使用正常。
说明是DLL生成大概是没问题的。

因为是官方生成的环境，上面的debug 右边本来就有x86和x64可选。我选了x64，也遇到找不到pch.h的错误，按上面方法也修改了，于是很正常的生成64位DLL，什么错误都没有。

但是我把新的64位DLLCHECK1.DLL拷贝得到64位金字塔后，还是和以前的错误一样，什么提示都没有，就是没反应。

我试着把32位的DLL拷贝到64位金字塔环境，金字塔会提示，加载DLL出错，错误代码126。那就是说明64位金字塔是在加载DLL的，但是为什么无法加载64位的DLL呢？

技术015

使用Depends工具检查你的64位的DLL是否有依赖其他的DLL库计算机上没有

羊洋

一些很玄学的问题又出来，我自己尝试在VS生成一个缺省值的DLL项目，按照前面说的方式去生成DLL（32位）的，又无法正常加载到32位金字塔了，报错126.

我现在只能复现做到在官方项目上，编译出32位的STOCKFUNC.DLL，运行正常，但是编译成64位，金字塔就不认了

然后我用depends来看，其实32位DLL（API开头和EXT开头的DLL找不到），其他开启看都没什么错。  分析64位DLL，也是API和EXT开头的DLL找不到，其他也没看出什么问题。

好玄学的问题，不知是否可以就给一个能编译使用的版本，直接可以使用啊？

羊洋

刚才很无奈，我尝试把STOCKFUNC改用逐K模式写法，函数就是官方给的那个，没有修改。PEL里面的语句是  AA：“STOCKFUNC@MYMACLOSE”（CLOSE，60）;

32位下依然编译和运行正常。

64位下，逐K模式，在图形上居然出现了“AA”，但AA的值一直是0。

原来代码是：
if(pData->m_pfParam1 && pData->m_pfParam2)
{
*pData->m_pResultBuf = fAdd / dwCyc;
}

羊洋

原来代码是：
if(pData->m_pfParam1 && pData->m_pfParam2)
{
*pData->m_pResultBuf = fAdd / dwCyc;
}
return 1；
上面这个写法，就能在图上出现“AA”，但值一直是0


然后，我在return 1前加入一行，想修改下返回值，看看什么情况
if(pData->m_pfParam1 && pData->m_pfParam2)
{
*pData->m_pResultBuf = fAdd / dwCyc;
}
*pData->m_pResultBuf = 5;
return 1；

这时候，加载到图上，就AA都不显示了。

这好像说明，金字塔是加载了64位的DLL的，逐K模式下有点反应，但是不知道反应是什么。而序列模式下则是完全没有反应。

技术008

逐k和序列，这个返回值要求不一样的

羊洋

谢谢解答。
其实我之前一直都有用STOCKFUNC来写代码的，在32位上写，各种数据调用和输出都是正常的。我是知道这些区别。

我现在的问题，就是我对官方代码一行都没有修改，用最原始的序列模式，32位都运行正常。一编译到64位就不正常，我也不知道该怎么调整啊。
我现在怀疑，是不是VS里面的一些字节对齐的设置，32位里面正常，但是到了64位就开始异常。所以调整金字塔的源代码是找不出原因的，可能是VS的某些设置问题。

但是VS设置实在太玄学，超出大多数人能力了。能否给一个官方编译好的64位开发环境，我直接在上面改就可以了啊？

羊洋

十分感谢技术人员的耐心解答。我用VS2022和2019，发现64位编译出来，怎么样都无法在64位金字塔运作。

我就请教技术人员，技术人员很耐心的了解了我的开发环境，以及看了我如何编译的过程。还和我一起打印调试DLL的具体运作情况，发现64位DLL能正常调用，但是读入的参数和预期不一样（32位是符合预期的），加上VS环境设置中有修改字节对齐的内容，就怀疑是这问题。但解决这问题已经超出我的技术能力。

后来技术人员修改了官方项目的头文件，改了一些字节对齐的方式，终于使得64位编译通过并能够运行了。

十分感谢金字塔技术人员的帮助！