WinXP: Make winapp2.ini work for your language (translate to German)

[putzend]

Hello

 

I just found the winapp2.ini recently for ccleaner

http://forum.piriform.com/index.php?showtopic=1110

 

I noticed that temporary files of several programs weren't found by ccleaner remaining on my hdd.

Unfortunately, this version doesn't work on my German Windows XP since the used paths are optimized for the English Version.

 

Windows 7 and Vista probably will work, since English path expressions are found.

 

Thus, I searched and replaced some of the entries to make above winapp2.ini work properly.

 

Since I didn't find an existing forum entry, I thought, I want to share it with you:

 

Just download the empty winapp2.ini to your hdd and copy/paste the original entries into it or whatever you need.

Then search and replace the expressions below if you are using the German Version or use your Windows XP localised expressions:

 

;-----------------------
; English Expression       Deutscher Ausdruck
; ----------------------   ------------------
; My Documents             Eigene Dateien
; My Music                 Eigene Musik
; Documents and Settings   Dokumente und Einstellungen
; Application Data         Anwendungsdaten
; Local Settings           Lokale Einstellungen
; My Videos                ? (Eigene Videos?)
; My Chat Logs             ?

For Videos and Chat you have to check the path.

 

Happy ccleaning

[Andavari]

I'll PM this topic location to TwistedMetal since he maintains winapp2.ini, and hopefully he'll copy over your topic to his.

[Alan_B]

Windows 7 and Vista probably will work, since English path expressions are found.

;-----------------------
; English Expression       Deutscher Ausdruck
; ----------------------   ------------------
; My Documents             Eigene Dateien
; My Music                 Eigene Musik
; Documents and Settings   Dokumente und Einstellungen
; Application Data         Anwendungsdaten
; Local Settings           Lokale Einstellungen
; My Videos                ? (Eigene Videos?)
; My Chat Logs             ?

 

Thank you for information that is relevant to a script created by others that I am working on.

One problem is that paths for XP do not work on W7 (JUNCTIONS regardless);

Another problem is that even for XP they do not work on German systems.

 

The first problem is easily solved by avoiding stupid things like

%userprofile%\Application Data\

and instead to use the far more concise and correct for XP and W7 etc variable

%APPDATA%

 

Please advise, does this variable also exist in the German O.S.

Would %APPDATA% not only give compatibility for XP and W7,

is it also compatible for "foreign" languages ?

 

I have found this to be a very useful list of XP and W7 compliant variables

http://wapedia.mobi/en/Environment_variable?t=5.#5.

 

N.B.

Although %LOCALAPPDATA% does not exist in XP by default, as shown by the above link,

I understand it works within winapp2.ini.

 

Regards

Alan

[putzend]

Hello Alan

 

Sure, %appdata% does work on my German XP as well as %programdata% etc.

From your linked list the last three commands don't apply as well as the (x86)-stuff since Win XP is 32bit.

If you'd like, I'll can check the list on Windows 7 German 32bit and 64bit.

 

I can also check ccleaner on Windows 7 32bit as well as 64bit using the English as well as my localized German winapp2.ini for the installed applications.

 

Many of the combinations of winapp2.ini are like "\local settings\application data\" or "My blabla" which has no set command under XP.

As I understand, the local settings\application data is the same as %localappdata% for Win7.

It might be a solution to create a set command "localappdata" for ccleaner under XP to solve the problem. This should run under all Windows-Versions if the path is correct.

Without having the command localappdata set, it won't work for ccleaner under XP.

 

What kind of script are you working on?

 

Regards

[Willy2]

I can confirm that both %localappdata% and %appdata% do work on XP SP 3. See also the table below. In the registry there's a very interesting ""translation"" table.

 

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders]

Below some lines from that table in the dutch Windows (XP) version:

 

"AppData"="C:\Documents and Settings\--User--\Application Data"

"Local Settings"="C:\Documents and Settings\--User--\Local Settings"

"Local AppData"="C:\Documents and Settings\--User--\Local Settings\Application Data"

"My Pictures"="C:\Documents and Settings\--User--\Mijn documenten\Mijn afbeeldingen"

"My Music"="C:\Documents and Settings\--User--\Mijn documenten\Mijn muziek"

"My Video"="C:\Documents and Settings\--User--\Mijn documenten\Mijn video"

 

(Are these all Windows systemvariables ?)

 

Olli_S and El Pusher had some interesting MS Office related (Not Windows related) language problems. See post #11 and #15 of this thread: http://forum.pirifor...showtopic=25696

[Alan_B]

Sure, %appdata% does work on my German XP as well as %programdata% etc.

 

Many of the combinations of winapp2.ini are like "\local settings\application data\" or "My blabla" which has no set command under XP.

As I understand, the local settings\application data is the same as %localappdata% for Win7.

 

Thank you very much.

I was afraid that a batch script which used %APPDATA% would need changing to %ANWNDUNGSDATEN%.

 

I previously added to the beginning of my script

IF "%LOCALAPPDATA%"=="" SET LOCALAPPDATA=%USERPROFILE%\Local Settings\Application Data

and used %LOCALAPPDATA% to replace all instances of

%USERPROFILE%\Local Settings\Application Data

 

What was good for XP is now good for W7 as well.

Pleased to see that this should also resolve foreign language problems.

 

It might be a solution to create a set command "localappdata" for ccleaner under XP to solve the problem.

%LOCALAPPDATA% is not defined for XP, and I thought the same as you.

I recently suggested winapp2.ini needed to be fixed to accommodate this,

but have been assured that the variable does exist.

I am happy to assume that when CCleaner runs its code (written in 'C' I believe)

it is able to achieve the equivalent of SET LOCALAPPDATA=.....

and this additional environmental variable is inherited by Winapp2.ini when CCleaner runs it.

 

What kind of script are you working on?

 

I have taken a cleanup script from the Comodo user forum and made it bullet proof.

The original made the assumption that when it deleted something it was gone.

Often the assumption was good, but a lot of people had permissions issues which prevented deletion.

I have adapted the script to revisit everything it deleted and report every item that resisted eviction.

It makes no attempt at automatically over-powering Windows security settings and breaking down permissions barriers,

but it identifies every problem which merits consideration of manual actions to "take ownership" and then zap.

 

After various battles I had everything good for XP, for which it was written.

 

I have recently got dual booting and Windows 7.

 

I think M.$ used Intellectual property of others, possibly Unix, when they created JUNCTIONS.

They did not understand what the were doing and made a pigs ear out of what had been a silk purse.

They originally intended and published that when a JUNCTION was no longer needed it could be deleted.

Unfortunately deleting not only removed the junction it also removed the entire contents of the destination.

 

Instead of correcting their mistake they published a technical note warning of the problem

and as a typical M.$. bodgy workaround advise the use of CACLS to protect the junction from deletion.

 

Windows 7 (and presumably Vista) are supposed to be able to use applications that were coded for use on XP,

and to that end they have JUNCTIONS to intercept and redirect the paths that were present in XP.

Those morons still have not corrected their fundamental error,

and have applied special access restrictions to prevent deletion of the junctions in W7.

Unfortunately this has broken functionality for most of CMD.EXE,

e.g. DIR will not see files that are on the junction destination.

 

Now I have altered every path to make maximum use of environmental variables,

and have found that two of these variables are defined in W7 to avoid the redirection JUNCTIONS.

CMD.EXE now works just as well in W7 as in XP for cleaning two paths which no longer use JUNCTIONS.

 

I have quite a few more paths to correct and validate for W7 - but I am getting there.

 

Regards

Alan

[putzend]

Good news Alan!

 

%localappdata% does work under my Windows XP without the set variable :-)

I've found it a couple of times in the winapp2.ini like M$ Picture Manager.

 

I just checked on MediaMonkey

 

[*MediaMonkey standard]
LangSecRef=3023
DetectFile=%ProgramFiles%\MediaMonkey\MediaMonkey.exe
Default=True
FileKey1=%userprofile%\Lokale Einstellungen\Anwendungsdaten\MediaMonkey|MediaMonkey.m3u
FileKey2=%userprofile%\Lokale Einstellungen\Anwendungsdaten\MediaMonkey\Previews|*.*|RECURSE

 

[*MediaMonkey localappdata]
LangSecRef=3023
DetectFile=%ProgramFiles%\MediaMonkey\MediaMonkey.exe
Default=True
FileKey1=%localappdata%\MediaMonkey|MediaMonkey.m3u
FileKey2=%localappdata%\MediaMonkey\Previews|*.*|RECURSE

 

In both cases the file mediamonkey.m3u was found analyzing the system.

The other folder I usually don't use.

 

 

@Willy2

I checked my registry and found the entries you were posting.

But have you noticed, that "LocalAppData" is written "Local AppData" in registry with a space in between.

There must be some kind of magic!

[Alan_B]

Good news Alan!

 

%localappdata% does work under my Windows XP without the set variable :-)

I've found it a couple of times in the winapp2.ini like M$ Picture Manager.

 

Sorry but I whilst I accept it could work under winapp2.ini under CCleaner.exe under XP,

that does not convince me it would work under XP direct,

and I am currently focussed on use of scripts where %LOCALAPPDATA% would be useful.

 

Quoting http://wapedia.mobi/en/Environment_variable?t=5.#5.

%LOCALAPPDATA% [NOT AVAILABLE IN WINDOWS XP WITHOUT EXPLICIT DECLARATION. [1]]

I assume that CCleaner.exe is responsible for such an explicit declaration.

 

I have a default XP that was installed by Acer 7 years ago.

The command SET will show APPDATA, but knows nothing of LOCALAPPDATA.

SET cannot show volatile variables such as TIME,

but ECHO %TIME% will show them,

but even ECHO %LOCALAPPDATA% cannot see them.

 

If anyone finds that %LOCALAPPDATA% is usable for a script running under XP,

I suggest that it may be due to a custom tweak incorporated by a P.C. maker that pre-installs the operating system.

 

I launched CMD.EXE and issued a few commands to illustrate my concern, and have pasted the result below

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Dad>ECHO LOCALAPPDATA = "%LOCALAPPDATA%"
LOCALAPPDATA = "%LOCALAPPDATA%"

C:\Documents and Settings\Dad>ECHO APPDATA = "%APPDATA%"
APPDATA = "C:\Documents and Settings\Dad\Application Data"

C:\Documents and Settings\Dad>ECHO %TIME%
13:02:55.26

C:\Documents and Settings\Dad>CD /D H:\

H:\>CD /D %LOCALAPPDATA%
The system cannot find the path specified.

H:\>CD /D %APPDATA%

C:\Documents and Settings\Dad\Application Data>

 

 

I checked my registry and found the entries you were posting.

But have you noticed, that "LocalAppData" is written "Local AppData" in registry with a space in between.

There must be some kind of magic!

 

I noticed that as well, but decided this was nothing to do with LOCALAPPDATA because I could not see in that region of the registry any similar entries for APPDATA or all the other environmental variables which can be shown via SET. I think I know what it is not - but do not know what it is for ! !

 

Regards

Alan

[Willy2]

Putzend,

 

I noticed that extra space as well. When I searched the registry for local appdata. I found several entries. But it seems localappdata can't be found at all in the registry. (Suggestion: Search the registry with the words appdata and you'll come across more translation tables.)

 

Alan,

 

Yep, you're right. I tried your example and my XP didn't recognize the systemvariable %localappdata% as well. So, it hasn't been declared at all. But Windows Explorer (WE) does recognize it (somehow).

 

I came across the following:

I renamed the folder Mijn documenten (english: My documents, german: Eigene Dateien) to Willy2 using Windows Explorer (WE). After that, in WE this folder always shows up as Willy2. Then I added that folder to the Include section of CC. Both in ExplorerXP and CC that folder Willy2 doesn't show up. In the Include section of CC that foldername Willy2 is ""translated"" back to the full windows path C:\Documents and Settings\--user--\Mijn documenten.

 

So, it seems CC is aware of this and has come up with a workaround (One or more APIs in Windows and/or WE ??) to translate %localappdata% back the the appropriate full path. But is this ""translation"" confined to XP ?

 

Now I am getting more and more curious. Could you check the story above (text in italics) on your PC with Win 7 (??) ? And tell me what shows up in the Include section of CC ? It will certainly help you as well to get a better understanding of what's happening.

 

The lesson I learned from the conversation so far in this thread is that one should ALWAYS use systemvariables as much as possible. So, instead of e.g. C:\Program Files the user should use %Programfiles% in a customized Winsys.ini/Winapp.ini file. I already adapted my own CC *.ini files.

[putzend]

Hello Alan

Hello Willy2

 

Well, my cmd doesn't show anything about localappdata either and I have no idea why it is working.

On the other hand, program installers somehow must have a possibility to install at the correct place, without having localized the paths for 20 languages.

 

I searched the registry as suggested for appdata and found

File://%userappdata%\Microsoft and some other weird stuff.

 

Why don't you analyze the follwing

You should get the same result twice. You might have though to localize your path:

 

[Adobe9 Search localappdata]
LangSecRef=3021
Default=True
FileKey1=%localappdata%\Adobe\Acrobat\9.0\Cache\Search|*.*

 

[Adobe9 Search EN (DE)]
LangSecRef=3021
Default=True
;FileKey2=%userprofile%\Lokale Einstellungen\Anwendungsdaten\Adobe\Acrobat\9.0\Cache\Search|*.*
FileKey1=%userprofile%\Local Settings\Application Data\Adobe\Acrobat\9.0\Cache\Search|*.*

 

That's my Adobe search result folder, which is supposed to be found in the winapp.ini, but the original path (last line) doesn't work for my windows:

 

Embedded winapp.ini (version 3.2.4)

[Adobe Reader 9.0]
ID=2137
LangSecRef=3021
Detect=HKCU\Software\Adobe\Acrobat Reader\9.0\AVGeneral
Default=True
RegKey1=HKCU\Software\Adobe\Acrobat Reader\9.0\AVGeneral\cRecentFiles
FileKey1=%localappdata%\Adobe\Acrobat\9.0\Cache\Search90|*.*

 

There are in the embedded winapp.ini even some other %-stuff linked

FileKey1=%localappdata%\Apple Computer\QuickTime\downloads|*.*|RECURSE -->is found
FileKey2=%locallowappdata%\Apple Computer\quicktime\downloads|*.*|RECURSE -->probably Win7/Vista only
FileKey1=%commonappdata%\Symantec\Norton AntiVirus Corporate Edition\7.5\Logs|*.log
FileKey1=%commonappdata%\Spybot - Search & Destroy\Logs|*.* -->is found

Commonappdata is not available under cmd.

 

Well, next week I'll ask my scripting friend about %localappdata% and %commonappdata%, he probably knows the answer ;-)

[Alan_B]

Yep, you're right. I tried your example and my XP didn't recognize the systemvariable %localappdata% as well. So, it hasn't been declared at all. But Windows Explorer (WE) does recognize it (somehow).

I have just launched W.E. in Folders mode (i.e. folder tree on left and files on right.

It makes no difference whether I start with focus on the left or the right half of the screen,

when I select the address bar and paste into it, my results are :-

Success for %appdata%

Failure for %localappdata% + a pop-up which states "the parameter is incorrect"

Failure for %abcdefg% + a pop-up which states "the parameter is incorrect"

i.e. %localappdata% is just as un-known as the never defined and never used %abcdefg%

 

Perhaps something has tweaked either your P.C. or mine, so that you have success where I have failure.

 

Now I am getting more and more curious. Could you check the story above (text in italics) on your PC with Win 7 (??) ? And tell me what shows up in the Include section of CC ? It will certainly help you as well to get a better understanding of what's happening.

I will investigate, but at the moment W7 is not fit for purpose.

I have to finalise my script for removing the broken fragments of a failed Comodo installation so I can

Get rid of the emergency security patch in W7 of Norton,

and do a clean install of Comodo.

 

I find that Norton in W7 has exceeded its boundaries, and subverted my XP partition with its Comodo protection.

Whilst XP was bypassed and Comodo was OFF as W7 was running,

Norton under W7 seized the opportunity to plant in the "System Volume Information" of XP partition two booby traps,

a folder and a file.

When I Googled these items I found they were Norton things,

and I very quickly found most of the Google results were how to solve various system problems caused by these things.

 

I am looking forward to finding out how much Norton junk is left behind after using the Norton Removal Tool.

Until then I will minimise my use of W7 and the Norton invader.

 

Regards

Alan

[Alan_B]

Well, next week I'll ask my scripting friend about %localappdata% and %commonappdata%, he probably knows the answer ;-)

 

I am pleased to say I have no Adobe bloat so no part of my winapp2.ini uses Loacalappdata.

 

I look forward to seeing what your scripting friend tells you.

 

I wonder if M.$. has a special revenue stream from the sale of a special software developers kit,

which allows the developer to install stuff on the desired path regardless of the language.

Perhaps every time Windows is installed for a non-English language

there is also a hidden secret table with an English translation,

and by having access to that table an application can install to the correct path regardless of language.

 

Regards

Alan

[Aethec]

Try the shell: ones too. Such as shell:personal for My Documents, shell:local appdata (with a space!) for AppData\Local (or Local Settings\Application Data), shell:sendto for the SendTo folder, etc.

[Alan_B]

Try the shell: ones too. Such as shell:personal for My Documents, shell:local appdata (with a space!) for AppData\Local (or Local Settings\Application Data), shell:sendto for the SendTo folder, etc.

I thought I knew most of the commands I could give to CMD.EXE, and I hoped you had given me a new one.

Unfortunately not.

But I found that Start => Run => shell:local appdata launched Windows explorer at the right place.

 

Is it possible for a CMD.EXE script file to use shell:local appdata ?

I am tempted to try invoking it via rundll but this is not a good time to break my O.S. ! !

 

Alan

[Aethec]

It seems not. Too bad, since there are much, much, much more shell: path than environment variables.