Unicode vs Ascii API calls

[Paul Dwyer]

The solution to international coding lies in some work.

MS has done it on their part, in MS C++ if you use an ifDef statement for unicode then the one piece of code will comepile for either. The reason for this is simple.

For example, if nothing is specified then:

Messagebox() is MessageboxA() but IfDef Unicode then
Messagebox() is MessageboxW() so all you have to do is add the IfDef to the start of your code and your done! (sort of)

but in PB there are no includes for unicode so you can't do this. and even if your combined my include with PB's you'd be screwed because of the PB syntax.

If you use a LEN() command one an ASCIIZ type it will return the count till the first Chr$(0) so "Hello" in unicode will return 1 as the length "H" I use a unicode.inc include which has uLEN(), Strcpy(), StrCat(), etc to get around this but I am far from finished. Where possible I have used arrays of Words as per the C++ wChar Type.

To finally answer your question.
If your write code based on unicode, you will find (depending on your code) that it may not run under 95, 98 and ME
But, the reverse is also true. You will notice that MS release a '95 and NT version of IE where as Netscape released just one. This was the reason.

You could write an app to detect the OS and run appropriately but this would be excessive, the best solution in PB is unfortunately to flush international coding down the the TOO hard basket toilet, as the extra effort is a pain. under MS c++ you write your app, you compile it twice and release a win95-98-ME version and an NT-2K version. The OS's are different, so should your code be.

What I am trying to do (slowly because My IT profession is not programming so I'm busy) is bring to PB a proper guide for international code. Feel free to help.

The goal will be to identify non unicode compliant functions (Len, left, right, mid etc) and build new ones (thise is where C excels over basic (not just PB) these are not built in and can be overwritten. Re-organise the win32api,inc into ifDefs so you can specify which type to use, and untimately (and this is a long way off) use the same code base for ascii or uncode so that there will be no excuse for non international applications

Here endith the lesson

Amen




------------------

Paul Dwyer
Network Engineer
Aussie in Tokyo
(Paul282 at VB-World)

[Lance Edmonds]

If your code implicitly loads a [system] DLL (ie, load-time linking) on an O/S that does not support the given Unicode functions, Windows will throw a "Missing Export" error and refuse to run the app.

Using Explicit (run-time linking using LoadLibrary(), GetProcAddress(), CALL DWORD, FreeLibrary(), etc) will enable your app to load and run, where upon your code can query the availability of a given Unicode function and call it if it is available.

Windows 95a has very few Unicode functions available compared with NT/2000.

For more information, consult one of the Windows programming "bibles" that are often touted on this BBS.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Wayne Diamond]

Thanks for the insight Paul - I noticed your unicode version of win32api.inc in the source code forum, but my question remains - if I distribute a program based on this code, would I have to have both an A and W version? If so, is there any way to detect whether to call it as ascii or unicode ???


------------------

[Paul Dwyer]

Unicode is the native format for NT 2000. occassionally you have to use it (like to add users to an nt domain etc)
however 95-98 support for unicode is poor but not non-existant.

I have posts an inc file for the unicode API's in the source code dir if your want it.

<Opportunity to jab the americans >
Often US Software houses are particularly poor when it comes to international programming so they take the shortcut of exclusively using ascii calls. because of this I can't use software like winzip on my english win2k system because whenever it reads a unicode filename it crashes.

Yes, it's a bit more effort
yes, your exe will be a bit larger

but in my opinion (which is only minority in the US) international software is better software

<End of spiel>

sorry if I didn't really answer your question, I got a bit carried away

------------------

Paul Dwyer
Network Engineer
Aussie in Tokyo
(Paul282 at VB-World)

[Wayne Diamond]

I while ago I downloaded a VB demo that had an Ascii function:

 Public Function IShellExecuteHook[b]A[/b]_Execute(ByVal This As Object, pei As shlext.SHELLEXECUTEINFO2) As Long

It wasn't working properly on my NT4 workstation so I wrote to the author and he replied back instructing me to change the A to a W to change it from Ascii from Unicode - that fixed the problem.

My question is... if I distribute a program based on this code, would I have to have both an A and W version? If so, is there any way to detect whether to call it as ascii or unicode ??? Seemingly the A version works on the authors system while the W version works on mine

I've never really had to call any unicode APIs before other than that one, so any insight to this is very much appreciated


------------------