Using a Directory Alias with @iniwrite fails

[Joe Caverly]

c:\users\jlc\documents\dosbox\utils>ver

TCC  22.00.41 x64   Windows 7 [Version 6.1.7601]

I have a directory alias;

c:\users\jlc\documents\dosbox\utils>alias db:
c:\users\jlc\Documents\dosbox

Using this directory alias with @iniwrite causes it to fail;

echo %@iniwrite[db:\utils\vdos.ini,vDos,cmd,pause]
-1

Using the actual directory succeeds;

echo %@iniwrite[c:\users\jlc\documents\dosbox\utils\vdos.ini,vDos,cmd,pause]
0

Is this WAD?

Joe

 

[rconn]

@INIWRITE (and @INIREAD) don't support directory aliases in the filename.

 

[Charles Dye]

I suspect these functions call WritePrivateProfileString() and GetPrivateProfileString() under the hood. These functions are old and funky: if they are passed a filename without a path, Windows assumes the file is in %WINDIR%, not the current directory. Which is why Rex does not canonicalize the filename he passes to them — it would break the documented, longstanding ... weird ... behavior.

 

[Joe Caverly]

This works;

echo %@iniwrite[%@alias[db:]\utils\vdos.ini,vDos,cmd,pause]
0

Joe

 

[Charles Dye]

This works;

echo %@iniwrite[%@alias[db:]\utils\vdos.ini,vDos,cmd,pause]
0

Joe

Or:

echo %@iniwrite[%@truename[db:\utils\vdos.ini],vDos,cmd,pause]

 

[djspits]

I suspect these functions call WritePrivateProfileString() and GetPrivateProfileString() under the hood. These functions are old and funky: if they are passed a filename without a path, Windows assumes the file is in %WINDIR%, not the current directory. Which is why Rex does not canonicalize the filename he passes to them — it would break the documented, longstanding ... weird ... behavior.

That is an illuminating explanation, Charles. Do you also happen to know why TC doesn't support dir-aliases in other places? One that always surprises me is

GOSUB "alias:\fname[.EXT]" Routine

But there are others - should have kept a list. ;-)

DJ

 

[Charles Dye]

That is an illuminating explanation, Charles. Do you also happen to know why TC doesn't support dir-aliases in other places? One that always surprises me is

GOSUB "alias:\fname[.EXT]" Routine

That I don't know. But I'm pretty sure that GOSUB %@TRUENAME[alias:fname.exe] should work.

 

[djspits]

Sure, you can @search @expand, or @full, @truename or even just @alias it yourself. But that's no fun. In that case a dir-alias is just another syntax for the string concatenation we already have.

I remember something called "logical devices" (on DEC VMS machines) which were envars with a special status. Quite similar to dir-aliases in use. When you defined them there was string expansion but also a validity check. After that you had a certain convidence that you could safely use it. Like a guaranteed part of a path you could trust. That's how I use them. And its a fruitfull practice --- until its not.

I sound like a very old man.

Dirk Jan Spits.

 

[vefatica]

I remember something called "logical devices"

Windows has "DOS Devices". There's SUBST.EXE and TCC's PSUBST to manage the ones which act as drive names. The names are limited to single characters but not to A-Z. On Windows 7, these (maybe more) also work: 0, 1, ... 9, !, #, $, +, -. And at least 4: can be made permanent.

v:\> psubst
* P:\ => L:\projects
* S:\ => C:\Windows\system32
* T:\ => H:\temp
* U:\ => G:\uty
* V:\ => H:\work
* 4:\ => G:\tc22

 

[Charles Dye]

That is an illuminating explanation, Charles. Do you also happen to know why TC doesn't support dir-aliases in other places? One that always surprises me is

GOSUB "alias:\fname[.EXT]" Routine

Because GOSUB can do a path search for the file?

 

[djspits]

Why would that be a reason not to support a dir-alias? @search supports it.

 

[djspits]

Windows has "DOS Devices". There's SUBST.EXE and TCC's PSUBST to manage the ones which act as drive names. The names are limited to single characters but not to A-Z. On Windows 7, these (maybe more) also work: 0, 1, ... 9, !, #, $, +, -. And at least 4: can be made permanent.

Good point.

1) Use PSUBST on a sub-path to make it *protected*, besides if not persistent.
2) Assign the root of the virtual drive to a descriptive dir-alias to clarify its use.

The PSUBST part isn't strictly necessary but it certainly hardens the validity of your dir-alias.
I guess the appropriateness depends on how long the dir-alias will live.

A great example would be the root directory of larger standard environments like develop-, test and production trees.

copy /y develop:\product\module\*.cpp test:\product\module

BTW your idea of virtual drives could be of interest to Joe too, couldn't it?
Thanks.

 

[djspits]

I suspect these functions call WritePrivateProfileString() and GetPrivateProfileString() under the hood. These functions are old and funky: if they are passed a filename without a path, Windows assumes the file is in %WINDIR%, not the current directory. Which is why Rex does not canonicalize the filename he passes to them — it would break the documented, longstanding ... weird ... behavior.

A thought.

Lately Rex seems to invest in backward compatibility with CMD. It sounds like he does that by burdening a perfectly healthy product with the quirks from the past. Burdening, as in: actually rebuilding quirks and adding them as an alternative. If we could have a switch to toggle from compatibility mode to "way less weird" mode we go ahead and canonicalize all weird behavior out of TC. Have a separate DLL or something. Wouldn't that be nice?

 

[Charles Dye]

Why would that be a reason not to support a dir-alias? @search supports it.

Why would you pass a fully-qualified filename to a path-search function?

 

[djspits]

Why would you pass a fully-qualified filename to a path-search function?

You wouldn't, of course. Perhaps I was not expressing myself clearly.
Never, mind.
Thanks.