Using a Directory Alias with @iniwrite fails

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

TCC  22.00.41 x64   Windows 7 [Version 6.1.7601]

I have a directory alias;
Code:
c:\users\jlc\documents\dosbox\utils>alias db:
c:\users\jlc\Documents\dosbox

Using this directory alias with @iniwrite causes it to fail;
Code:
echo %@iniwrite[db:\utils\vdos.ini,vDos,cmd,pause]
-1

Using the actual directory succeeds;
Code:
echo %@iniwrite[c:\users\jlc\documents\dosbox\utils\vdos.ini,vDos,cmd,pause]
0

Is this WAD?

Joe
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
4,689
106
Albuquerque, NM
prospero.unm.edu
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.
 
Apr 13, 2010
318
7
62
The Hague
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

Super Moderator
Staff member
May 20, 2008
4,689
106
Albuquerque, NM
prospero.unm.edu
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.
 
Apr 13, 2010
318
7
62
The Hague
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. :oldman:

Dirk Jan Spits.
 
May 20, 2008
12,175
133
Syracuse, NY, USA
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.
Code:
v:\> psubst
* P:\ => L:\projects
* S:\ => C:\Windows\system32
* T:\ => H:\temp
* U:\ => G:\uty
* V:\ => H:\work
* 4:\ => G:\tc22
 
Apr 13, 2010
318
7
62
The Hague
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.
Code:
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.
 
Last edited:
Apr 13, 2010
318
7
62
The Hague
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?
 

Similar threads