A good use for this Forum - Discuss Metro/WinRT

[Chris Boss]

Rather than make this forum a rehash of what is already on Jose's current forums, maybe it would be a good idea to start discussions on new topics where Jose would be a moderator and contributor.

IMO Jose may be one the best persons to lead a discussion about Metro and how to improve the PowerBasic compiler for building Metro applications.

Also his knowledge would help all of us to start digging into the WinRT, which is not only used in Metro apps, but I have read that WinRT can also be accessed by desktop apps.

So maybe add two new child forums to Joses Corner:

Metro Discussions

WinRT Discussions

[José Roca]

Sorry to disappoint you, but besides not having Windows 8, I don't know more about Metro applications than you, and I don't have any expertise with the languages currently available to develop them.

Regarding WinRT, if Bob has already read the scarce preliminary documentation, he already knows what is needed to do. It is more a problem of PBers not being yet used to use low-level COM that anything else.

I told Bob that having worked so hard to implement one of the best low-level COM support in any compiler, it is a crime that almost nobody is using it. So the purpose of this forum is to demonstrate that it is not so hard to use.

Contrarily to Automation servers, most low-level COM servers don't come with type libraries. Why? Because these servers can not be used by Automation languages and have to be used with direct interface calls. Therefore, you can't simply take a browser to generate the interface definitions, but have to be translated from the ones in the C++ headers, just as we have to do with standard function declares.

The PB includes don't provide any interface declarations; therefore, you can't use the low-level COM servers provided by Windows with them. Mine provide them, but there are differences in the translation of many of the declares that they have in common. Many that have tried them, have stopped at the first conflict, because having no good knowledge of the Windows API, don't know how to solve them, and others that only post in the PB Forums, prefer to use code that Semen or I wrote 8 or 10 years ago to no force the use of my includes. Anybody lurking this forum and seeing this kind of code still being used must thing that PB is an arcane compiler.

So I have modified my headers to wrap the differences with #IF/ENDIFs. The only gotcha is that the PB includes and mine can't be mixed. Maybe one day we will got one version of the PB IDE with provision for more than one set of include files and a menu option to easily switch between them.

My goal is that PBer's start to learn and use low-level COM. About 2/3 (a rough estimate) of the Windows 7 API are low-level COM servers and this proportion is only going to increase. If they don't, they won't be able to use any of the new technologies and WinRT will be the least of his problems.

[Chris Boss]

Well then, why not use this new forum to help the rest of us get up to speed with Powerbasic COM and then let those of us who do have Windows 8 try to put it into practical use for accessing the WinRT.

Maybe a child form entitled:

Prepare for WinRT by learning PB COM now

[Eric Pearson]

It's pretty hard to justify adding a subforum at this early date, when this is literally the one and only thread on the three existing ones. Let's see what our oh-so-competent friend José has in store for us before suggesting improvements.

I suspect that if Metro/etc. is a hot enough topic, for long enough, it could eventually earn a dedicated section. Until then, there's plenty of wide open space here, and an excellent host to guide us.

-- Eric

[José Roca]

Contrarily to Automation, low-level COM is quite similar to calling a function dynamically.

To call a function dynamically, what we do?

1. Call LoadLibrary to load a library module into the address space of the process. It successful, it increments the reference count of the library and returns an handle.

2. Call GetProcAddress to retrieve the address of the wanted function.

3. Use CALL DWORD to call he function directly and pass the parameters.

4. Call FreeLibrary to drecement the reference count. When the reference count reaches zero, the module is unloaded from the address space of the calling process and the handle is no longer valid.

COM is similar, but deals with a group of functions (called methods), and this agroupation is called an interface. Several interfaces can be grouped in a class.

1. Instead of calling LoadLibrary, we call CoCreateInstance (or the PB NEWCOM statement, that calls CoCreateInstance). CoCreateInstance calls LoadLibrary to load a library module into the address space of the process, but instead of returning the handle, it calls the CreateInstance method of an interface called IClassFactory, implemented in the COM server, and returns the address of a pointer (COM uses double indirection) to an array of DWORDs containing the addresses of all the methods that belong to the requested interface. This has a similar effect to what GetProcAdress does, but for a group of methods instead of a single function.

2. We use CALL DWORD to call the method, but as what we have is the address of a pointer to an array of pointers, instead of CALL DWORD pAdress, we have to use CALL DWORD @@pAdress[offset], where the offset is 0 for the first method, 4 for the second, 8 for the third and so on. Another particularity is that the first parameter passed is always this address to a pointer to the array of pointers, commonly know as pthis. To make it easier to use, instead of CALL DWORD @@pAdress[offset] USING <prototype declaration> <pthis, parameters>, we group the prototypes in an interface declaration and the compiler calculates the correct offset based on it. This allows to use pInterface.MethodName(parameters) instead of the more convoluted CALL DWORD @@pAdress[offset] USING <prototype declaration> <pthis, parameters>, but it does the same thing.

3. Instead of FreeLibrary, you set pInterface = NOTHING.

Events work as callback functions, but instead of passing a pointer to a single function, we group several related ones in a class and we pass a reference to this class.

The most important interface is IUnknown (all interfaces inherit ultimately from it), which has three methods: AddRef and Release to manage reference counting, and QueryInterface to navigate between the different interfaces implemented in the same class. You will see them being constantly used in C and other languages, but you don't need to call them with PB because it does it under the hood. However, it is important to know what they do.

[Steve Hutchesson]

That's an excellent description José, compliments.

[Patrice Terrier]

José--

I would like also to say thank you, for these descriptions helping us to understand how low level COM works.

[Eric Pearson]

I too have learned a great deal already! Thanks José !

[José Roca]

If I had talent for writing, I could have written a book of 1,950 pages and you wouldn't have understood anything and got the wrong impresion that low-level COM is a pain to learn, when in fact is pretty straightforward.

If you look at the declaration of a METHOD, you will see that it is the same that the one for a standard function:

METHOD GetBindOptions ( _                            ' VTable offset = 28
   BYREF pbindopts AS BIND_OPTS _                     ' __in BIND_OPTS * pbindopts
) AS LONG                                            ' HRESULT

In PB, we are using the keyword METHOD instead of FUNCTION, but only to avoid confussion. In C, it would be:

HRESULT STDMETHODCALLTYPE GetBindOptions(
            /* [out][in] */ BIND_OPTS *pbindopts)

You can also use with them all kind of data types and structures. Almost none of them uses VARIANTs and SAFEARRAYs because they aren't needed. To pass an array, you simply do the same that with a standard C function: to pass a pointer to the first element of the array and the number of elements of the array.

Anybody that already knows how to use the Windows API has much of the way traveled.

[Theo Gottwald]

Maybe one day we will got one version of the PB IDE with provision for more than one set of include files and a menu option to easily switch between them.

While this would be a next step, the PB IDE already is not so far from that as we can already move INCLUDE sets up or down in the includes list.
And the include set that is up is taken. I found myself doing that quite often, trying which include set was the right for an old project.

Therefore what I would prefer is not a change in the IDE but a Meta-statement in the compiler to override the IDE.Setting, like the one in CSED.
As its the compiler that uses the "Include Path" at the end, thsource code is the right place where it should be,

$CSED_INCPATH = "E:\...\pbwin10\WINAPI_IV"

Only informations that are in the source code are backup'ed with the source code.

If the setting are in the IDE, how will you know in several years, when the next PB is on the market,
which set of includes the old project has used?

[Anabelle Mills]

I've been watching this thread for a while, it's useful to me since I'm only a beginner in this subject - it helps me learn and figure everything out. Thanks for sharing your expertise, guys!

[Rick McNeely]

I've been trying COM for a while now. Mainly by stealing Jose's code and modifying to suit. I really appreciate all of the guidance that he and others are willing to provide. The learning curve on COM seems a little steeper than most technologies. Just have to keep pushing.