PB internal libraries use the same "user libraries" system. Compiled lib (.lib/.obj) and a description file (.desc) compiled intomarroh wrote:And your other reasons like "... or when developping an user lib (everybody is unicode)" I feel as void because user libs in pb was no topic since x years. Not because the unicode / ascii thing, because the win / mac / linux thing.
a PureBasic library. It seems like they write at least 4 functions in C for every PB function:
- Function()
- Function_Debug()
- Function_Unicode()
- Function_Unicode_Debug().
As far as I understand that's the main reason for removing Ascii support. 2 out of 4 above functions
could be eliminated and built-times are faster, too.
Making low-level-API PB-Libs for Ascii and Unicode is not always as easy as with PB, where you only check
"[X] Create Unicode executable", and everything just works, if coded properly.
AFAIK many new programming languages (last 15 years) are UNICODE only by default (like .NET),marroh wrote:I think remove the ascii support makes PB definitely NOT modern.
so I think it is not a big problem for most people.
I remember one console application where I had to use ASCII mode explicitly, because it didn't work
otherwise. Most external console apps are ASCII only, and some have problems with UNICODE pipe stuff
or something like that. Beside that, I did always write everything for UNICODE and ASCII mode for
some years, including writing big wrappers for external libraries/DLLs, and it was never a big problem
by using all possibilities (including pseudo-types like p-ascii and p-utf8). Most of the bugs with
this stuff should be fixed already.