H
hector santos
Guest
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
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:
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:
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, CTO Santronics Software, Inc. Santronics Software, Inc.
Continue reading...
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
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:
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:
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, CTO Santronics Software, Inc. Santronics Software, Inc.
Continue reading...