Register all pending file operations

[NewsArchive]

Hi Friedrich,

it seems, I have missunderstood the function "register all pending file
operations". Could you please clarify, under which circumstances I will
need this funtionality?

Thanks in advance.

Markus

[NewsArchive]

Hi Markus,

> it seems, I have missunderstood the function "register all pending file
> operations". Could you please clarify, under which circumstances I will
> need this funtionality?

Let us assume, you install two (OCX) files that support self-registration
and you have the "Register as OCX/DLL/EXE/TLB" option enabled. The
self-registration process is not automatically executed after the file
installed. Instead, it is "queued" and at the end of the installation
process, the "Register all pending file operations" function will execute
the OCX self-registration process.

HTH,
Friedrich

[NewsArchive]

Hi Friedrich,

thanks for your answer. But unfortunately, I have further question.

1.) I have no OCX-Files, just a few self-registering dlls. Is this relevant?

2.) your famous documentation (PDF) says on page 395 (408):
"Queued files are registered automatically at the end of the script."
Why do I need "register all pending file operations" at all?

I will tell you the reason, why I ask all this questions:
Sometimes, "register all pending file operations" causes my Setup to
hang, and I dpn't know why. After a reboot, you can install the
application succesfull. And with our old self-written setup, there was
never be a problem with registering our dlls. Even if one of our dlls
causes this problem, I have no chance to see, which dll it is.

Thanks for your reply and thanks for the new maintenance build. It
solves two major issues in our setup.

Markus

[NewsArchive]

Hi Markus,

>
> 1.) I have no OCX-Files, just a few self-registering dlls. Is this
> relevant?
>

The self-registering OCX file was just an example for a pending file
operation. Pending file operations include self-registration files, shared
files registration, true type font registration, .NET file operations (e.g.
register the file in the GAC), and replace in-use file actions.

If no file operation is "pending", then the function is not executed at all.

BTW, the uninstall .log should display the "last" successful operation.
Perhaps this can help to find out what the next file operation might be.
Please note that the installer just executes the self-registration process
in self-registering DLLs. If the setup "hangs", then the DLL does not
return to the installer (means, there is a problem with the registration
procedure in the DLL).

Friedrich

[NewsArchive]

Hi Friedrich,

thank you for your explanation. This was very helpful.

To know, which last action was successful is not very helpful. The more
interesting thing is, which action just has started.

Perhaps you can wrote this Information in line 2 of the progress bar
screen and ensure, that the repainting is done, before you start the action.

I think about lines like that:
Registering "special.dll"
Registering Font "MyFont.ttf"
Register replace file action for file "iwasinuse.exe"

Or do you see another way to determine, which action fails?

Because there was never a problem in the past, I can't guess which
action might be the evil.

This thing drives me crazy and is very problematic for our customers.

Thanks for your reply.

Markus

[NewsArchive]

Hi Markus,

>
> This thing drives me crazy and is very problematic for our customers.
>

There is a /E command switch that creates a c:\sbevents.txt. This feature
will enhance in the future and I don't know if it covers pending file
operations yet. Could you please start your installer with the /E switch
(e.g. setup.exe /E) and send me the created sbevents? Perhaps this already
gives more information. If not. we'll add some more code so we can see
where it "hangs".

But as far as I know (I checked, re-checked and checked again the release
history), there was no modification in that runtime area.

Friedrich

[NewsArchive]

Hi Friedrich,

I'm sure, it has nothing to do with your new release. I had this issue
already with SB 6.9, but since a few weeks, we ship our main product
with the SB-Setup too and the little problem grows faster as I wish...

I can't reproduce this problem every time and I can't tell every
customer, to start the setup with /e.

Is it possible (in an upcoming release), to activiate sbeventlog.txt
programatically and to set the path to the file and the filename?

Do you close or flush the file after every write access?
If no: How can I be sure, that last line I see in the file is the last
line sb has written?

Thank you, for your support.

Markus

[NewsArchive]

Hi Markus,

> I'm sure, it has nothing to do with your new release. I had this issue
> already with SB 6.9, but since a few weeks, we ship our main product with
> the SB-Setup too and the little problem grows faster as I wish...
>
> I can't reproduce this problem every time and I can't tell every customer,
> to start the setup with /e.
>
> Is it possible (in an upcoming release), to activiate sbeventlog.txt
> programatically and to set the path to the file and the filename?

Yes, it should be possible to add an installer flag to always create the
sbevents.txt.

> Do you close or flush the file after every write access?
> If no: How can I be sure, that last line I see in the file is the last
> line sb has written?

The file is not closed but flushed and accessible, so you should see the
previously written item without any problem.

If it is a self-registering DLL and this process "hangs", then it's
definitely caused by the DLL itself because the call to "DllRegisterServer"
in the DLL never returns. The installer does nothing more (or less) than
calling the "DllRegisterServer" API. The DLL does all the registration
stuff and the installer can't continue until the DLL returns.

Friedrich

[NewsArchive]

Hi Friedrich,

thank you. At the moment, I don't even know, wheter a dll causes the
problem or if there is another queued item, I don't think about.

I will wait until you have added the installer flag (and perhaps to set
the sbeventlog.txt-path too) in a developement build, than we will see,
what's going on.

Thanks again.

Markus

[NewsArchive]

Hi Markus,

> thank you. At the moment, I don't even know, wheter a dll causes the
> problem or if there is another queued item, I don't think about.

Yes, you are right. Perhaps it's not caused by this self-registration DLL
scenario at all.

> I will wait until you have added the installer flag (and perhaps to set
> the sbeventlog.txt-path too) in a developement build, than we will see,
> what's going on.

We'll add some more "events" to the installer runtime to log all possible
pending file situations. This should provide us with more information.

Friedrich

[NewsArchive]

Hi Friedrich,

I can't start my setup with /E. If I do so, it crashes (on some
machines) with a buffer overrun. I think, it's caused by a variable with
more than 1kb contents or by the http post script event.

For more information, please have a look at the attached zip file.

Thanks.

Markus

[NewsArchive]

Hi Markus,

> I can't start my setup with /E. If I do so, it crashes (on some
> machines) with a buffer overrun. I think, it's caused by a variable with
> more than 1kb contents or by the http post script event.

Yes, that's well possible. The debug function has to make use of the
"wsprintf" Windows function which only supports up to 1,024 bytes. In the
past (pre-7.x), the variable size was limited to 1K so this was not a
problem. It increased to 10KB in SB7 and I think we never updated that
debug function. I have added it to the ToDo list.

Thanks,
Friedrich

[NewsArchive]

Hi Markus,

Buffer-overrun fixed. Thank you for bringing this to my attention.

Friedrich

[NewsArchive]

Hi Friedrich,

I just want to bring to your attention to add the installer flag "always
create sbevents.txt" and to add a possibility to change the path where
the sbeventslog will be written.

Do you have an idea, when you will release the next development build?

Thanks for your support in the last few monthes.

Markus

[NewsArchive]

Markus,

> I just want to bring to your attention to add the installer flag "always
> create sbevents.txt" and to add a possibility to change the path where the
> sbeventslog will be written.
>
> Do you have an idea, when you will release the next development build?
>
> Thanks for your support in the last few monthes.

We have already added a new SBEVENTS pragma to compile a setup.exe that
always creates the sbevents.txt log.

But it's not possible to set the target path. It's always created in the
C:\ root or (if this fails) in C:\Users\<User>

A new maintenance build is scheduled to be available by the end of the week.

Friedrich

[NewsArchive]

OK, Thank you, Friedrich.

Markus Zander

[NewsArchive]

Markus,

> We have already added a new SBEVENTS pragma to compile a setup.exe that
> always creates the sbevents.txt log.

FYI: we had to remove the new SBEVENTS pragma (to always create the
sbevents.txt) because it does not work this way. The events logging
functionality has to be initialized in the "stub loader" before the script
engine is started. But the SBEVENTS pragma solution only works at script
engine level. So unfortunately, only the /E command line option can enable
sbevents.txt logging. There is no way to control this from the script.

Friedrich

[NewsArchive]

OK,

I'll do it this way:

Set Variable %CMDLINE% to FUNCTION:Get System Info(Command Line)
If %CMDLINE% Does Not Contain "/E" Then
Set Variable %INSTALLER% to FUNCTION:Get System Info(Installer File
Name)
Set Variable %INSTALLERFILE% to FUNCTION:Extract File(%INSTALLER%)
Set Variable %INSTALLERPATH% to FUNCTION:Extract Full
Folder(%INSTALLER%)
Run Program %INSTALLERPATH%\%INSTALLERFILE% /E %CMDLINE% (Always
Install)
Exit Installation()
End


What do you think?

Markus

[NewsArchive]

>
> What do you think?
>

Good idea!

Friedrich

[NewsArchive]

Hi Friedrich,

if there a multiple instances with /E running at the same time, on
einstance overwrites the entry of the other instance.

Could you make the sbevents filename unique, for example by adding an
upcounting number or a GUID?

Markus

[NewsArchive]

Hi Markus,

> if there a multiple instances with /E running at the same time, on
> einstance overwrites the entry of the other instance.
>
> Could you make the sbevents filename unique, for example by adding an
> upcounting number or a GUID?

Yes, in our internal version, we are already appending a unique GUID to
sbevents.txt.

For example:
sbevents_45BE5140-8FD7-11DF-4823-089F058F0029_.txt

But it was requested to change the GUID into a date/time stamp (to make it
"sortable").

For example:
sbevents_2010:12:31_10:42:35:328_.txt

One of the above solutions (I prefer the latter) will be available in the
next public build.

Friedrich

[NewsArchive]

Hi Friedrich,

this sounds good.

I would suggest the following format:

sbevents_2010-12-31_10:42:35.328_.txt

At least for me, it's more readable than a format with : as delimiter in
the date an before the miliseconds.

But it's your choice. You are the boss :-)

Markus

[NewsArchive]

Hi Markus,

> this sounds good.
>
> I would suggest the following format:
>
> sbevents_2010-12-31_10:42:35.328_.txt
>
> At least for me, it's more readable than a format with : as delimiter in
> the date an before the miliseconds.
>
> But it's your choice. You are the boss :-)

<G>

I like your "sbevents_2010-12-31_10:42:35.328_.txt" format suggestion.

Thanks,
Friedrich

[NewsArchive]

I suggest you do not use that format for the TIME portion...

Windows file names have certain reserved characters.

From the MSDN site...

The following reserved characters:

< (less than)
> (greater than)
: (colon)
" (double quote)
/ (forward slash)
\ (backslash)
| (vertical bar or pipe)
? (question mark)
* (asterisk)

John Griffiths

[NewsArchive]

Hi Friedrich,

is the format

"sbevents_2010-12-31_10-42-35.328.txt"

already implemented?

Markus

[NewsArchive]

Hi Markus,

> is the format
>
> "sbevents_2010-12-31_10-42-35.328.txt"
>
> already implemented?

We have the following in the 7.3 history log:

----
IMPROVEMENT: Add new /E1 and /E2 event logging mode command line options to
create an unique sbevents_GUID.txt logging file name (/E1) or
set the name of the event logging file (/E2 "filename").
----

Friedrich

[NewsArchive]

Hi Friedrich,

yesterday, thew first customer sends back the sbevents log.

This are the last few lines, before the setup hangs:

|10/20/2010|16:37:50:223|Set Variable %PATH% to C:\Programme\Gemeinsame
Dateien\AIDASQL\bin\;C:\WINDOWS\system32;C:\WINDOW S;C:\WINDOWS\System32\Wbem;C:\Programme\Microsoft
SQL Server\80\Tools\Binn\;C:\Programme\Microsoft SQL
Server\90\Tools\binn\;C:\Programme\Microsoft SQL
Server\90\DTS\Binn\;C:\Programme\Microsoft SQL
Server\90\Tools\Binn\VSShell\Common7\IDE\;C:\Progr amme\Microsoft Visual
Studio 8\Common7\IDE\PrivateAssemblies\
|10/20/2010|16:37:50:223|@SETVARIABLE
|10/20/2010|16:37:50:223|Set Variable %PATH% to C:\Dokumente und
Einstellungen\Administrator.OBFELD\Lokale
Einstellungen\Temp\09589fa0-dc56-11df-4823-3cf8bd380029;C:\Programme\Gemeinsame
Dateien\AIDASQL\bin\;C:\WINDOWS\system32;C:\WINDOW S;C:\WINDOWS\System32\Wbem;C:\Programme\Microsoft
SQL Server\80\Tools\Binn\;C:\Programme\Microsoft SQL
Server\90\Tools\binn\;C:\Programme\Microsoft SQL
Server\90\DTS\Binn\;C:\Programme\Microsoft SQL
Server\90\Tools\Binn\VSShell\Common7\IDE\;C:\Progr amme\Microsoft Visual
Studio 8\Common7\IDE\PrivateAssemblies\
|10/20/2010|16:37:50:223|@CALLDLL kernel32.dll : SetEnvironmentVariable
|10/20/2010|16:37:50:223|Set Variable %_SB_RETURN% to 1
|10/20/2010|16:37:50:254|ProcessSpecialActions: 2 :
C:\WINDOWS\Fonts\ITFCTT.TTF : Interleaved2of5C

And now?

Markus

[NewsArchive]

Good news. Thank you.

Markus Zander

[NewsArchive]

Hi Markus,

The installer tries to register the font "C:\WINDOWS\Fonts\ITFCTT.TTF", but
the call to the AddFontResource and/or SendMessage Windows APIs do not
return.

Friedrich

[NewsArchive]

Hi Friedrich,

now I have several logfiles. All stop with the same line

ProcessSpecialActions: 2 : C:\WINDOWS\Fonts\ITFCTT.TTF : Interleaved2of5C

We have to found the reason. What exactly are you doing after you wrote
this line and before your write the next line?

Perhaps you could add more logging information and post (or mail) the
involved source snippet from sb.

Thanks for your help.

Markus

[NewsArchive]

Hi Markus,

> now I have several logfiles. All stop with the same line
>
> ProcessSpecialActions: 2 : C:\WINDOWS\Fonts\ITFCTT.TTF : Interleaved2of5C
>
> We have to found the reason. What exactly are you doing after you wrote
> this line and before your write the next line?
>
> Perhaps you could add more logging information and post (or mail) the
> involved source snippet from sb.
>
> Thanks for your help.

There are two additional Windows API calls:

1. AddFontResource
2. SendMessage (to broadcast the font change)

One of the above API (IMO, it's SendMessage) do not return in your case.

http://msdn.microsoft.com/en-us/library/dd145211(VS.85).aspx

Friedrich

[NewsArchive]

Hi Friedrich,

in this case, you could use "SendNotifyMessage" (at least on W2000 or
newer systems) to solve the problem.

http://msdn.microsoft.com/en-us/library/ms644953(v=VS.85).aspx

Markus

[NewsArchive]

Hi Markus,

> in this case, you could use "SendNotifyMessage" (at least on W2000 or
> newer systems) to solve the problem.
>
> http://msdn.microsoft.com/en-us/library/ms644953(v=VS.85).aspx

Yes, but the problem is that (as far as I can see) Microsoft recommends the
use of SendMessage. We are using the very same runtime RegisterFont
function for 10+ years now (last source code modification is dated
FEB-2000).

http://msdn.microsoft.com/en-us/library/dd145211(VS.85).aspx

I don't know if there are any negative side-effects involved when switching
to "SendNotifyMessage". There are quite a few million SetupBuilder projects
out there and it's always somewhat risky to change APIs <g>. I remember a
similar case more than two years ago (IIRC, in June 2008).

I found a few messages where SendMessage caused such a "dead-lock"

http://www.go4answers.com/Example/programmatically-deleting-fonts-windows-170673.aspx

We'll have to investigate if it is safe to use "SendNotifyMessage" here.

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder is Windows 7 installation -- "point. click. ship"

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

> Yes, but the problem is that (as far as I can see) Microsoft recommends the
> use of SendMessage. We are using the very same runtime RegisterFont
> function for 10+ years now (last source code modification is dated
> FEB-2000).
>
> http://msdn.microsoft.com/en-us/library/dd145211(VS.85).aspx

SendMessage() will wait for the window to process the message. Same with
SendNotifyMessage if it is on the same thread. PostMessage() OTOH will
return immediately to the caller. I don't know if PostMessage() would be
appropriate but as far as I can tell it should not be possible for it to
dead-lock as it is always supposed to return immediately
(http://msdn.microsoft.com/en-us/library/ms644944(v=VS.85).aspx)

I have used PostMessage() in cases where I just wanted to post the message
and didn't care when the receiving window processed it. I would _think_
that PostMessage() would work just as well with wm_fontchange as
SendMessage() except that the calling window should not risk dead-lock if
one of the top windows isn't able to process the message for whatever
reason.

Best regards,

--
Arnór Baldvinsson - Icetips Alta LLC
Port Angeles, Washington
www.icetips.com - www.buildautomator.com - www.altawebworks.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Arnór,

PostMessage is problematic in this case because it returns before Windows
has processed the message and added or released the font to/from the font
cache. One solution to overcome this PostMessage problem would be to "wait
a few seconds" before continuing the process. Whatever a few seconds means
here.

There are three possible options:

1.) Leave it as it is with SendMessage (recommended by Microsoft)
2.) Switch to SendNotifyMessage (might, or might not help).
3.) Switch to PostMessage (and wait "a few seconds").

Perhaps I'll add an option so the developer can decide what to do <g> I
think we'll go with option 3.)

Friedrich

[NewsArchive]

Hi Friedrich,

> PostMessage is problematic in this case because it returns before Windows
> has processed the message and added or released the font to/from the font
> cache. One solution to overcome this PostMessage problem would be to "wait
> a few seconds" before continuing the process. Whatever a few seconds means
> here.

<g> I figured there could be some issues with the font notification. Just
thought I'd mention it:)

Best regards,

--
Arnór Baldvinsson - Icetips Alta LLC
Port Angeles, Washington
www.icetips.com - www.buildautomator.com - www.altawebworks.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Friedrich,

> Perhaps I'll add an option so the developer can decide what to do<g> I
> think we'll go with option 3.)

Some news about this?

Markus

[NewsArchive]

Hi Markus,

> > Perhaps I'll add an option so the developer can decide what to do<g> I
> > think we'll go with option 3.)
>
> Some news about this?

We switched from 'SendMessage' to 'SendNotifyMessage' on November 18, 2010.

SetupBuilder 7.3 Build 3162 (December 05, 2010)
----------------------------------------------------------------------------

CHANGE : Installer: The 'Add/Remove Font' functions do not use the
SendMessage Windows API to notify other windows of the font
table change by sending a WM_FONTCHANGE message to all
top-level windows in the system. It uses the SendNotifyMessage
API now.

Friedrich

[NewsArchive]

Thank you.

Markus Zander