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

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
> 

== 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).

As for point #1 (startup performance), I seem to have narrowed
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

== 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

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.

== 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