Announcement

**Sven Blumenstein** · 26 Jun 2001, 02:19 PM

Just one wish:
-static libraries (.lib's )

------------------
E-Mail (home): mailto:[email protected][email protected]</A>
E-Mail (work): mailto:[email protected][email protected]</A>

**Josh Forster** · 27 Jun 2001, 03:49 AM

Originally posted by Jim Barber:
(2) COM
Ducking and running,

Jim Barber

I'm curious. Why would you want COM support, when it will soon be the "legacy" component architecture?

Josh

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

[This message has been edited by Josh Forster (edited June 27, 2001).]

**Jim Barber** · 27 Jun 2001, 04:43 AM

Josh,

>I'm curious. Why would you want COM support, when it
>will soon be the "legacy" component architecture?

My uses for COM aren't limited to controls. For example,
I'm doing more and more DirectSound work for clients, (as
opposed to using the MMSYSTEM API) and the only reasonable
choice at the moment is to use C++. I can't say that my clients
would accept PB binaries, but if PB never supports COM and
64-bit FP register optimization, we'll never have the
opportunity to find out, either. Ditto for the remainder
of DirectX, and it's hard to say (with a straight face) that
there's no money in game programming. I don't normally write
code for games, but I have a suspicion that those that do
won't be doing so in C# or Visual Fred. Unmanaged C++,
yes, but why not in PB? Not today, but we'll have to see
what the Mum Floridians have gotten around to by the time
they get around to it.

As for COM being a legacy item, well, just about anything
MS does is "legacy" the instant it suits them. They've
exposed enough COM in latter-day Windows that I find it
unlikely it'll go away any time soon.

My .02 ,
Jim Barber

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

**Wayne Diamond** · 27 Jun 2001, 05:12 AM

Hmm, well, seeing as i havent put forward anything to the wish list yet and Ive got 2 minutes to kill, I'd love to be able to have preprocessor functions such as #PREPROCESS and #POSTPROCESS which get executed before/after compiling
eg. sommit like this:

Code:

#COMPILE EXE
#PREPROCESS SHELL "preproc.exe " & SourceBas
#POSTPROCESS SHELL "postproc.exe " & CompiledExe

so when you compile it, preproc.exe will be invoked first, when that finishes the compiler does its stuff, an when its all done postproc.exe gets invoked
I'd also like to use #PREPROCESS to encrypt strings etc in the actual source code before compiling, and #POSTPROCESS to decrypt back to original

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

**Eric Pearson** · 27 Jun 2001, 05:31 AM

Josh --

> I'm curious. Why would you want COM support,
> when it will soon be the "legacy" component
> architecture?

Sorry, but IMO that mindset is a direct result of Microsoft hype. And of a basic misunderstanding about .NET, which is based on the next generation of COM. It's easy to get confused by Microsoft's frequent name changes... OLE, OLE2, ActiveX, COM, COM+, DCOM... They are all just different generations of the same technology. And in many cases the differences are minor, more like 1.00 and 1.10 than 1.00 and 2.00!

COM technology is no more "legacy" architecture than DLLs are! The entire Windows operating system -- every single core API -- is located in a DLL, and will be for many versions to come. Are DLLs "out of date" technology? Or are they just out of style? I have never been one to wear certain clothes because the current "fashion" says that I should, and I don't choose my technology that way either. I use what works for me.

The same is true for COM. COM is a well-established, widely-used technology, and dismissing it because it isn't "the latest and greatest from Microsoft" is a very serious mistake, IMO.

That's especially true considering that Microsoft's new paradigm is getting a less than enthusiastic reception, and many programmers are likely to delay implementing it. .NET 1.00 isn't even out of beta yet, and I'll bet that 2.00 will be significantly different. Would you prefer that PB jump directly to a technology that may be significantly changed next year, or the year after that?

I for one would applaud LOUDLY if PowerBASIC For Windows had native support for COM.

-- Eric

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[This message has been edited by Eric Pearson (edited June 27, 2001).]

**Philippe Monteil** · 27 Jun 2001, 09:45 AM

I fully agree with Eric. Not to mention that .NET classes
are automatically exposed as COM components, and that .NET application
see COM components as native .NET classes.

Making PB COM client capable would let PB developers use .NET classes seamlessly.

A COM server capable PB version would make possible to build components
directly usable in .NET applications.

Philippe Monteil
JAZZAge Software

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

**Brent Eldstrom** · 27 Jun 2001, 10:25 AM

I absolutely agree with putting native COM support into PB. I've been using PB since it was released and the lack of native COM support has severely limited it's use in my company. I'm heavily into .NET and I see PB as a very important addition to my toolkit when it supports COM natively. PB COM DLLs would be the 'Unmanaged' high performance components in my .NET applications.

Brent Eldstrom
Custom Software Solutions Inc.

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

**Don Dickinson** · 27 Jun 2001, 02:09 PM

Ditto to what eric and phillipe said. COM (by whatever name) is becoming more pervasive (like it or not). More APIs are becoming COM based (e.g. directx) instead of straight DLL based with every upgrade.
--Don

------------------
dickinson.basicguru.com

**Josh Forster** · 28 Jun 2001, 03:52 AM

Originally posted by Eric Pearson:
Josh --

> I'm curious. Why would you want COM support,
> when it will soon be the "legacy" component
> architecture?

Sorry, but IMO that mindset is a direct result of Microsoft hype. And of a basic misunderstanding about .NET, which is based on the next generation of COM. It's easy to get confused by Microsoft's frequent name changes... OLE, OLE2, ActiveX, COM, COM+, DCOM... They are all just different generations of the same technology. And in many cases the differences are minor, more like 1.00 and 1.10 than 1.00 and 2.00!

COM technology is no more "legacy" architecture than DLLs are! The entire Windows operating system -- every single core API -- is located in a DLL, and will be for many versions to come. Are DLLs "out of date" technology? Or are they just out of style? I have never been one to wear certain clothes because the current "fashion" says that I should, and I don't choose my technology that way either. I use what works for me.

The same is true for COM. COM is a well-established, widely-used technology, and dismissing it because it isn't "the latest and greatest from Microsoft" is a very serious mistake, IMO.

That's especially true considering that Microsoft's new paradigm is getting a less than enthusiastic reception, and many programmers are likely to delay implementing it. .NET 1.00 isn't even out of beta yet, and I'll bet that 2.00 will be significantly different. Would you prefer that PB jump directly to a technology that may be significantly changed next year, or the year after that?

I for one would applaud LOUDLY if PowerBASIC For Windows had native support for COM.

-- Eric

No, COM components are more closely related to VCL components than .NET components. Type libaries are
history. .NET components store the "header" information as metadata. .NET components are "compiled"
into MSIL, not machine code. You can have multiple versions of a particular .NET assembly on one machine.
.NET assemblies can be simply copied and used. COM components need to be registered. Does this sound
like they are similar to you? It is like saying a Volkswagen Bug and the Porsche 911 are similar because
they are "German" cars.

My point was why would PowerBASIC put time and money into a technology that is soon to go the way of the
VBX? To me, the money and effort would be better spent in other areas. If you want to believe COM is not
going away, that is your choice. However, it will. How soon? No one knows.

Josh

[This message has been edited by Josh Forster (edited June 28, 2001).]

**Josh Forster** · 28 Jun 2001, 04:06 AM

Originally posted by Philippe Monteil:
I fully agree with Eric. Not to mention that .NET classes
are automatically exposed as COM components, and that .NET application
see COM components as native .NET classes.

Making PB COM client capable would let PB developers use .NET classes seamlessly.

A COM server capable PB version would make possible to build components
directly usable in .NET applications.

Philippe Monteil
JAZZAge Software

As of Beta 1, .NET classes are NOT automatically exposed as COM components. You must use an export tool or the RegAsm
utility to allow it to be used. COM components are NOT automatically "seen" as .NET classes. A wrapper
must be created by either an import tool or the TlbImp utility.

Josh

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

[This message has been edited by Josh Forster (edited June 28, 2001).]

**Mark Newman** · 28 Jun 2001, 04:10 AM

COM isn't going away for many years, as Windows and MS's applications are
COM through-and-through. I doubt that there will be much new development
in COM, but it will be here for a long time.

------------------
Mark Newman

**Josh Forster** · 28 Jun 2001, 04:14 AM

Originally posted by Mark Newman:
COM isn't going away for many years, as Windows and MS's applications are
COM through-and-through. I doubt that there will be much new development
in COM, but it will be here for a long time.

Yes! My point exactly. The world will not drop COM as .NET is released. Developers will still use COM components. However, the smart business and component vendors will do all new development in .NET. To build NEW COM components makes no sense when the market will demand .NET components. However, this is not an issue if maximizing your ROI is not a priority.

Josh

[This message has been edited by Josh Forster (edited June 28, 2001).]

**Philippe Monteil** · 28 Jun 2001, 04:27 AM

<<As of Beta 1, .NET classes are NOT automatically exposed as COM components. You must use an export tool or the RegAsm
<<utility to allow it to be used. COM components are NOT automatically "seen" as .NET classes. A wrapper
<<must be created by either an import tool or the TlbImp utility.
But at least those processes are possible and made pretty straightforward,
which is more than enough to me.

Also, lots of software resources, either exposed by the OS, by widely used commercial
products (like the Office suite), by third-party component providers
take the form of COM components, therefore fully justifying the need
for the best possible COM support by PB.

Philippe

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

**Josh Forster** · 28 Jun 2001, 04:31 AM

Originally posted by Philippe Monteil:
<<As of Beta 1, .NET classes are NOT automatically exposed as COM components. You must use an export tool or the RegAsm
<<utility to allow it to be used. COM components are NOT automatically "seen" as .NET classes. A wrapper
<<must be created by either an import tool or the TlbImp utility.
But at least those processes are possible and made pretty straightforward,
which is more than enough to me.

Also, lots of software resources, either exposed by the OS, by widely used commercial
products (like the Office suite), by third-party component providers
take the form of COM components, therefore fully justifying the need
for the best possible COM support by PB.

Philippe

Philippe,

PB using COM components would be a useful feature for some developers.
I cannot see the business justification for putting time & money into COM
component creation. From what I have heard, JAZZAge is great for that.

Josh

[This message has been edited by Josh Forster (edited June 28, 2001).]

**Mark Newman** · 28 Jun 2001, 06:23 AM

Josh,

I didn't word my last post too clearly - to be more precise, I don't think
that there will be much new COM-platform development by Microsoft.
I think that 3rd party COM development will continue for some time, as quite
a large developer base is very familiar and comfortable with COM.

I think it's too early to make a wholesale jump to .NET; it's only in beta and
remember, nothing from MS is any good until it hits Version 3. In the long
run, .NET might turn out to be a viable platform to program against, or it might
turn out to be another Microsoft Bob.

------------------
Mark Newman

[This message has been edited by Mark Newman (edited June 28, 2001).]

**Semen Matusovski** · 28 Jun 2001, 06:34 AM

It's not necessary to make big efforts to build something like ATL wizard.
I mean that this (external) tool will generate PB source code.
Of course, classic COM is not ActiveX, but it's enough, for example, to build shell extentions.

------------------
E-MAIL: [email protected]

**Eric Pearson** · 28 Jun 2001, 06:45 AM

Josh --

You've obviously done a lot of reading about .NET. And you've obviously believed every word. (Sorry, couldn't resist. )

> My point was why would PowerBASIC put time and money
> into a technology that is soon to go the way of the VBX?

Honestly, I think the only place we really disagree is the meaning of the word "soon". I mean, someday "soon" every computer will have a 64-bit processor. Should PowerBASIC give up on 32-bit development because there is no real future in it?

COM isn't going away "soon" just because Microsoft says so. It will fade away when it is no longer useful.

Yes, probably at some point COM will be "legacy" technology and .NET will dominate. But today it is the most widely accepted component architecture.

And most of us need to make a living today, so if PowerBASIC adds support for COM, we will use it. Why should PB ignore a market that they know exists, in favor of betting the farm on a new paradigm that is still in beta?

-- Eric

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[This message has been edited by Eric Pearson (edited June 28, 2001).]

**Philippe Monteil** · 28 Jun 2001, 07:56 AM

Josh,

<<
PB using COM components would be a useful feature for some developers.
I cannot see the business justification for putting time & money into COM
component creation. From what I have heard, JAZZAge is great for that.
>>
Our products for PB, and most of them were released several years ago,
already cover almost all the aspects of COM programming in PB on both
the client and server sides. So I tend to agree with you that it is
somewhat late to start adding support for COM to PB now... We will
see what the future versions of PB will add to what the JA products
have been offering for sometime now

Philippe

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

Announcement

For the wish list

For the wish list

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment