Issue with path
Posted: Tue Oct 04, 2022 2:01 pm
Yes sir, big t.
Page 4 of 4
Issue with path
Posted: Tue Oct 04, 2022 2:17 pm
Be careful Rocky. Don't push too hard. You don't know who you are dealing with.
Issue with path
Posted: Tue Oct 04, 2022 4:08 pm
Don't worry. We go way back.
Issue with path
Posted: Wed Oct 05, 2022 11:08 am
Issue with path
Posted: Wed Oct 05, 2022 12:46 pm
Thank you for the follow-up. Curly heaved a sigh of relief. 
Maybe we should make the UTF-8 manifest the default?
Maybe we should make the UTF-8 manifest the default?
Issue with path
Posted: Wed Oct 05, 2022 1:45 pm
Issue with path
Posted: Wed Oct 05, 2022 5:16 pm
Make it the default only for smart people.
Issue with path
Posted: Wed Oct 05, 2022 5:17 pm
Me too.
Issue with path
Posted: Wed Oct 05, 2022 5:25 pm
I don't need any support anywhere, you can see. 
Issue with path
Posted: Wed Oct 05, 2022 5:31 pm
Issue with path
Posted: Sun Dec 03, 2023 5:54 am
Nice doggie. Stay there.
The method being used by ffms2/directshowsource et al is to use wide characters internally in the code. Then use conversion routines to convert the incoming encoding to wide character, e.g., MultiByteToWideChar(). pinterf just modified DirectShowSource() to take a parameter utf8 to signal use of these routines. So before invoking your application you need to know and tell what your encoding is. I believe ffms2 may try to determine that automatically but I haven't checked the code. I doubt there is a way to reliably do that. You can't expect a BOM because often it is not used and as you'll see in the article linked below, BOMs are not a good idea. Anyway, for pinterf's stuff the app must be notified, i.e., there is an effective configuration of whether to use UTF8 or not. When not, the system locale codepage is used. The same is true for DGDecNV. You configure UTF8 or not by which manifest you enable. Typically people are not switching modes every 5 minutes. They run in one mode on their system. The manifest method is very clean and simple and does not require internal wide character to be implemented. DGDecNV then uses UTF8 internally and doesn't require all the fraught conversion routines with their corner cases and error exceptions, etc. To do a MultiByteToWideChar() conversion safely you have to call it twice, once to get the needed buffer size and again to do the conversion. And you have to look after allocating/freeing memory and making sure the strings are correctly terminated. This internal wide character solution is nutso, while running UTF8 internally is so easy. I've posted this before but here it is again, a concise case for internal UTF8.
https://utf8everywhere.org/
The section on how to do unicode text on windows (Section 10) is now obsolete as it is no longer true that "The problem with Windows platform is that it does not (yet) support Unicode-compatible narrow string system APIs." Windows supports UTF8 directly now, either through the infamous "beta" setting or through a manifest.
See here for an example of the muck you get involved with when trying to use the internal wide character approach. Just what we need in our applications. Not!
https://ravenspoint.wordpress.com/2010/ ... haracters/
Initially, the author couldn't even get it right, and had to be corrected by the commenters. And the author acknowledges that it is windows-specific. Crazy.
One thing that could be considered for DGDecNV, if frequent changes are needed, is to provide a little quick manifest switcher utility. Want UTF, run 'setutf8'. Want system locale, run 'setsl'. Nobody has ever asked for such a thing or complained that switching is currently too hard, but Sherman said he'd make that utility if we want. Go for it, Sherm!
The method being used by ffms2/directshowsource et al is to use wide characters internally in the code. Then use conversion routines to convert the incoming encoding to wide character, e.g., MultiByteToWideChar(). pinterf just modified DirectShowSource() to take a parameter utf8 to signal use of these routines. So before invoking your application you need to know and tell what your encoding is. I believe ffms2 may try to determine that automatically but I haven't checked the code. I doubt there is a way to reliably do that. You can't expect a BOM because often it is not used and as you'll see in the article linked below, BOMs are not a good idea. Anyway, for pinterf's stuff the app must be notified, i.e., there is an effective configuration of whether to use UTF8 or not. When not, the system locale codepage is used. The same is true for DGDecNV. You configure UTF8 or not by which manifest you enable. Typically people are not switching modes every 5 minutes. They run in one mode on their system. The manifest method is very clean and simple and does not require internal wide character to be implemented. DGDecNV then uses UTF8 internally and doesn't require all the fraught conversion routines with their corner cases and error exceptions, etc. To do a MultiByteToWideChar() conversion safely you have to call it twice, once to get the needed buffer size and again to do the conversion. And you have to look after allocating/freeing memory and making sure the strings are correctly terminated. This internal wide character solution is nutso, while running UTF8 internally is so easy. I've posted this before but here it is again, a concise case for internal UTF8.
https://utf8everywhere.org/
The section on how to do unicode text on windows (Section 10) is now obsolete as it is no longer true that "The problem with Windows platform is that it does not (yet) support Unicode-compatible narrow string system APIs." Windows supports UTF8 directly now, either through the infamous "beta" setting or through a manifest.
See here for an example of the muck you get involved with when trying to use the internal wide character approach. Just what we need in our applications. Not!
https://ravenspoint.wordpress.com/2010/ ... haracters/
Initially, the author couldn't even get it right, and had to be corrected by the commenters. And the author acknowledges that it is windows-specific. Crazy.
One thing that could be considered for DGDecNV, if frequent changes are needed, is to provide a little quick manifest switcher utility. Want UTF, run 'setutf8'. Want system locale, run 'setsl'. Nobody has ever asked for such a thing or complained that switching is currently too hard, but Sherman said he'd make that utility if we want. Go for it, Sherm!
Issue with path
Posted: Tue Dec 05, 2023 12:23 pm
Issue with path
Posted: Tue Dec 05, 2023 12:32 pm
u cud get a+
Issue with path
Posted: Tue Dec 05, 2023 12:41 pm
All reference frames are valid.
Issue with path
Posted: Tue Dec 05, 2023 1:08 pm
All is calm, all is bright.