[C.RAZY]

Hello again!

I posted earlier what I thought to be a problem with batch files, see here...

This seems not to be a problem with batch files, it seems as if it has to do something with the workdir.x directive, as the following does not work:

description.0=Office 2003
workdir.0=software\Office
command.0=Office.exe
selected.0=1
hidden.0=0

(Office.exe is a self extracting reduced silent Office installation, which works if I just doubleclick it)

With /verbose, in the logfile (and -window) it just reads "Office.exe", but nothing like "Office 2003: completed."

Could this be the workdir.x directive? Does *everything* used with workdir.x has to use "command.x=cmd.exe /c <file here>"?

the following code works:

description.0=Word, Excel, Powerpoint
command.0=software\Office\Office.exe
selected.0=1
hidden.0=0

I tested with wihu versions 2.1.6.0, 2.1.10.2 and 2.1.10.3

Thanks for any answers and have a nice day,
C.RAZY

[my2001]

Hi!

I was about to post a new thread about workdir.x directive since I face exact the same problems as you described. But u've been faster!

[For those who don't have time to read: just compare the last two code examples in this posting, they cause the same.]

I guess I found out the following:
Obvioulsy the workdir-directive doesn't set the let's call it "main directory". This remains always the same directory where WIHU.EXE is located. So, if you want to call an application it is NOT sufficient to set the appropiate directory by workdir.x-directive and merely call the installation executable by command.x-directive without any path.

You always have to use command.x-directive with a relative path to WIHU.EXE! workdir.x-directive doesn't seem to affect this. So, when does one need workdir.x? Well, let's assume WIHU.EXE is located one level above a folder called "Inst" and you use the following line:

command.0=msiexec /i Inst\Prog\Acrobat\AcroPro.msi TRANSFORMS=unattended.mst /qr

- Here you must not forget to specify the (relative) path for AcroPro.msi or elsewise WIHU won't find the AcroPro.msi. (I told that earlier.)
- If you DO NOT specify workdir.0 line in this example WIHU will search for the unattended.mst file in it's own directoy, i.e. where WIHU.EXE is located! And (only) this particular behaviour can be changed by workdir.x-directive! So you've got the choice between:

command.0=msiexec /i Inst\Prog\Acrobat\AcroPro.msi TRANSFORMS=Inst\Prog\Acrobat\unattended.mst /qr

or

command.0=msiexec /i Inst\Prog\Acrobat\AcroPro.msi TRANSFORMS=unattended.mst /qr
workdir.0=Inst\Prog\Acrobat\

Hopefully I'm right and maybe this explanation helps a bit.

[C.RAZY]

Indeed, that could be the problem, but does it work like the following (as I replied to your thread about msiexec /i)

command.0=cmd.exe /c msiexec /i AcroPro.msi TRANSFORMS=unattended.mst /qr
workdir.0=Inst\Prog\Acrobat\

or even

command.0=cmd.exe /c AcroPro.msi TRANSFORMS=unattended.mst /qr
workdir.0=Inst\Prog\Acrobat\

?

Strange behavior of the workdir.x directive, but what you said seems to be a possible workaround of this ...

I think the workdir.x needs some recode to work like expected, but unfortunately I am no visual c programmer

So long,
C.RAZY

P.S.: Sorry for editing my own posts that much, but I wrote them as all of this slowly became clearer to me

[my2001]

Hi!

I don't know because I didn't test but most likely your second code example won't work and your first might. *hehe* Although there is no reason to use any of both examples because there's no reasonable case in which it makes sense to call msiexec by cmd. Msiexec is available from everywhere within Windows since it's stored in system32 directory and why not call it directly?

Moreover I assume workdir-directive is confusing, indeed. But this comes because it didn't come up to our expectations. Workdir is quite the same as the "Ausführen in"-thingy; right click on a windows shortcut to see what I mean. So there's no real need for recoding - at least according to my opinion. workdir.x has just been misinterpreted.

[C.RAZY]

my2001, on Sep 16 2004, 09:15 AM, said:

Msiexec is available from everywhere within Windows since it's stored in system32 directory and why not call it directly?

I can start .msi files from the command shell just by typing <name>.msi.
I can start batch files from the command shell, and cmd.exe is in system32, too.
But why do I have to explicitly enter it when starting batch files from wihu?
I am (or *should* be) in the folder the batch file is in (through the workdir.x directive), so why not call them directly?

Just curious...

P.S.: I think it's not well done of workdir.x if not *all* of the command.x is started in the directory explicitly stated there.

[BenjaminKalytta]

Quote

I can start .msi files from the command shell just by typing <name>.msi.

Yes, but since .msi files are not native windows executable files this isn't possible here. The same thing concerns batch files.
But let me say, I'll rework some code by readin the "command interpreter" from registry.

What workdir.x actually do and what not just read it by your self. http://msdn.microsoft.com/library/default....eateprocess.asp

Take a look at "lpCurrentDirectory" parameter.
workdir.x only sets the "current working directory" for the new running process i.e. after command.x is executed. This does not change the relative directory where WIHU searchs for application files, so it wont change %WIHU% or %CURDIR% environment variables!

Benjamin

This post has been edited by BenjaminKalytta: 18 September 2004 - 05:31 PM