64 bit COM programing with PluriBASIC

[Brian Alvarez]

 Now that i have some major areas of PluriBASIC for 64 bit complete, I would like to get COM programming done.

I know the basics of COM programming, but i dont know how to emulate things in Oxygen, or if it is possible at all. I would like
to be able to create advanced and complex COM applications.

PluriBASIC can now compile 64bit applications with Oxygen, and it can also use most of Jose Roca's includes to do so. Parsing COM
classes is no problem, but i dont know how to emulate them in Oxygen.

So, i am summoning the Oxygen and COM gurus out there.

I would like to support:

• Creating COM clients.
• Creating COM server applications, including (of course) notifications and listeners.
• Supporrt COM classes.
• Support COM statements for object creation.
• Compilation of existing code + New and easier ways to do things.

I dont know if 64 bit COM programming is different than 32 bit COM programming either (if required).

Anobody wants to play?

[Brian Alvarez]

By the way, VARIANT variables already work fine for the most common data types and can be enhanced for more.

[Brian Alvarez]

PluriBASIC + Oxygen currently supports:

VARIANTVT
VARIANT$
VARIANT$$
VARIANT#

And sintax like:

LOCAL V AS VARIANT

V = "Some text"

? VARIANT$(V)
? STR$(VARIANTVT(V))   ' Messagebox displays 8, which is %VT_BSTR

The internal Variant header is standard.

The Following commands are there but need some code inside:

Code Select Expand

GUID$
GUID$$
GUIDTXT$
CLSID$

These statements are also valid:

LET V = SomeUDT AS STRING

SomeUDT = VARIANT$(BYTE, V)

Added:
All VARIANT's bstrings are cleared when the variable goes out of scope too.

Added:
Also, VARPTR works fine with variants. Declaring VARIANT's as PTR works too

LOCAL V AS VARIANT PTR

V = ADDRESS

? STR$(VARIANTVT(@V))

[Mike Lobanovsky]

PluriBASIC can now compile 64bit applications with Oxygen ...

Brian,

With all my respect for your indie effort to keep PowerBASIC afloat in the absence of its historical captain(s), so far it's been only your own words to testify that PluriBASIC is capable of doing just what you say it can do -- to any significant degree of proficiency.

Where, how, on what conditions, and at what price can I get me a copy of PluriBASIC to run my own insider tests to assert its compatibility with its prototype?

... and it can also use most of Jose Roca's includes to do so.

Are you perfectly sure that would be in line with Jose's own policies regarding the legitimacy of use of his header files in any paradigm other than PowerBASIC and FreeBASIC alone? I do not see either PluriBASIC or OxygenBasic on that very short list of legit uses.

Until the above issues are addressed and resolved successfully, I'm afraid your attempt at

... summoning the Oxygen and COM gurus out there. ... Anobody wants to play?

is likely to be negative, especially in view of, alas, a very limited number of O2 users in the first place.

[Brian Alvarez]

 Hello mike, PluriBASIC is capable of doing what i said, with the tools i said. I guess i am the only one 100% sure that there is nothing more required than my word.

Are you perfectly sure that would be in line with Jose's own policies regarding the legitimacy of use of his header files in any paradigm other than PowerBASIC and FreeBASIC alone?

No. To be honest I have to admit I am guilty of not taking the time to see what the headers were permited for... My apologies to Jose. But i hope that is not an impediment for getting permission to. Otherwise I will not have any other option than, not using them. My intentions were not to break any rules (otherwise i would not have said that so openly), my intentions were an attempt to say "hey, we are going somewhere with this!".

In fact, PluriBASIC has its own set of "headers" which it includes when it detects that some feature has been used. Automatically. Those are not complete though.

[Brian Alvarez]

Where, how, on what conditions, and at what price can I get me a copy of PluriBASIC to run my own insider tests to assert its compatibility with its prototype?

Only time will tell... But i hope this becomes available to everybody, with a reasonable price and with the conditions we are used to.

You could get it today if you purchase the whole project rights though.

[Mike Lobanovsky]

Hello mike, PluriBASIC is capable of doing what i said, with the tools i said. I guess i am the only one 100% sure that there is nothing more required than my word.

To be honest I have to admit I am guilty of not taking the time to see what the headers were permited for...

Quod erat demonstrandum.

And please, Brian, -- my name is Mike, M-i-k-e with a capital M, not mike or mIKE or mIkE or whatever else your Siri thinks it may be.

Thank you!


P.S.

You could get it today if you purchase the whole project rights though.

Oh no, that would be too generous. I am not particularly interested in PB 5- capabilities or options. I might have professional interest in, and/or uses for, 32-bit PowerBASIC and 64-bit OxygenBasic but kiddie's-first-gadget environments are certainly beyond my scope.

[Brian Alvarez]

 My apologies Mike, but i usually dont have time to check my grammar.

So, I request for your advanced indulgence to my human mistakes and my sticky
SHIFT key without getting all offended. Not my intention.

What makes you think this is a "kiddie's-first-gadget" environment? I mean,
you havent even used it and I (despite my efforts) have barely explained the surface
of what it can do...

May I get offended too?

[Mike Lobanovsky]

My apologies Mike

Accepted.

May I get offended too?

You shouldn't. Evidently I failed to make myself clear: it isn't PluriBASIC that's beyond my sphere of interest, it's the "kiddie's-first-gadget" environments that PluriBASIC v5 generates its output for that don't ring the bell for me.

My bad, even if unintentional.

[José Roca]

@Brian,

I don't understand why you want to use my headers for PowerBasic if they aren't useful for 64-bit compiling. What I'm missing?

If your tool will allow to write applications using the PowerBasic syntax, but O2 as the backend compiler, then who is going to buy PowerBasic?

> I dont know if 64 bit COM programming is different than 32 bit COM programming

The same differences as with the Windows API: pointers are 64-bit, etc.

[Chris Chancellor]

Jose said

If your tool will allow to write applications using the PowerBasic syntax, but O2 as the backend compiler, then who is going to buy PowerBasic?

look at the bright side, Jose  :
Brian  and Charles should form an alliance with Drake to push out  an  OxygenPower Basic  64 bits compiler
which a lot of programmers needed to convert from 32bit to 64bit

Sell this joint venture compiler out to everyone which will be rewarding to all the Basic programmers worldwide
My boss is willing to pay to buy this compiler

[José Roca]

You are a dreamer.

[Brian Alvarez]

I don't understand why you want to use my headers for PowerBasic if they aren't useful for 64-bit compiling.

Hello Jose. Certainly the headers need a small change to be completely usable for 64 bit compilations. Thats why i said i have been using only portions of your headers.

What I'm missing?

There is a SYS data type in Oxygen. The size of the SYS datatype is target dependant and the same syntax can be used for compiling applications with 32 bit address pointers or 64 bit address pointers. It would be just a matter of using target dependent address pointers where needed, and carefully using DWORD's and LONG's where needed. I dont know exactly at what extent is this possible, or if internally the windows API is completely consistent with this.

So, by defining a lot of conditional compiling + the use of the SYS datatype, your headers can be very usable also for 64 bit compilations. Not right now, of course, at least not with a small change that for the moment PluriBASIC and Oxygen are doing.

If your tool will allow to write applications using the PowerBasic syntax, but O2 as the backend compiler, then who is going to buy PowerBasic?

Exactly the same people that will buy it if the things continue as they are going right now.

Actually, i am not against Chris' idea, i think it could benefit all of us. I believe that when more than 1 person has a personal interest in a project to flourish, there are more chances of achieving this. Also, the future of the compiler has more guarantees than when only one person is developing it. But i kind of agree with you, this is probably day dreaming, because a 64 bit version of PowerBASIC could appear any moment... I don't know, maybe.

[José Roca]

I think that the remaining PB users have convinced themselves that they don't need a 64-bit compiler, that they won't get anyway because the inversion needed to produce one will never be recovered and I don't think that the Drakes will work for the fun.

[Brian Alvarez]

 I dont know Jose, I think its like when someone says "I didnt want it anyways" just because they
know they cant have it, but as soon as the opportunity appears, they hold on to it like a limpet.
No offense intended to my fellow programmers, of course. I know that, because I would. 

Maybe I should start a fundraiser. If it gets to a reasonable quantity (lets say 50 licenses), I quit
my job, and continue, otherwise, the money goes back to the investors.

I need it to continue anyway. Otherwise I will have to go back to my regular job once these free
weeks end. Last time i had some few weeks was back in april and may i think. At the current step
im going to finish it by 2030.