unicode versions of IPC_GET<file> apis

[TheSaw]

Winamp should have a unicode way to get the ini file / directory... it really complicates things sideways without it

[DrO]

will look to getting a patch submitted to have unicode versions of of the filepath api's available (though a MultiByteToWideChar(..) isn't that hard to add in)

-daz

[TheSaw]

MultiByteToWideChar(..) is useless, because it does not support actual unicode characters, and yes, many users reported that they have unicode characters in the ini file path.

[DrO]

the following should work in the next public release as direct unicode equivalents of the ansi versions (though i've still to finish converting and checking i've not broken anything in the changes):#define IPC_GETINIFILEW 1334
#define IPC_GETINIDIRECTORYW 1335
#define IPC_GETPLUGINDIRECTORYW 1336many users reported that they have unicode characters in the ini file pathif there issues then i've missed them or they've not been reported properly as there shouldn't be a reason for that to happen when it's been using the correct OS api's which should have been converting the paths to 8.3 format where applicable (when then makes MultiByteToWideChar(..) a relatively safe to be doing from what i understand).

i'll split these posts out shortly as it's not key to the discussion of the language example.

-daz

[SilverBird775]

But DrO, do those pathes storing internally in unicode or in ansi? How the winamp itself opening the ini path?

If the path is ansi by design then it makes a little sense convering it to unicode. In any outcome the plugins need the alternate way for ansi to unicode conversion for erlier winamp versions. If the winamp is actually using the unicode pathes internally then it would worth to have the two alternative routines in the plugin, the one for true unicode support and another one for the outdated ansi to unicode approach. If the winamp operate in ansi then IPC_*W definitions are simply confusing.

[DrO]

all i'll say at the moment is that once i've finished working through everything in winamp.exe then the new ones will be true unicode paths and Winamp will be using them correctly as well.

all existing apis will still be in place and will be down converted (if need be into an 8.3 format so it'll work - this is done on the playlist entries when required from what i remember).

as for how it is in the current clietns, some are true unicode already and are converted down where required (like the m3u one) and others are ansi from the relevant OS api's like using the 8.3 filename where required and then converted up to unicode when required (as if the path works in ansi then a conversion shouldn't cause issues). is just a vestigial issue from the player being ansi only that has been tinkered with as and when it can be (as i'm doing this off my own back which is sort of stupid but nevermind).

[edit]
and to round things off from some other requests i've had from people, i've also added in the following (though it's relatively simple to get them from winamp.ini):
#define IPC_GETVISDIRECTORYW 339
#define IPC_GETSKINDIRECTORYW 340
#define IPC_GETDSPDIRECTORYW 341-daz

[TheSaw]

Well I'm not sure how 8.3 filenames would help, but as long as I was using the non-unicode API to get the ini paths everything was fine, but many users had their real names as the Windows user, and non-english names often have unicode characters, so the %appdata% paths all had unicode characters in them, so i had to do that workaround I was asking about, but obviously, it wasn't as effective, and it complicated, etc :)

[DrO]

the current apis were all designed to cope with weird user account names as the multi-user support was implemented before Winamp ever started to support unicode so it would work correctly either with the ansi full path or if that wasn't right then the OS api's used would convert it to a 8.3 formatted path which is guaranteed to work (so even if i'd just unicodified the ansi string then things should still have worked). however the implementation has been swapped over to unicode apis in all cases so unless something goes wonky then the inipath should show as per what the user see's in Explorer, etc.

alas as you're having to generate the path externally at times (from what i remember) then that'd explain some of the failures you'd been seeing (is part of why i'm interested to compile the plug-in completely as there's a few things which don't seem right with it when pawel has made me test it).

-daz

[TheSaw]

Okay, I'll wait then, and will put all files needed to compile, Tuesday.

[TheSaw]

And here it is: Download (http://win7shell.googlecode.com/files/gen_win7shell.zip)