一般生产问题：调试信息，基本位置，清单和代码证书 [英] General production questions: Debug info, Base Location, Manifest and code certificates
问题描述
我有一些一般性的问题。通过新的64位制作，我正抓住机会改变一些事情并探索其他从未真正考虑过的事情。 希望其他想要回到MS折叠的长期MS开发者有类似的
兴趣并且可以从这次讨论中学习。
一些 背景：
多年（自VS98以来），发布我的产品的构建完成了调试信息，以帮助任何客户报告。 从VS2015开始，我添加了 a"Release_v140_xp" 。结构 使用Release PostBuild批处理文件
为每个项目（超过125），我保留二进制图像，Libs，Dlls，Exe和符号的东西，* .MAP，* .PDB，* .COD， * .AN机器文件夹中的ASCII由版本和构建分隔。 我很少遇到有关客户GPF报告等的问题，实际上，这不是
可跟踪的， 对于一组选定的图像， 我设置了基本位置，这有助于多年来确定问题区域。
I have some general questions. With a new 64 bit production, I'm taking the opportunity the change a few things and explore others never really considered. Hopefully other long time MS developers who want to come back into the MS fold have similar
interest and can learn from this discussion.
Some Background:
For many years (since VS98), the release build of my product was done with debug information to help with any customer reports. Starting with VS2015, I added the a "Release_v140_xp" configuration. Using Release PostBuild batch files
for each project (over 125), I kept the binary images, Libs, Dlls, Exe and symbolic stuff, *.MAP, *.PDB, *.COD, the *.ASM in LAN machine folders separated by versions and builds. I rarely had an issue regarding customer GPF reports, etc, that wasn't
traceable, in fact, for a selected set of images, I set the Base Location which greatly assisted in pinpointed the problem areas over years.
--------------------------------------
IMAGE BASE LOCATIONS FOR WILDCAT!
--------------------------------------
Server
------
wsmw.dll 0x08000000
wsgate.dll 0x08100000
Clients
-------
wcsrv.dll 0x08000000
wcsmw.dll 0x08100000
wcsgate.dll 0x08200000
wccore.dll 0x08300000
wccomm.dll 0x08400000
wcomodem.dll 0x08500000
wcotelnt.dll 0x08600000
wcoftp.dll 0x08700000
wcguiagt.dll 0x08800000
wcotapi.dll 0x08900000
wcohttp.dll 0x08a00000
wchttps.dll 0x08b00000
wcsock32.dll 0x08c00000
wcopop3.dll 0x08d00000
mkwsrv.dll 0x08e00000
mimelib.dll 0x08f00000 我也从不使用Manifest和Code证书。
现在，我处于64位领域并且还考虑了非xp编译， 我有新的考虑因素。
I also never used Manifest and Code certificates.
Now, that I am in the 64 bit realm and also with non-xp compile consideration, I have new considerations.
发布图片调试信息和基本位置：
Release Images Debugging Info and Base Locations:
问题＃1， 更多的确认，我仍然可以使用基本位置，但使用64位注意事项？ 它们是什么？
$
我相信今天我可能不再需要它了。多年来，该产品稳定可靠，如果有任何客户GPF报告，其小型转储文件和调试信息保留在图像中，只需放大问题
区域就足够了  但我可能会删除它们，因为它们可能被视为具有"已知记忆"的安全风险。坏人定位的基地位置。 但是将调试信息保存在图像中仍然是个好主意吗？
或者单独的* .PDB可用吗？ 用户的WER设置是否需要PDB文件来创建迷你转储？
清单文件：
$
我从未使用过Manifest Files。 当他们第一次出来时，我 想想VS2003 / vs2005版本，由于Manifest和DLL"From Hell"而我跳过了这个版本。在我看来，MS很糟糕，"失去了"在这个清单文件和
OS DLL不匹配相关问题的时代。 我对Manifest文件的理解对此有所帮助，并且还有助于GUI外观和感觉相关的东西。  但它也引发了开发人员的问题，而且我记得，随着VS2010的推出，MS终于通过推广"更好的VS98"来带回
。让开发人员重新控制他们的发行版，如果出现问题，Manifest就会减少。 但总的来说，我从来没有想过这样的开销，并且在2000年代期间保持VS98编译
直到vs2010出来。 ;
我们需要它们，嵌入式还是分开式？ 我可以安全地禁用它们吗？ 我今天为什么要考虑它们？
代码证书：
Question #1, more of a confirmation, can I still use Base Locations, but use 64 bit considerations? What are they?
I believe today I may not need them any more. For a number of years, the product was solid and stable and if there were any customer GPF reports, with their mini dump files and the debug info kept in the image, it has been sufficient to zoom in on the problem
areas. But I probably will remove them since they might be viewed as a security risk today with having "known memory" base locations for bad guys to target. But keeping the debug information in the images, is that still good idea?
Or is having the separate *.PDB available sufficient? Does the user's WER setup need the PDB files to create the mini dumps?
Manifest Files:
I never used Manifest Files. When they first came out, I think with the VS2003/vs2005 versions, which I skipped because of the Manifest and DLL "From Hell" mess, MS was, in my opinion, "lost" in this era of manifest files and
OS DLL mismatch related issues. My understanding Manifest files helped with that and also with helping with GUI look and feel related stuff. But it caused issues with developers also and as I recall, with VS2010, MS finally brought t back
to earth with the promotion of a "Better VS98" to give developers back control in their distribution and the Manifest was less if an issue. But overall, I didn't never wanted the overhead and stayed with VS98 compiles during the 2000s
until vs2010 come out.
Do we need them, embedded or separate? Can I safely disable them? Why would I consider them today?
Code Certificates:
最后，代码证书。 让我首先注意一个意见，如果你不关心它，你可以跳过。 < opinion>我认为，由于以下简单原因，MS迫使开发人员向第三方CA（证书颁发机构）支付他们的
软件产品，这在道德上是错误的; 1）向他们从未见过的产品支付第三方CA是没有意义的。第三方CA不是"信任"的。您的代码，因为他们看到或使用了您的代码。 他们是"信任"的。
因为我付钱给它担保，2） 如果客户一直在使用我的产品5,10,15， 他们已经安装了20多年，维护它甚至编程等等，当新的操作系统现在为客户提供"建议"时，为什么他们不再相信它呢？它不是"安全的"。 如果产品已经安装，则客户已经列出了"白名单"。他们通过防火墙弹出窗口，为什么操作系统仍然建议他们没有签名并且
不能被信任？ 如果我可以提出建议，可以表达一个问题：MS应该在这里审查他们的政策。 MS应该是可信证书颁发机构（CA），而不是第三方CA. 毕竟，代码在Microsoft操作系统上运行。 如果
，MS开发者已经支付了VS PRO或MSDN，就像我2015年那样， 该软件包应具有Microsoft Code Certification功能，其中操作系统将执行"信任链"。回到MS，特别是在我的产品没有更改
的操作系统更新期间，操作系统确实如此。但是，操作系统不会列出已安装的产品和应用程序。 它至少应该提示用户"您希望白名单/信任已安装的程序/应用程序吗？"或类似
的东西，带有已安装应用程序的复选框列表。 是的，它是奇怪的并且是一个额外的复杂功能，但操作系统不再信任安装和使用的东西是奇怪的和错误的并且必须支付第三方更奇怪和道德，道德
错误。< /意见>
所以说的是，我 从来没有使用过代码证书，但是今天，以营销的名义，因为它与安全无关，我可能需要考虑它并担心"道德规范"。另一次。 我的问题是，当有125个exe，dll时，如何完成
？ 这可以在每个DLL和EXE或选定的DLL的Post Build Batch文件中完成吗？我是否需要每个代码证书？ 我可以使用全球证书吗？ 或者这是与CA相关的问题吗？ 它是否具有自签名的
与CA签名的概念（如浏览器SSL证书），操作系统将在其中说"这是自签名的。 不可信任？" 它是否也有过期日期概念？ 如果客户打电话给我，请说"嘿，所有突然的Windows都在说Wildcat！"这将是一个难以接受的问题。可以更长久地被信任。为什么&NBSP？;是否有病毒或什么？"
$
总的来说，我的新64位和非XP工作，我正试图"赶上"无论新的"微软VS规范"是什么适用于Windows Oses的限制。 通常情况下，我每5年升级一次VS，因此2020年将成为下一个。 但今天，
我需要使用VS2015设置新作品。
谢谢，您的意见将非常感谢。
$
Finally, code certificates. Let me first note an opinion which you can skip if you don't care for it. <opinion> I believe it is morally wrong for MS to force developers to pay a 3rd party CA (Certificate Authority) to vouch for their
software product for the following simple reasons; 1) It makes no sense to pay a 3rd party CA for a product they never saw. The 3rd party CA are not "trusting" your code because they saw or use your code. They are "trusting"
it because I paid them to vouch for it, and 2) If customers has been using my product for 5, 10, 15, 20+ years where they have installed it, maintained it and even programmed it, etc, why should they no longer trust it when the newer OSes now
give the customer a "suggestion" that it is not "secured?." If the product is already installed, the customer has "white listed" them via the Firewall popups, why is the OS still suggesting they were not signed and
can't be trusted? It is OK to express a concern if I can make a suggestion: MS should review their policy here. MS should be the Trusted Certificate Authority (CA), not a 3rd party CA. After all, the code is running on Microsoft OSes. If
a MS developer has paid for VS PRO or the MSDN like I have in 2015, the package should come with Microsoft Code Certification capabilities where the OS will do the "trust chain" back to MS, especially during an OS update where my product has
not changed, the OS did. Yet, the OS doesn't white list the products and applications that are already installed. It should at least prompt the user "Do you wish to white list/trust the programs/applications already installed?" or something
like that with a checkbox list of installed applications. Yes, it is odd and an extra complication, but the OS no longer trusting what is installed and used is odd and wrong and having to paid a 3rd party is even more odd and ethically, morally
wrong.</opinion>
So with that said, I never used code certificates, but today, in the name of Marketing because it has nothing to do with Security, I perhaps need to consider it and worry about the "ethics" another time. My question is how is it
done when there are 125 exe, dlls? Can this be done in a Post Build Batch file for each DLL and EXE or selected ones? Do I need to Code Cert each one? Can I use a global certificate? Or is that a CA related issue? Does it have a Self-signed
vs CA signed concept like a browser SSL cert, where the OS is going to say "This is self-signed. Can't be trusted?" Does it have an expiration date concept too? That will be a tough one to swallow for have customers call me
to say "Hey, all of the sudden Windows is saying Wildcat! can longer be trusted. Why? Is there are virus or something?"
Overall, with my new 64 bit and non-XP work, I am trying to "catch up" to whatever is the new "Microsoft VS norm" is for Windows Oses to a limit. Normally, I upgrade VS every 5 years, so 2020 will be the next one. But today,
I need to set up the new production with VS2015.
Thanks and your input would be greatly appreciated.
Hector Santos，Santronics Software，Inc。首席技术官http://www.santronics.com
Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com
推荐答案
我只会去对应用程序清单做出回应。另外两点是我不需要定期处理的事情。 ASLR尤其如此。
I'm only going to respond in regards to the application manifests. The other two points are things that I don't really have to deal with on a regular basis. This is especially true with ASLR.
应用程序清单始终在构建期间生成并默认嵌入。 Windows使用应用程序清单来确定是否应将32位应用程序视为遗留应用程序，并且可用于启用可选功能。
Application manifests are always generated during a build and embedded by default. Windows uses the application manifest to determine whether a 32 bit application should be treated as a legacy application and can be used to enable optional features.
例如，应用程序清单是您定义的位置该应用程序与Windows 7,8,8.1和10兼容，这将禁用这些应用程序的兼容性行为。如果您想选择高DPI感知，长路径能力和
以上，
申请
manifest 这些设置的结束位置。
For example, the application manifest is where you define that the application is Windows 7, 8, 8.1 and 10 compatible, and this will disable compatibility behaviour for these applications. If you want to opt into high DPI awareness, long path capable and more, the application manifest is where these settings end up.
虽然可以通过编程方式启用某些功能，但并非一切都可以。
While some things can be enabled programatically, not everything can.
Manifest文件在今天使用得非常广泛，只是不是因为你似乎有不好的回忆。
Manifest files are very widely used even today, just not for the things that you seem to have bad memories about.
这篇关于一般生产问题：调试信息，基本位置，清单和代码证书的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
