AfxWin - a start

Testing the C-headers compatibility and, at the same time, writing some useful functions (at least for me) to retrieve Windows version information. Place the zipped files in the Afx subfolder of the Oxygen inc subfolder.

10 Oct 2018 - Added new functions.

[JRS]

José Roca Rocks!

A new BASIC beginning.

Added new functions, some using a workaround because of a bug in MID.

New file uploaded in the first post.

Notice that I always use unicode because it is superfluous to write both ansi and unicode versions.

[JRS]

You may be the first to give O2 a good unicode workover. Most of us are still ansi centric.

[José Roca]

Too many ansi cooks spoil the broth. The only ansi only function that remain in Windows is GetProcAddress. All the other "A" functions are mere wrappers that convert the ansi strings to unicode and call the "W" functions. Therefore, when using the Windows API, using Unicode is more efficient. These "A" wrappers were written for compatibility reasons with existing code. Current applications must be unicode and DPI aware.

[JRS]

That post deserves a Sticky.

I wonder how long the automatic conversion to Unicode has been in place. News to me.

I think Unicode and managed code (.Net) scared many Windows programmers away. It was my motivation to get into web programming.

[Aurel]

Therefore, when using the Windows API, using Unicode is more efficient

 
how is that possible?
do you can explain this?

[JRS]

Therefore, when using the Windows API, using Unicode is more efficient

 
how is that possible?
do you can explain this?

Please reread the post. Unicode is the default calling method. ANSI needs to be converted first before the call is made. Why it's faster.

There must have some functions with dual procedures, like some string manipulation functions in the shell, but the rule is to convert ansi parameters to unicode, call the unicode function, and convert strings back to ansi. For example:

Code: [Select]

/***********************************************************************
 *           GetShortPathNameA   (KERNEL32.@)
 */
DWORD WINAPI GetShortPathNameA( LPCSTR longpath, LPSTR shortpath, DWORD shortlen )
{
    WCHAR *longpathW;
    WCHAR shortpathW[MAX_PATH];
    DWORD ret;

    TRACE("%s\n", debugstr_a(longpath));

    if (!(longpathW = FILE_name_AtoW( longpath, FALSE ))) return 0;

    ret = GetShortPathNameW(longpathW, shortpathW, MAX_PATH);

    if (!ret) return 0;
    if (ret > MAX_PATH)
    {
        SetLastError(ERROR_FILENAME_EXCED_RANGE);
        return 0;
    }
    return copy_filename_WtoA( shortpathW, shortpath, shortlen );
}

And there are some recent procedures available only in unicode (they haven't bothered in writing an ansi wrapper).

> I wonder how long the automatic conversion to Unicode has been in place. News to me.

Since Windows NT.

See: https://msdn.microsoft.com/en-us/library/cc194797.aspx

Because the system is based on Unicode, Win32-based applications that use Unicode will run more efficiently on Windows NT and can process as many characters as the system can. This is especially true for programs localized for Far Eastern languages. Because the Windows NT system converts non-Unicode API parameters to Unicode at run time, not using Unicode adds a layer of overhead to some function calls and message processing. In addition, the system converts text returned from function calls to a local character set for non–Unicode-based applications, and information can be lost during the conversion because, like Windows 3.x, Windows NT supports only one local code page at a time. If the installed local code page is Latin 1 and the application calls GetLocaleInfoA to retrieve the Russian word for January, the system returns a string of question marks because there are no Cyrillic characters in the Latin 1 code page. A similar conversion process takes place for Windows messages and clipboard text.

This remembers me that many people use the integer functions of GDI+, instead of the float functions, thinking that they will be faster. But what it happens is that they are mere wrappers that call the float functions. Therefore, they are slightly slower because of the overhead.

[JRS]

This reminds me of how blind Microsoft can make you with their legacy wrappers.

[José Roca]

Even after knowing it, many people continues using ansi. It's like a superstititon.

[JRS]

Even after knowing it, many people continues using ansi. It's like a superstititon.

There are people still promoting the Z80 8 bit BASIC languages even today. 

[JRS]

José,

What are your thoughts about trying to use C header files as a default WinAPI?

I'm still assuming we would need your wrappers but creating them might not be so much work.

Well, Charles should enlighten us about what is supported and what is not, and the changes required.

I have made an small test and it works:

Code: [Select]

typedef sys HWND
typedef char* LPCSTR
typedef wchar* LPCWSTR
typedef dword uint

extern lib "user32.dll"
int MessageBoxA(HWND hWnd, LPCSTR lpText, LPCSTR lpCaption, UINT uType);
int MessageBoxW(HWND hWnd, LPCWSTR lpText, LPCWSTR lpCaption, UINT uType);
end extern

MessageBoxW 0, "Hello World", "declare", 0

We will have to write a base include file, that all the other header files will have to include directly or indirectly, with typedefs for all the Windows Data Types, e.g.

Code: [Select]

typedef sys HWND
typedef char* LPCSTR
typedef wchar* LPCWSTR
typedef dword uint

Windows Data Types: https://docs.microsoft.com/en-us/windows/desktop/winprog/windows-data-types

If a C data type is not defined, O2 does not report an error. What it does? It tries to guess it?