can I setup some kind of environment variable with UNC that reply WNetGetUniversalNameA windows api function ?
Regards,
Martin
UNC environmental variable
-
olivierfrdierick
- Level 5
- Posts: 258
- Joined: Thu Sep 13, 2012 12:09 pm
Re: UNC environmental variable
I think you had a proper answer to your UNC issues already in your previous topic.
Please make any follow up to your issue in the existing topic, thanks.
There's no variable that I know of that can change the behaviour of an API function inside Wine.
Source: WineHQ Forums - View topic - UNC path related problem
Please make any follow up to your issue in the existing topic, thanks.
There's no variable that I know of that can change the behaviour of an API function inside Wine.
Source: WineHQ Forums - View topic - UNC path related problem
Re: UNC environmental variable
tinoper as olivierfrdierick point you to my prior that UNC in wine is very badly implmented. But there is something worse here.
There is another issue here.
No application should be using WNetGetUniversalNameA but instead should be using WNetGetUniversalNameW. What is important difference here. UNC is in fact UNICODE. What happens when WNetGetUniversalNameA result is a UNC address containing a non ANSI char exactly the same as how wine stub responds no string.
Microsoft implemented ANSI forms of stacks of functions that make absolutely no sense and any developer using them needs to be told hey this function is stupid and it will break your program on some of your users. Implementation insanity that every Uncode function has to have a Ansi one even if the Ansi one will random-ally break. Even new functions in Windows 8.1 have Ansi versions on functions that source data is Unicode and will do the wrong things at times.
I can see reasons to implement WNetGetUniversalNameW but I see very limit reason to implement WNetGetUniversalNameA when its insane to use it, In fact if WNetGetUniversalNameA was ever implemented it would be worth leaving a FIXME message to report to author of program they have stuffed it and used a invalid function.
This might be a case of wine forwarding on because WNetGetUniversalNameW is not implemented if it not the maker of the program needs a patch requested.
Wine registry would be where the setting data would go if the function worked tinoper. The fact of the matter is not a implemented function.
There is another issue here.
No application should be using WNetGetUniversalNameA but instead should be using WNetGetUniversalNameW. What is important difference here. UNC is in fact UNICODE. What happens when WNetGetUniversalNameA result is a UNC address containing a non ANSI char exactly the same as how wine stub responds no string.
Microsoft implemented ANSI forms of stacks of functions that make absolutely no sense and any developer using them needs to be told hey this function is stupid and it will break your program on some of your users. Implementation insanity that every Uncode function has to have a Ansi one even if the Ansi one will random-ally break. Even new functions in Windows 8.1 have Ansi versions on functions that source data is Unicode and will do the wrong things at times.
I can see reasons to implement WNetGetUniversalNameW but I see very limit reason to implement WNetGetUniversalNameA when its insane to use it, In fact if WNetGetUniversalNameA was ever implemented it would be worth leaving a FIXME message to report to author of program they have stuffed it and used a invalid function.
This might be a case of wine forwarding on because WNetGetUniversalNameW is not implemented if it not the maker of the program needs a patch requested.
Wine registry would be where the setting data would go if the function worked tinoper. The fact of the matter is not a implemented function.
