Author Topic: STARTUPDIR  (Read 415 times)

André Heldoorn

  • Full Member
  • ***
  • Thank You
  • -Given: 37
  • -Receive: 8
  • Posts: 235
    • View Profile
STARTUPDIR
« on: November 29, 2017, 04:47:23 pm »
</silence>
Often one can reduce the size of INI files and install scripts by modifying what an install script (REXX, WarpIn, EXEs, ...) is doing. No object IDs for abandonware objects unless it's a WPFolder, not setting a value to its default value anymore because WPTOOLS once reported such a copied and pasted setting, using ENVIRONMENT variables instead of Microsoft's OS2ENVIRONMENT, and so on.

Code: [Select]
CALL SysCreateObject 'WPProgram','Why?','<WP_DESKTOP>','EXENAME=F:\OO\BAR.EXE;STARTUPDIR=F:\OO'
Assuming this EXENAME setting of a new WPProgram object of a native OS/2 F:\OO\BAR.EXE, then when/why is it required to set the STARTUPDIR to the same F:\OO as BAR.EXE's directory?
<silence>



Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 8
  • -Receive: 91
  • Posts: 1171
    • View Profile
Re: STARTUPDIR
« Reply #1 on: November 29, 2017, 06:06:35 pm »
Some programs need to find their ini files and such, including the Mozilla apps that need to find their DLLs.

Andreas Kohl

  • Full Member
  • ***
  • Thank You
  • -Given: 6
  • -Receive: 9
  • Posts: 203
    • View Profile
    • warpserver.de
Re: STARTUPDIR
« Reply #2 on: November 29, 2017, 09:20:39 pm »
Assuming this EXENAME setting of a new WPProgram object of a native OS/2 F:\OO\BAR.EXE,
From the unsilent minorty: Sorry, but this assumption is completely wrong. The created Program object is an instance of the WPProgram object class unless it's not overwritten by something else. WPProgram is a subclass of WPAbstract. It's never an object of your "native OS/2 F:\OO\BAR.EXE". That should be an object on it's own (of class WPProgramFile).

Quote
then when/why is it required to set the STARTUPDIR to the same F:\OO as BAR.EXE's directory?
I don't know where your information came from? It's not required to specifiy a STARTUPDIR (a working directory) for the Setup string, so it can be left empty. Quite easy to check by using the template folder and creating a Program object from the Program template.

André Heldoorn

  • Full Member
  • ***
  • Thank You
  • -Given: 37
  • -Receive: 8
  • Posts: 235
    • View Profile
Re: STARTUPDIR
« Reply #3 on: November 30, 2017, 01:08:01 am »
Some programs need to find their ini files and such, including the Mozilla apps that need to find their DLLs.

</silence>
Is a generic conclusion that BAR.EXE reports the right current working directory, but if a file-related OS-specific API is involved (load module, open INI file, ...) then it should always be set, if anything to make sure that the OS ("SHELL.EXE") always uses the same working directory too? So even when BAR.EXE writes "Hello, INI file!" to its BAR.INI file?
<silence>

André Heldoorn

  • Full Member
  • ***
  • Thank You
  • -Given: 37
  • -Receive: 8
  • Posts: 235
    • View Profile
Re: STARTUPDIR
« Reply #4 on: November 30, 2017, 01:53:48 am »
Sorry, but this assumption is completely wrong.

I don't know where your information came from?

It's not required to specifiy a STARTUPDIR (a working directory) for the Setup string, so it can be left empty. Quite easy to check by using the template folder and creating a Program object from the Program template.

</silence>
It looks like you've constructed and solved both of your own new issues, so that's sorted.

The single fact that the STARTUPDIR can be empty doesn't really mean anything. It's weird, but users do expect working software. The install procedure in question does create 744 WPProgram objects and sets 197 STARTUPDIRs, so I presume there's no need for such a proposed check. Nor test.

It being set by an author of an installer often appears to be random behaviour, and/or a result of pasted sample REXX code. In a way I'm pasting code of those installers too, and matching documentation of actually required settings is quite rare. The number of installers setting a STARTUPDIR was significantly more than 197, but now it isn't always 100% obvious anymore that the setting can be removed. Without breaking anything. Hence the original question.

SM still has the setting, unlike several objects pointing to simple EXEs.
<silence>