Launching an exe after install

[NewsArchive]

I have recently changed my application combined with adding the ability to
run the application after install. I THINK this has broken my application.
Not a fault but I am not sure why?

I launch the application Non Elevated as per the screenshot. When the
application opens a wizard runs automatically. However now I have added a
wmv video that launches when the wizard opens. It seems that if I do NOT run
the application after install and launch it manually from the desktop
shortcut the video opens. Otherwise if I allow SB to launch the application
the video does not load.

Is there an explanation for this or is it just coincidence?

But taking out that launch command does seem to make a difference.

Thanks

John

[NewsArchive]

John,

Assuming that your "If Statement" is executed, it seems to me that your
vetmain32.exe application can't be launched non-elevated. If it does not
"open" then it needs a higher permission level in order to run.

Are you requesting "asInvoker" privileges from vetmain32.exe?

It's nothing that you can "fix" at installer level. If the application does
not start (non-elevated) then it needs a change at application level.

Friedrich

[NewsArchive]

Sorry Friedrich - you misunderstand.

The application launches just fine. Once it does it opens this wizard which
then in turn opens the video. It is at this point that the strange behaviour
occurs.

It could just be a coincidence. It also might be something to do with
running in a VM. This is the first time I have tested rigorously using a VM.

All I know is that it appears to be something to do with running the
application after the install. No big deal if I take the feature out but
just curious. I just know that every time the non elevated run is used the
video does not launch, every time it is not used the video does run.

But the application always launches fine either way.

Thanks

John

[NewsArchive]

Hi John,

No, I think I did not misunderstand.

IMO, it's not a coincidence and it has nothing to do with running it on a
VM. It's exactly what I said and it has nothing to do with running the
application after the install per-se. If it does not run non-elevated after
the install then there is definitely a problem with that application. I
assume it has to handle some kind of video "initialization" and this does
not work in your case with the least privileges!!!

You have to fix this at application level! Do you have an "asInvoker"
manifest embedded?

Friedrich

[NewsArchive]

Sorry Friedrich. I understand. Yes it is "asInvoker".

But I wonder if it is in a way to do with the VM. Because the VM I am using
is XP 64bit and XP is always a pain I find. When I used to test the old way
without a VM I was always using WIndows 7 or 8.

So maybe it is XP?

John

[NewsArchive]

Hi John,

On XP, you can't run an application "non-elevated". This is an exclusive
Windows feature on UAC-aware operating systems.

Just curious, when you use "Get System Info (Installer Elevation Type)"
before your "Run Program" function, what is returned? "0" or "1"?

And what do the %_SB_ERRORCODE% and %_SB_RETURNEX% variables return after
your "Run Program" function?

Friedrich

[NewsArchive]

OK Friedrich

I can get that information to you in a while. But you seem to be saying that
what I have should not work on XP? It does <g>

Also just tried Windows 7. I have a bit more information which probably
confuses the issue even more!

Using this run command the wizard opens and the video TRIES to run. The
control then just has ready in it and even trying to run the video manually
it does not run. So I took out the run command on the installer and
reinstalled and it behaved perfectly.

I am not sure if it helps at all.

But it seems I have raised a strange issue of why a non elevated
application is running in Windows XP?

Will try to get those values to you shortly.

Thanks

John

[NewsArchive]

John,

Perhaps your "vetmain32.exe" makes use of a current path and this path is
not what is expected? I don't know.

But what I am trying to say is that this issue has absolutely nothing to do
with the installer <g>.

The installer launches your application with the CreateProcess or
ShellExecuteEx API (depending on the function you have used). After that,
responsibility is at the launched application!!

But whatever it is, it's definitely a problem in vetmain32.exe. If the
application expects a specific path to run correctly, try to set the
"Default Directory" item.

Hope this helps a bit.

Friedrich

[NewsArchive]

> But it seems I have raised a strange issue of why a non elevated
> application is running in Windows XP?

BTW, the elevated task model is not supported in XP. Microsoft introduced
it in Vista.

Friedrich

[NewsArchive]

BTW, I would suggest to check the %_SB_ERRORCODE% and %_SB_RETURNEX% return
values after the Run function. Perhaps one of the variables can catch an
exit code from your application.

Friedrich

[NewsArchive]

I can try that Friedrich. The thing is the run command NEVER fails.

But I get the point.

Thanks

John

[NewsArchive]

> I can try that Friedrich. The thing is the run command NEVER fails.
>
> But I get the point.

With "run command", do you mean the "Run Command Line" script function?

The "Run Command Line" function is a wrapper around the "CreateProcess"
Windows API and the "Run Program" function is a wrapper around the
"ShellExecuteEx" function. So the question is why does your application not
launch via ShellExecuteEx.

Because this is a XP x64 machine, the "non-elevated" option is skipped (by
SetupBuilder) and the "asInvoker" manifest item is ignored (by Windows).

Friedrich

[NewsArchive]

OK Friedrich - maybe I am misunderstanding how to set up the RUN command. I
feel sure this is how you recommended it be set up when someone else asked
this question but I could be wrong.

Attached is how I have set it up and also the results from the variables you
asked for. Sorry must dash and did not get GetSystemInfo correctly. If still
needed will sort it on my return.

HTH

John

[NewsArchive]

BTW just to confirm this is installing to XP - 64

HTH

John

[NewsArchive]

Hi John,

Okay, the screenshot tells me that your "vetmain32.exe" launched fine. 259
means that your process is active. After that, responsibility is at
(launched) application level.

It also tells us that the problem is definitely in your "vetmain32.exe"
application. Perhaps it requires a specific working directory? Only the
developer of that apps knows. If you have access to the source code then I
would check if it depends on a specific current folder (an application
should never do this!). Sometimes it can also help to set the working
directory in the "Run Program" function. This will then pass the folder to
the CreateProcess and/or ShellExecuteEx API.

But this is definitely not an installer issue at all. It's a problem in the
launched application.

Sorry for the bad news :-(

Friedrich

[NewsArchive]

Hi Friedrich - no need to apologize <g>

It's not bad news at all. I suspected it was me. You threw me when I thought
you were saying it should not run under XP.

Yes this video thing is acting rather strangely I have to say. I am in
control of it all. Am using FileExplorer to load the video into and play.

Thanks

John

[NewsArchive]

Hi John,

<G>

Please keep us posted.

Friedrich

[NewsArchive]

Well I thought I had it sorted. A CLEAN VM does not have Windows Media
Player installed! So I thought there was no association. I realized this
when I went to the folder and launched the video manually and it started the
Media Player setup wizard.

Anyway even with it installed it still does not work.

However, if I quit the wizard which opens the video and start the
application again, this time the wizard starts and the video plays.

The video is in Program Files (x86)/Ambrit Software/Vet/Video/Wizard but
that should not make any difference at all.

Being as I am strapped for time anyway maybe I will just take out the Run
after install feature. It's no big deal at all really and maybe safer
anyway. I find that most software these days does not run immediately after
installing anyway.

John

[NewsArchive]

>
> Being as I am strapped for time anyway maybe I will just take out the Run
> after install feature. It's no big deal at all really and maybe safer
> anyway. I find that most software these days does not run immediately after
> installing anyway.

John,

AND, as we have received cautions when running programs immediately after
installs - most software should be run "asInvoker" NOT
"requireAdministrator" -

I choose to NOT allow ANY programs to be run immediately after install as a
matter of habit - in case, a company makes a mistake in setup and the
program in question IS NOT running - non-elevated.

Received this caution years ago, and still follow it.

David

--
From David Troxell - Product Scope 7.9 - Encourager Software
EZChangeLog Reporter 2.1 Available - http://www.encouragersoftware.com/
http://www.encouragersoftware.com/software-developers.html

[NewsArchive]

I agree. I know Friedrich advised against this some time ago (going back a
couple of years now) until he came up with this new method of running.

Personally I think removing the option is safest all round and no great
inconvenience to the end user.

Being as my problem is going to take some tracking down right now it makes
the best sense.

John

[NewsArchive]

> I agree. I know Friedrich advised against this some time ago (going back a
> couple of years now) until he came up with this new method of running.

John,

Yes, I quite agree, with Setupbuilder, it's a legitimate, useful option,
and each vendor must determine if their market needs to have it as an
option - but - personally - I choose to NOT use that option at the end of
any install.

However, having said that - there are VERY good reasons to use it besides
having the MAIN program start at the end of the install. Another great
option in the SetupBuilder Developer feature list.

David

--
From David Troxell - Product Scope 7.9 - Encourager Software
EZChangeLog Reporter 2.1 Available - http://www.encouragersoftware.com/
http://www.encouragersoftware.com/software-developers.html

[NewsArchive]

Oh yes - absolutely.

John

[NewsArchive]

> Personally I think removing the option is safest all round and no great
> inconvenience to the end user.

That is what we do.

We simply give the user a MESSAGE saying that the install completed
successfully and that they can run it from the shortcut.

Charles


--
-------------------------------------------------------------------------------------------------------
Charles Edmonds
www.clarionproseries.com - ProScan, ProImage, ProPath and other Clarion
developer tools!
www.ezchangelog.com - "Free ChangeLog software to manage your projects!"
www.setupcast.com - "A revolutionary new publishing system for software
developers - enhanced for SetupBuilder users!"
www.pagesnip.com - "Print and Save the Web, just the way you want it!"
www.ezround.com - "Round Corner HTML tables with matching Banners, Buttons
and Forms - Now with PNG support!
www.lansrad.com - "Intelligent Solutions for Universal Problems"
www.fotokiss.com - "World's Best Auction Photo Editor"
-------------------------------------------------------------------------------------------------------

[NewsArchive]

>> Personally I think removing the option is safest all round and no great
>> inconvenience to the end user.
>
> That is what we do.
>
> We simply give the user a MESSAGE saying that the install completed
> successfully and that they can run it from the shortcut.

In fact, it's perfectly valid to start a program after installation on
UAC-aware operating systems if you enable the "launch non-elevated" option.
This always launches the application in the correct user context.

But of course, a message is okay, too!

If the application does not work as expected when started from the installer
(and in Johns' case it does not make a difference whether it is an UAC or
non-UAC system) then there is definitely a hidden bug in the application
somewhere. It starts fine but does not work as expected!

IMO, when John starts its application for the first time, it has to do some
kind of "initialization". And I think this initialization process fails.
Perhaps it is caused by a permission problem or the classic "current folder"
problem.

@John: what happens in the following scenario: Create a new "JoeUser"
Standard User account on Windows 7. Then logon to that JoeUser profile. In
your install project, do NOT start the application at the end of the
install. Okay, now install your program and start it from the Shortcut.
What happens?

Friedrich

[NewsArchive]

Hi Friedrich

Using a JoeUser Standard User account and starting manually as suggested the
application opens, the wizard starts and the video control is displayed. The
video is the loaded and starts to play.

With the original problem the video tries to load, says Ready but does not
play.

The behaviour of this Standard Account is what I get on every OS I have
tried when NOT using the Run command.

I am thinking this IS to do with the "current folder" issue which is not
being set when the Run command is issued but is being set when starting
manually.

HTH

John

[NewsArchive]

Hi John,

> I am thinking this IS to do with the "current folder" issue which is
> not being set when the Run command is issued but is being set when
> starting manually.

Try to set the "Default Directory" to %_SB_INSTALLDIR% in the 'Run Program'
dialog properties. I see that you have this field blank in your previous
screenshot.

Friedrich

[NewsArchive]

Yes just trying that Friedrich.

John

[NewsArchive]

Friedrich - that does seem to work. Just going to run some more tests for
curiosity.

But now it does work.

Sorry to have wasted your time.

I suspect I have just been lucky before in that I have not launched a file
after startup although that file is in the working directory and this is the
first time I have released a FULL install since changing that. All previous
installs using the Run command have been updates to existing clients where
that wizard is never run.

Amazing how a bug can exist for so long and never be found.

John

[NewsArchive]

Hi John,

COOL!!! Absolutely no problem. Thank you for the very good news! :-)

Friedrich

[NewsArchive]

Friedrich - I have just confirmed everything and the Current Path was the
Desktop. I now recall having this problem when I first bought SB!! But that
was a long time ago <g>

Anyway is there any mileage in suggesting that when completing the Target
Folder field on the Run Program and Create Shortcut Dialogs that SB could
auto complete the Default Directory field also? Of course anyone could
delete that then.

But I really cannot see why you would ever not want the Default Directory to
be the same as the Target Folder except for unusual circumstances. After all
the shortcut by it's very nature is always on the desktop (or in the old
days in the Start Menu) so the Current Path will NEVER be the target folder.

Maybe I am just being lazy but thought it might prevent this happening with
someone else. After all it can exist for many years in my case and never
cause a problem until you do something like launch a file immediately after
the Run dialog.

What do you think?

Many thanks

John

[NewsArchive]

Hi John,

> Maybe I am just being lazy but thought it might prevent this happening
> with someone else. After all it can exist for many years in my case
> and never cause a problem until you do something like launch a file
> immediately after the Run dialog.
>
> What do you think?

Well, the default folder is set by default to %_SB_INSTALLDIR% for the Run
command from the Visualizer ;-) See attached screenshot. When you add a
Run command from the script editor then all is blank so you can fine-tune
it.

But in fact, only the developer knows what is required for his specific
application.

It is a fatal application issue when an application depends on the "current"
folder. You should never ever do this!!! It's against the good development
rules and guidelines -- you NEVER know what the current path is when an
application gets started (and you don't know the currently active "search
order" for dependency files).

You said "I really cannot see why you would ever not want the Default
Directory to be the same as the Target Folder except for unusual
circumstances". Needed quite often. For example, if the working directory
is on a network share, etc. But even in this case you should control the
working directory from within your own application.

But again, it is very bad practice to depend on the currently active folder.
You can "work-around" this here in your case by setting the default or
working folder, but it's still not 100% accurate.

To cut a long story short <g>, the main problem is not that you didn't set
the working directory when you launched it. The problem is that the
application itself depens on a "current folder" value.

Friedrich

[NewsArchive]

Agreed. I normally never do rely on the current path and set that right at
the start in my data dll and set variable globals for different paths using
the full name. In this case however I did not!

John