Running program from icon = current dir is changed

8bitbubsy · 24 January 2023, 12:35

I'm bugfixing a program written in 68k asm that has an issue. On startup, it assigns the current working directory to a device name.
It expects the directory to be the same directory as where the binary was ran from, but if you double-click the icon from Workbench, the directory is changed to Workbench: before the assign happens.
However, running the program from CLI will not mess with the correct working directory.

How can I make sure that the working directory is the same as the binary directory when I run the program from an icon in Workbench?

hooverphonique · 24 January 2023, 12:54

If you're on OS2+, you can refer to the "PROGDIR:" assign which always points to the directory of the executable. On OS <2 it is a bit more involved - there is a thread on eab which describes how to get the path of the currently running executable.

8bitbubsy · 24 January 2023, 13:03

I see. Do you happen to have a link to that thread?

hooverphonique · 24 January 2023, 15:15

I just recalled something - the WBStartup message contains a lock to the directory of the executable, so you could use that to CurrentDir() to it. It should work on all OS versions.

ross · 24 January 2023, 16:06

Perhaps this?:
http://eab.abime.net/showpost.php?p=1331387&postcount=5

This is specific for extracting the working floppy device, but you can strip it

8bitbubsy · 24 January 2023, 16:20

Thanks, I'll borrow some of that.

Thomas Richter · 24 January 2023, 17:18

Quote:

Originally Posted by 8bitbubsy

I'm bugfixing a program written in 68k asm that has an issue. On startup, it assigns the current working directory to a device name.

Hopefully to a lock created from a device name, otherwise it is calling for a software failure.

Quote:

Originally Posted by 8bitbubsy

It expects the directory to be the same directory as where the binary was ran from, but if you double-click the icon from Workbench, the directory is changed to Workbench: before the assign happens.

I am a little surprised here. If it "assigns" the current dir to a "device name", then the current dir would hardly be the directory the program was called from. For that, you would need - if called from the shell - get the current working directory, then lock on the name of the executable you find in the CommandLineInterface structure, and then take the ParentDir(). Or use PROGDIR:

Note that the program does not need to be called by its name - it could also be called by a full or partial path.

Quote:

Originally Posted by 8bitbubsy

However, running the program from CLI will not mess with the correct working directory.

That should hopefully be the norm, inlcuding to unlock all locks you have obtained on the way.

Quote:

Originally Posted by 8bitbubsy

How can I make sure that the working directory is the same as the binary directory when I run the program from an icon in Workbench?

You find the directory of the "tool" program in WBStartup->wa_Args[0].wa_Lock. That is, the lock of the first workbench argument delivered with the startup message.

Note that this lock was created by the workbench for you, so please do not release this lock (but only those locks you obtained yourself).

a/b · 24 January 2023, 17:49

Quote:

Originally Posted by Thomas Richter

You find the directory of the "tool" program in WBStartup->wa_Args[0].wa_Lock. That is, the lock of the first workbench argument delivered with the startup message.

Note that this lock was created by the workbench for you, so please do not release this lock (but only those locks you obtained yourself).

Is that argument 100% guaranteed to be present in KS2.04+, in case you know (if so, how about KS1.3+)? I was recently fixing an app, and I ended up using the CLI method as fallback if it's not available, but would prefer not to if there's no need...

Code:

.FromWB
	move.l	d5,a0				; startup wbmsg
	move.l	(sm_ArgList,a0),d0
	beq.b	.GetCurrDir			; just in case...
	move.l	d0,a0
	move.l	(a0),d1				; ArgList[0].wa_Lock (currdir)

Thomas Richter · 24 January 2023, 19:25

Quote:

Originally Posted by a/b

Is that argument 100% guaranteed to be present in KS2.04+,

Yes.

a/b · 24 January 2023, 19:35

OK, thanks

. While it's logical, the original code is making that check and I didn't want to completely disregard that.

8bitbubsy · 25 January 2023, 16:40

How about KS1.x? Can you still get the directory lock like that?

Thomas Richter · 25 January 2023, 17:01

Yes. In worst case, the lock is NULL and wa_Arg is the complete path.

24 January 2023, 12:35	#1
8bitbubsy Registered User Join Date: Sep 2009 Location: Norway Posts: 1,711	Running program from icon = current dir is changed I'm bugfixing a program written in 68k asm that has an issue. On startup, it assigns the current working directory to a device name. It expects the directory to be the same directory as where the binary was ran from, but if you double-click the icon from Workbench, the directory is changed to Workbench: before the assign happens. However, running the program from CLI will not mess with the correct working directory. How can I make sure that the working directory is the same as the binary directory when I run the program from an icon in Workbench?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Icon changed	Planetinfinity	Retrogaming General Discussion	1	12 October 2021 22:05
OS 3.9 Ram-Disk Icon gone/changed	elowan	support.Other	16	10 August 2016 12:41
External windows program communicating with program running inside WinUAE	xxxxx	support.WinUAE	10	19 February 2013 09:27
Cf card show up as dir in program	penta	support.Hardware	1	14 October 2011 17:13
Icon Update program - what do you use?	Bloodwych	support.Apps	9	22 September 2007 22:54

24 January 2023, 12:54	#2
hooverphonique ex. demoscener "Bigmama" Join Date: Jun 2012 Location: Fyn / Denmark Posts: 1,624	If you're on OS2+, you can refer to the "PROGDIR:" assign which always points to the directory of the executable. On OS <2 it is a bit more involved - there is a thread on eab which describes how to get the path of the currently running executable.

24 January 2023, 13:03	#3
8bitbubsy Registered User Join Date: Sep 2009 Location: Norway Posts: 1,711	I see. Do you happen to have a link to that thread?

24 January 2023, 15:15	#4
hooverphonique ex. demoscener "Bigmama" Join Date: Jun 2012 Location: Fyn / Denmark Posts: 1,624	I just recalled something - the WBStartup message contains a lock to the directory of the executable, so you could use that to CurrentDir() to it. It should work on all OS versions.

24 January 2023, 16:06	#5
ross Defendit numerus Join Date: Mar 2017 Location: Crossing the Rubicon Age: 53 Posts: 4,476	Perhaps this?: http://eab.abime.net/showpost.php?p=1331387&postcount=5 This is specific for extracting the working floppy device, but you can strip it

24 January 2023, 16:20	#6
8bitbubsy Registered User Join Date: Sep 2009 Location: Norway Posts: 1,711	Thanks, I'll borrow some of that.

24 January 2023, 19:35	#10
a/b Registered User Join Date: Jun 2016 Location: europe Posts: 1,039	OK, thanks . While it's logical, the original code is making that check and I didn't want to completely disregard that.

25 January 2023, 16:40	#11
8bitbubsy Registered User Join Date: Sep 2009 Location: Norway Posts: 1,711	How about KS1.x? Can you still get the directory lock like that?

25 January 2023, 17:01	#12
Thomas Richter Registered User Join Date: Jan 2019 Location: Germany Posts: 3,233	Yes. In worst case, the lock is NULL and wa_Arg is the complete path.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)