Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: SDK - ANSI configuration (Read 4138 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

SDK - ANSI configuration

How to build SDK Release ANSI? There is no such configuration in DSP file.

SDK - ANSI configuration

Reply #1 –
That should not matter.

SDK - ANSI configuration

Reply #2 –
all right,
I just have to manually add sdk lib link to my project (dependecy doesn't work)

SDK - ANSI configuration

Reply #3 –
Why does your project have a Release ANSI configuration? Can you rename it to Release?

SDK - ANSI configuration

Reply #4 –
Quote
Why does your project have a Release ANSI configuration? Can you rename it to Release?

does it mean that we have now ANSI version of foobar 2000 only? (no splitted ANSI and UNICODE version?)

SDK - ANSI configuration

Reply #5 –
It rather means that foobar itself is neither ANSII nor UNICODE. All "charset-aware" functions were moved to separate library (utf8api.dll) and only this library has different compiles (ANSII or UNICODE).

Instead of using ANSI/Unicode specific functions in your plugin, use wrappers defined in utf8api (eg. instead of SendMessage, use uSendMessage etc.) and make your code dependent on utf8api. If some function you need is missing from utf8api, either request for it or use:

if(IsUnicode()) {
// unicode version of the code

} else {
// ansii version

}

SDK - ANSI configuration

Reply #6 –
Quote
It rather means that foobar itself is neither ANSII nor UNICODE. All "charset-aware" functions were moved to separate library (utf8api.dll) and only this library has different compiles (ANSII or UNICODE).

Instead of using ANSI/Unicode specific functions in your plugin, use wrappers defined in utf8api (eg. instead of SendMessage, use uSendMessage etc.) and make your code dependent on utf8api. If some function you need is missing from utf8api, either request for it or use:

if(IsUnicode()) {
// unicode version of the code

} else {
// ansii version

}

I see

SDK - ANSI configuration

Reply #7 –
There are also various string conversion classes that you can find in PFC, such as string_os_from_utf8, automatically defined to string_ansi_from_utf8 or string_utf16_from_utf8 depending on your build target. Or, if you actually need runtime detection, you can use those classes directly.

I already use string_os_from_utf8 and string_utf8_from_os in my 7-Zip unpacker, as the Release target is compiled Unicode for 7-Zip itself. I'll have to upload my very minor modifications to 7-Zip, since it is LGPL. (Wow, I changed all lstrlen to _tcslen, and forced CreateEvent into CreateEventA with NULL name. I'm sure the main project could really use my modifications.)

SDK - ANSI configuration

Reply #8 –
thanks