MFC程序中使用到打开文件，打包后，自己电脑运行正常，别人电脑显示找不到文件路径
困扰了好久的问题，大哭！
问题现象：写了一个升级软件，其中需要读取升级文件并将其内容写入到设备中，使用VS2015软件编写代码，使用VS2017打包工具打包后，在自己电脑上测试可以正常使用。找到旁边win7 64bits中测试可以正常升级。win10 64bits server2012R2 64bits系统同样可以使用。以为万事大吉！无意中win7 32bits电脑测试一下，软件正常运行。但发现无法升级，win8.1 64bits同样出现此问题。打log分析，无法打开升级文件。
代码定位到此句：f=fopen(path,'rb+'); f=NULL;
打log，path显示出的内容竟然都是对的，但就是f=null；百思不得其解
问题分析：
心路1：以为是软件编写使用vs2015，但打包使用的VS2017版本太高导致的此问题。引出这个原因主要因为使用VS2017打开软件后，一些项目属性的设置会提示是否更改为2017默认的值，点击是的话，会导致没有问题的代码报错。缺少package生成包什么的....
尝试方法：安装了vs2015的installshield的工具，打包后，满怀期待的放到测试机器上发现，照样打不开路径，唉，看来不能怪机器了，肯定是代码的原因了。
心路2：难不成getcwd函数的问题？这个函数应该没有问题吧，尝试使用GetModuleFileName
结果2：问题仍在。
新路3：char *gPath=path[256]
OpenHexFile(path)
本来参数传递的是数组名，后来将参数改为gPath:OpenHexFile(gPath)
发现：单步调试的时候发现传递到这里的指针值不正确，但使用数组的值是正确的。但代码中没有对指针作修改。
找不到修改的地方，但指针值就是不正确。
解决方法：干脆就将获得文件的路径放到打开文件前一句，最终解决，在win10/win8 32bits系统中可以正常运行。
分析：应该是指针在某个地方修改了，这个应该好好研究下指针的使用
新路4：以为上述方式将此问题解决了，然而...，在win8.1 32系统中测试时此问题仍存在。简直要疯了！
解决方法：开始将文件的路径打log分析，发现，setup.exe选择了默认的安装路径，C\Program files(x86)\...系统文件夹；桌面产生了快捷方式。双击桌面的快捷方式启动文件。代码中使用getcwd()获得文件的路径名，发现获得的文件名为空（NULL）。大跌眼镜，什么情况？？？
随后打印文件的log,getcwd()获得的文件路径为文件快捷方式存在的路径，即桌面的路径，由于桌面没有升级文件，肯定打开失败；将升级文件拷贝到桌面后，可以实现正常升级。使用GetModuleFileName()时发现，此时打印的log为安装路径中exe的绝对路径，也是升级文件中存放的位置。虽然地址正确，但仍打开文件失败。
到此可以简单总结下：win8.1 32bits系统中，getcwd()获得了快捷方式所在的路径；GetModuleFileName()获得exe所在的真正路径。
冥思苦想，怎么回事？怎么回事？
最终解决方法：由于系统默认的安装路径在C盘中，当前系统使用的账户不是管理员账户，没有权限到C\Program files(x86)中读取到升级文件，故无法升级。若提示用户不安装在此路径下或者运行此软件在管理员账户下，就不会出现此问题。
目前我出现的问题是此种原因导致。