www.digitalmars.com         C & C++   DMDScript  

c++ - A couple of questions about win32 executables

reply Erik Weber <my_name_here mindspring.com> writes:
I have the full version of Mars Compiler. So far all I have used
are dmc and rcc on the command line. I have created a few
executables that contain resources such as bitmaps and wave files.
I do not use any MFC, no menus, etc., all just pure GDI, and in
some programs DirectX. I also am not using any IO other than cout.

Two questions:

1) How do I optimize the startup time of my executable? I mean the
amount of time it takes to get a window visible on a cold start. I
have noticed that having something in the prefetch directory
doesn't *seem* to make a difference. I usually get a cold start
unless I have been running the program frequently.

For example, I have an executable that is around 8 MB on disk.
About 7 MB of that is bitmaps. In WinMain the first thing I do is
create the window with WS_VISIBLE and then call UpdateWindow, then
proceed to initialize DirectX, initialize back buffers and load my
resources. I have noticed that my executable takes a lot longer to
cold start than it did when it was 1 MB. I have noticed though
that I have some installer executables from other programs (ones I
didn't build) that are as big as 80 MB and yet on a cold start (I
mean first time in years) they bring up a window almost instantly.
Maybe because they don't load any resources?

I tried "freeing" the main thread by moving my resource loading to
another thread and then signaling WM_USER when done but it made no
difference. Now, after the cold start, it starts immediately,
until the next cold start. But how are these other programs
achieving such great cold starts even with a giant executable? My
1 MB executable starts immediately even after a fresh compile, and
that's the performance I'm wanting, no matter the size of my
executable.

2) How do you create a "trusted" executable? If I give someone my
executable on a thumb drive it runs as normal. However if the user
downloads it via Internet Explorer, it gets "blocked" (visible and
clearable via "properties" on the icon's right-click menu). When
the user tries to run it, he gets the security warning. But I'll
use my installer program example from before. I download other
executables using IE (typically installers) and they are not
blocked like this. I take it there is some way to "sign" an
executable? If I am correct, how do I do this with Mars Compiler
and also, how does that really make the executable any more secure?

Thanks and sorry for the long post.

Erik
Dec 08 2011
parent reply "Nick Hofstetter" <nhofstetter gfg-group.com> writes:
For point 2, you need to 'Sign' the executables. To do this you will need to
get a Certification Authority (CA) to verfiy who you are and issue you with
a certificate. This is quite expensive. I use a Thawte certificate and this
costs US$495 for 2 years.

Once you have the certificate you would then use dm to generate your
execuatables and just before you ship them, you would need to sign them
using your certificate. You use a Microsoft utility called 'Signtool' to do
this.

Once the file has been signed, then it cannnot be modified without this
being detected and this is the added protecting that Signing code provides.
The executables can not be infected and everyone knows that they came from
you and have not been modified.

Because you have a certificate issued by a major CA anyone will be able to
verify the signature as the Major CA's certificates are part of the Windows
Operating system. You can see them all in Internet Explorer Tools->Internet
Options->Content and press the Certificates button.

But if you only have a small number of customers, you can 'Self Sign' the
code. This would mean that you need to get all of your customers to manually
'Import' your certificate (On the certificates screen) and Windows can use
your certificate to validate the module. This gets around the US$495 fee you
need to pay to get a real certificate from a recognised CA.

"Erik Weber" <my_name_here mindspring.com> wrote in message 
news:jbrfup$hms$1 digitalmars.com...

I have the full version of Mars Compiler. So far all I have used
 are dmc and rcc on the command line. I have created a few
 executables that contain resources such as bitmaps and wave files.
 I do not use any MFC, no menus, etc., all just pure GDI, and in
 some programs DirectX. I also am not using any IO other than cout.

 Two questions:

 1) How do I optimize the startup time of my executable? I mean the
 amount of time it takes to get a window visible on a cold start. I
 have noticed that having something in the prefetch directory
 doesn't *seem* to make a difference. I usually get a cold start
 unless I have been running the program frequently.

 For example, I have an executable that is around 8 MB on disk.
 About 7 MB of that is bitmaps. In WinMain the first thing I do is
 create the window with WS_VISIBLE and then call UpdateWindow, then
 proceed to initialize DirectX, initialize back buffers and load my
 resources. I have noticed that my executable takes a lot longer to
 cold start than it did when it was 1 MB. I have noticed though
 that I have some installer executables from other programs (ones I
 didn't build) that are as big as 80 MB and yet on a cold start (I
 mean first time in years) they bring up a window almost instantly.
 Maybe because they don't load any resources?

 I tried "freeing" the main thread by moving my resource loading to
 another thread and then signaling WM_USER when done but it made no
 difference. Now, after the cold start, it starts immediately,
 until the next cold start. But how are these other programs
 achieving such great cold starts even with a giant executable? My
 1 MB executable starts immediately even after a fresh compile, and
 that's the performance I'm wanting, no matter the size of my
 executable.

 2) How do you create a "trusted" executable? If I give someone my
 executable on a thumb drive it runs as normal. However if the user
 downloads it via Internet Explorer, it gets "blocked" (visible and
 clearable via "properties" on the icon's right-click menu). When
 the user tries to run it, he gets the security warning. But I'll
 use my installer program example from before. I download other
 executables using IE (typically installers) and they are not
 blocked like this. I take it there is some way to "sign" an
 executable? If I am correct, how do I do this with Mars Compiler
 and also, how does that really make the executable any more secure?

 Thanks and sorry for the long post.

 Erik
Dec 11 2011
parent reply Erik Weber <my_name_here mindspring.com> writes:
== Quote from Nick Hofstetter (nhofstetter gfg-group.com)'s article

 For point 2, you need to 'Sign' the executables.


Thanks again Nick. I was forgetting the fact that the user will
still be alerted and forced to make a decision if the certificate
is self-signed. Correct me if I'm wrong, but self-signing seems
like a viable option because as long as you secure and maintain
your private key your executables still cannot be forged. You just
have to convince the users to accept you as a certificate source
instead of a more well-known third party.

I also was wondering if signtool would work (I was looking for a
DM tool) and apparently it does. Seems like something should come
in the DM distro, unless signtool and the like are a free separate
download . . . Otherwise you would be forced to also have some
sort of platform SDK . . . again correct me if I'm wrong. Just so
happens that Visual Studio 8 Express Edition was included with my
OS, and it has signtool.exe from 2005. I'm hoping this will work
once I am able to generate a certificate. I'm wondering if the
tools that come with the Java SDK will generate compatible keys
and certificates since I have those and have created a self-signed
certificate for a Java program before (I do not seem to have
certgen.exe).


this down a bit.

I have an executable that simply brings up a window and starts
blitting text to it with GDI in a loop. There are very few
functions and only a few hundred lines of code. I compile on the
command line in either a VIM shell or Cygwin shell (bash), with no
resources, and -WA and -mn. Then I run with "./my.exe". After a
fresh compile, it starts immediately (what I am calling a cold
start) -- no real discernable difference from subsequent starts
(warm starts).

However, if I simply create a matching resource file, add about 20
bitmaps to it with a total size of about 7 or 8 MB, compile that
with rcc and then recompile my executable to include the resources
(which are never even accessed in the code), the cold startup time
is significantly impacted -- it can take several seconds. Then
subsequent starts are immediate again, until I recompile, or until
I wait maybe a day before running it again.

So I was thinking maybe it was just a product of file size, or
perhaps had something to do with how Windows starts up an
executable with resources packed into it. But then I noticed that
the executable even cold starts quickly when I copy it to a
(mostly empty) portable USB drive and run it from there! So, now
I'm thinking, maybe the slowness on my C drive is perhaps (to my
shame) because my hard drive is darned near full and probably
badly fragmented? I would love to learn the reason for this
because I'm sure it would shed light on how the OS works.

Thanks again,
Erik
Dec 12 2011
next sibling parent Erik Weber <my_name_here mindspring.com> writes:
== Quote from Erik Weber (my_name_here mindspring.com)'s article

 But then I noticed that
 the executable even cold starts quickly when I copy it to a
 (mostly empty) portable USB drive and run it from there!


Just to clarify, I meant run it from the USB drive for the *first
time*. I recompile, then copy the exe to the USB drive, then run
it for the first time from there. (My assumption here is that
every time you recompile, it breaks any caching that Windows might
do on that executable such as what is in the prefetch directory).

So why would an executable (cold) start up faster from a USB drive
then from my hard drive?

Erik
Dec 12 2011
prev sibling parent reply "Nick Hofstetter" <nhofstetter gfg-group.com> writes:
Self Signing protects the exectuable from being changed, You just need to 
get the user to load your certificate. Someone else can also create a 
certificate with your name in it and impersonate you and send an execuatble 
with a virus. The user would need to load the fake certificate but thats the 
advantage of have a real certificate.

As far as I am aware, all the tools necessary to sign code can be downloaded 
for free from the MSDN web site.
Dec 13 2011
parent Erik Weber <my_name_here mindspring.com> writes:
== Quote from Nick Hofstetter (nhofstetter gfg-group.com)'s article

 Self Signing protects the exectuable from being changed, You


just need to

 get the user to load your certificate. Someone else can also


create a

 certificate with your name in it and impersonate you and send an


execuatble

 with a virus. The user would need to load the fake certificate


but thats the

 advantage of have a real certificate.
 As far as I am aware, all the tools necessary to sign code can


be downloaded

 for free from the MSDN web site.


I appreciate it.

Erik
Dec 14 2011