Announcement

**Steve Hutchesson** · 24 Sep 2000, 03:20 PM

Tim,

I guess I am of much the same disposition as you are in terms my choice of
the compiler I use and for much the same reason, performance measured in
terms of both size and speed.

OOP appears to have many forms of implementation, some good, some bad and
some that are worse and it is this distinction that I find interesting and
probably worth pursuing.

If you added together all of the downside characteristics of the range of
suggestions that have been made to change PowerBASIC, you would end up
with an oversized visual garbage generator with uninteligible notation
that was toothless in its capacity, slow in its execution and required a
large runtime to make it run.

This sum total is the antithesis of what PowerBASIC actually is, a high
performance low level compiler. Now while I can happily keep writing
procedural based code as it delivers in terms of speed and size, I am not
directly opposed to the fundamental concept of programming in objects. Its
something that we in fact all do using the procedural model.

I have been following the discussion between Florent and Peter with some
interest as I would like to see what are the necessary requirements for
programmers to be able to implement an efficient form of OOP in a low
level compiler like PowerBASIC.

I am already familiar with both MACRO and LIBRARY capacity and in
conjunction they can deliver simplified code that is easy to use, powerful
and at no penalty in performance terms. I have enough stuff written in
MASM now to be able to drop small toys in a short time using macros and
libraries. Put this into a language that is as fast and comprehensive as
PowerBASIC in low level power terms and there will be a corresponding
improvement in code throughput.

Where I have the spare time, I sometimes experiment with "other"
architecture and it is here where I see the advantage of adding low level
capacity if it allows the programmer to be original and do things in
different ways.

The bottom line for me in a compiler is being able to write what I want in
it and if there is some advantage in being able to construct an
architecture that will do something useful, I am all for it, I draw the
line when a compiler restricts me to "method" style programming within
objects that I can't change and can't fix.

I don't believe this will ever happen in PowerBASIC as I doubt Bob Zale
would be willing to throw away so much work to implement such a bad idea
for so little result. I see the potential for OOP coming from additional
low level capacity, not from following the same path that has lead to a
generation of garbage.

Regards,

[email protected]

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

**Tim Wisseman** · 24 Sep 2000, 03:33 PM

That is a fantastic idea. . . Add OOP as an addon to the compiler,
without breaking / bloating the compiler.

Maybe, A preprocessor that rewrites the code before sending to to
the compiler.

As long as we can keep the small, fast, lean compiler I have
no problem with your idea for PB OOP.

Tim

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

**Florent Heyworth** · 24 Sep 2000, 03:48 PM

Tim, that's what we've been saying all along

Cheers

Florent

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

**jcfuller** · 24 Sep 2000, 03:56 PM

Just to make it clear where I stand on the oop issue.

I DO NOT want PB to implement any OOP functionality into the compiler
other than MACRO's and static libraries. As I have metioned in the past
I am an encapsulation freak. I enjoy working at the low levels the compiler
provides so I can implement objects in MY OWN way.

If OOP is that important to you as a PB programmer do it yourself or use
one of Philippe Monteil's Jazz Age products.

James

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

**Florent Heyworth** · 24 Sep 2000, 04:08 PM

The downside with everyone implementing their own objects
in their own way is that it makes it hard to re-use objects
written by others...

Cheers

Florent

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

**Kev Peel** · 24 Sep 2000, 04:16 PM

Implemented maybe in the form of an OOP library (engine) DLL (now) or a static module (maybe in the future), with OOP-Style functions, such as oAssign("MYOBJECT.MYPROPERTY=MYVALUE") or something to that effect.

Personally, I hate OOP, - It reminds me too much of VB, DELPHI and more importantly BLOAT, in some circumstances this may not be the case, but in most it is.

Oh, and please Stephane, no more postings!

Regards,

------------------
Kev G Peel
KGP Software, Bridgwater, UK.
www.go.to/kgpsoftware

**Tim Wisseman** · 24 Sep 2000, 04:53 PM

Well, Visual Basic 5.0 takes Basic code and converts it all
to C++, then it starts the C++ compiler and makes the EXE.

There is no reason why you guys can't do the same and make up
your own version of Basic with OOP that starts a converter that
converts it all into PowerBasic Code and calls to your Runtime
package. Then PowerBasic does the rest of the work.

I guess that is what you guys had in mind already. . .

Well that sounds fine.

Tim

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

**Chris Boss** · 24 Sep 2000, 06:43 PM

I use PB because it is a Richer language than VB and it
doesn't require a bloated runtime and dozens of OCXs. PB's
most significant advantage is also the size of the executables
it produces, which rivals even C compilers.

PB is rich in features not found in other languages (Basic or
non-Basic). Things, like pointers, AsciiZ, array functions,
powerful string functions, communications, etc. The name
PowerBasic tells it all !

Yet, for PowerBasic to compete in the "dog eat dog" world of
software development (compiler market), they need to keep
"pushing the envelope" in their compiler. This doesn't mean
becoming a clone of VB. It means making the language richer
in features and offering more "Raw" power to developers.

Many suggestions have been made, like adding COM support,
OOP, etc. If PowerBasic can impliment some of these features
their own way then they continue to make the language
richer. I doubt that if PowerBasic decided to add a feature, they
would bloat the compiler. If they felt they could impliment a
new advanced feature and still keep the code size down and the
speed fast, I can't imagine any sound reason to say, NO to such
a feature.

Microsoft and Borland are not standing still. Neither should
PowerBasic. The difference between PowerBasic and other companies
is not "whether" they will add new powerful features, but that
they only want to "do it right". With that I am in absolute
agreement.

So rather than "trash" suggestions like COM or OOP, it is better
to do what Dave Navaro suggested and that is give constructive
suggestions in "how" to impliment these features in a way that
works in harmony with PBs own goal of "small", "fast" and "solid".

[This message has been edited by Chris Boss (edited September 24, 2000).]

**Steve Hutchesson** · 24 Sep 2000, 07:16 PM

Below is a full WinMain and startup code using the MACRO capacity from
MASM. This code was cut and pasted out of one of my MASM test pieces and
works fine. It demonstrates the lowest level of encapsulation that is
possible using text replacement at the pre-processor level. This style of
encapsulation involves ZERO loss of size or performance as in its fully
expanded form, it is still minimum procedural programming.

PowerBASIC is well suited to use this style of encapsulation as it is a
high performance low level compiler that can produce the minimum size code
necessary to make this style of encapsulation both efficient in speed and
size terms.

Among the advantages in using MACRO expansion is that you can hide very
complicated and messy looking low level code within a single MACRO call.
This allows you in turn to optimise the code within the macro with little
need to keep it readable as you only need to get it right once.

MACRO expansion is also very useful where you ave to handle ugly repetitive
coding of the type that is used in system toolbars.

This is the toolbar code from my MASM code generator and it uses 2 macros
to handle the option of blanks or buttons.

Code:

    TBblank
    TBbutton  0,  50
    TBbutton  1,  51
    TBbutton  2,  52
    TBblank
    TBbutton  3,  53
    TBbutton  4,  54
    TBbutton  5,  55
    TBblank
    TBbutton  6,  56
    TBbutton  7,  57
    TBbutton  8,  58

This is very simple and fast code to use but it still is minimum API style
code below it that has no performance penalty from this style of
encapsulation.

Regards,

[email protected]

Code:

  ; #########################################################################
  
      Do_Model .486
  
      include abstract.inc     ; local includes for this file
  
  ; #########################################################################
  
      Do_Init
  
  ; #########################################################################
  
      Do_WinMain
  
      invoke LoadIcon,hInst,500    ; icon ID
      Do_RetVal hIcon
  
      szText szClassName,"Abstract_Class"
  
      mov wc.cbSize,         sizeof WNDCLASSEX
      mov wc.style,          CS_HREDRAW or CS_VREDRAW \
                             or CS_BYTEALIGNWINDOW
      mov wc.lpfnWndProc,    offset WndProc
      mov wc.cbClsExtra,     NULL
      mov wc.cbWndExtra,     NULL
      m2m wc.hInstance,      hInst
      mov wc.hbrBackground,  COLOR_BTNFACE+1
      mov wc.lpszMenuName,   NULL
      mov wc.lpszClassName,  offset szClassName
      m2m wc.hIcon,          hIcon
        invoke LoadCursor,NULL,IDC_ARROW
      mov wc.hCursor,        eax
      m2m wc.hIconSm,        hIcon
  
      invoke RegisterClassEx, ADDR wc
  
      Do_CentreWindow 550,400
  
      invoke CreateWindowEx,WS_EX_LEFT,
                            ADDR szClassName,
                            ADDR szDisplayName,
                            WS_OVERLAPPEDWINDOW,
                            Wtx,Wty,Wwd,Wht,
                            NULL,NULL,
                            hInst,NULL
      Do_RetVal hWnd
  
      Do_MenuLoad hInstance,hWnd,600
      Do_WindowDisplay hWnd
  
      Do_mlStart msg
      Do_mlEnd msg
  
      Do_EndWinMain
  
  ; #########################################################################

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

**Jason Bock** · 24 Sep 2000, 07:21 PM

My $0.02 on a couple of points:

Tim,

What about COM support? All that we know from PB INC, is that "if" they do add COM support, they will take their time and do it right.

Nobody wants VB in PB. But, the future of COM is definitely not bright. Sorry, but the .NET is the new way to do things in the MS world. Is that the only way? Is that the best way? Of course not. But it is the new way.

PowerBasic Inc, would not toss that all away to chase the latest insane notion that .NET or OOP is the cure-all.

Why is that "insane?" I have to admit, the comments of OOP being "bloated" and "insane" have to stop unless you're going to back up your statement with some concrete examples.

James,

I enjoy working at the low levels the compiler provides so I can implement objects in MY OWN way.

Please read the first chapter of Box's "Essential COM" book and you'll realize that this rips away at the idea of interoperability. If you do your objects your way and I do them my way, how do the two worlds meet?

Kev,

Personally, I hate OOP, - It reminds me too much of VB, DELPHI and more importantly BLOAT, in some circumstances this may not be the case, but in most it is.

VB isn't OOP. It's COM-based. I would strongly recommend reading as many hardcore COM books as you can, along with some OO books. The differences are there.

Again, the word "bloat."

Tim,

Well, Visual Basic 5.0 takes Basic code and converts it all to C++, then it starts the C++ compiler and makes the EXE.

This is news to me. I've watched directories where VB has built my application, and I've never seen .cpp or .h files being created. VB, AFAIK, does not create C++ code. VC++ and VB do share the same compiler, C2.EXE, but VB does not pull a PowerBuilder and create C++ code.

To all,

I like PB for the ability to create small, tight executable files. There's no doubt in anyone's mind that PB reigns in the Windows compiler world. And, like it or not, if it wants to stay in the Windows world, it will have to consider playing in the .NET world as well.

Regards,

Jason

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

**Steve Hutchesson** · 24 Sep 2000, 08:36 PM

Jason,

Like it or not, the term "bloat" is well applied to the current generation
of visual garbage, there are clear and objective measures on what a minimum
file size is and when it not just a bit bigger but much bigger, ther is
something radically wrong with it. Bloat conjures up images of swollen,
sick and slow, an image that is well pointed at software that takes more
that 100k to do a hello world.

Lets look at the track record of Microsoft blunders, did you waste the disk
space, time and brainpower on OS2 code back in the early nineties ? What about
the be all and and all in DDE for apps that "talked" to each other. Then came
the multiport fantasy, "can you port it to a MAC ?".

You have already mentioned the Component Object Model, I have a friend in New York
who has decyphered the COM interface in assembler and it is an extremely complicated
proprietry interface designed to be ported to other platforms, shame no-one in the
unix, linux, mac, mips or other hardware platforms were willing to assist Microsoft
in migrating there code there.

Why will .NET fare any better, Microsoft flopped in the MSN attempt to control the
internet and again in the browser war that has lead to them getting into trouble
with the US Dept of Justice.

I get spammed about every week with the MSDN flash emails from Microsoft so I get
to see much of what is floating through the Microsoft camp over time, I am all
in favour of good technology but I agree with the idea that following every whim
of Microsoft vapourware is a formula for failure.

Now related to some of the other coments,

I very much agree with the capacity to be original as much that is written will
never be pointed anywhere else than where its used,

=================================================================================
If you do your objects your way and I do them my way, how do the two worlds meet?
=================================================================================

Who says they have to ?

=================================================================================
This is news to me. I've watched directories where VB has built my
application, and I've never seen .cpp or .h files being created. VB,
AFAIK, does not create C++ code. VC++ and VB do share the same compiler,
C2.EXE, but VB does not pull a PowerBuilder and create C++ code.
=================================================================================

Perhaps you have not bothered to look at the Microsoft linker in Visual Basic 5,

Microsoft (R) 32-Bit Incremental Linker Version 4.20.6164
Copyright (C) Microsoft Corp 1992-1996. All rights reserved.

Its a Microsoft COFF generation linker that will build things from VxDs to DLLs
to C++ EXE files using standard Microsoft format object files. VB's capacity to
build what it calls native code EXE files is based on the same technology as the
other Microsoft languages so while there is no need to convert the files to CPP
extensions, the technology is the same.

=================================================================================
Why is that "insane?" I have to admit, the comments of OOP being "bloated"
and "insane" have to stop unless you're going to back up your statement
with some concrete examples.
=================================================================================

Would the compile size of PowerBASIC EXE files serve as concrete examples ?
I suggest that they do and that the call of "insane" "bloatware" is in fact
a fair statement of the difference.

Regards,

[email protected]

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

**Tim Wisseman** · 24 Sep 2000, 08:37 PM

If you compile Visual Basic 5/6 into PCode you get pure Pcode.
. . . but if you make a real EXE file it converts the Basic
Code into C++ code in temp files that C2.EXE (The C++ compiler)
compiles into an EXE.

Visual Basic first outputs temp files that are the same as the
C++ temp files that are produced by the first pass of the
Visual C++ compiler. It is a Basic To C++ first pass temp
file conversion. C2.EXE is a second pass C++ compiler.

This is very common knowledge among Visual Basic programmers.
Here are some web sites you can read about it on:
http://www.devx.com/upload/free/feat...199/jc1199.asp
http://www.vb-zone.com/upload/free/f...mckinney2a.asp

.NET is not something PB should be mixed up in. PB does not
need to be held hostage to a massive MS Common Runtime.
That is what .NET is, A massive common run time and C#.
Great at what it does, but it is a Microsoft thing, it is
the Microsoft way, not the PowerBasic way.

PB users should be looking at XML and SOAP. These would be
nice 3rd party addons for PowerBasic.

[This message has been edited by Tim Wisseman (edited September 24, 2000).]

**Egbert Zijlema** · 24 Sep 2000, 11:36 PM

OOPS!

------------------
mailto:[email protected][email protected]</A>
www.basicguru.com/zijlema/

**Mark Newman** · 25 Sep 2000, 04:41 AM

Some thoughts:

XML/SOAP: I second Tim's idea of adding support for XML and SOAP
to PB. This would allow PB to tie into much of the "new world
order", as it were.

Bloat: We have to get past the "bloat" monster. A VB/Delphi/VGG
(Steve H.'s favorite ) program that weighs in at 250K + a
runtime is not necessarily a slow, ponderous beast. I have a
couple of ~250K VB6 programs that I ported to PB6 for expected
speed improvements. The PB versions were much smaller, but only
one was visibly faster.

COM: Yes, COM is a complicated machine under the hood and I don't
understand all the internals, and I won't mourn it's passing in
favor of NET (if and when, but the previews from MS are a lot
more than vapor), but it's pretty stable now, relatively easy to
use at a high level and makes possible some pretty powerful apps.

OOP: I'm not a huge fan of OOP, but there are times when it's very
useful and efficient (in development time) and it's nice to have
the option available. Will adding it to PB increase the size of
compiler and slow it down? Yes! So What! (Blasphemy! )

Seriously, I don't care if the PB compiler is 20K or 2MB or 20%
slower, as long as it produces the good stuff it always has.

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

[This message has been edited by Mark Newman (edited September 25, 2000).]

**Chris Boss** · 25 Sep 2000, 05:09 AM

Mark;

I have a couple of ~250K VB6 programs that I ported to PB6 for expected
speed improvements. The PB versions were much smaller, but only
one was visibly faster.

When Visual Basic was generating only PCode EXEs (version 4.0 and before)
, PowerBasic had a significant advantage in speed and it was
10 to 20 times faster.

With Visual Basic 5.0 (and beyond), VB is a front end to a C
compiler when you generate "Native Code" which makes VB 5.0 (and 6.0)
10 to 20 times faster than VB 4.0. This means that PB has lost
a major advantage of speed, since VB is catching up to PB in the
speed catagory.

This means that PBs greatest advantage today is not speed, but size
of apps and the "Richness" of the Language (see my comments above).

Because Microsoft is "playing catch up" to PB in some areas (like
speed), this means PB needs to keep "pushing the envelop" when it
comes to features and "raw power".

For the same reason that many "commercial" apps are written in C and
not VB (small size, more power and control, closer to the API), PB
needs to be the alternative for Basic programmers wanting more power.
Rather than force Basic programmers to use C, they can use PB instead
of VB.

This would mean that PB needs to stay on the leading edge when it
comes to "accessing" the core of Windows. As Windows relies more
on COM, then likely PB should add some COM support. As other
technologies are added to the "core" of the Windows operating system,
PB needs to give programmers access to those technologies.

If you want to compare PB to any language it should be C !

PB should continue to offer all the advantages of C, but in a
Basic compiler.

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

**Jason Bock** · 25 Sep 2000, 06:05 AM

Steve,

Who says they (objects) have to?

Anybody involved with interoperability issues. If I had to write that layer every time I met up with a developer who decides to implement OO differently, I wouldn't be happy. There is a reason to doing things in a standard way - it makes interop easy. True, some apps are stand-alones, but all it takes is one person to say, "Hey, can we include some of this into our app?"

Would the compile size of PowerBASIC EXE files serve as concrete examples ?
I suggest that they do and that the call of "insane" "bloatware" is in fact
a fair statement of the difference.

I would never say that PB is bloated, nor that other technologies have not address bloat issues as hard as PB has. What I am saying is that OO does not necessarily equal bloat.

Perhaps you have not bothered to look at the Microsoft linker in Visual Basic 5,

I have. I'm not arguing that VC++ and VB share a lot when it comes down to the compiler. I am arguing that VB generates pure C++ code.

Which leads to another issue...

If you compile Visual Basic 5/6 into PCode you get pure Pcode.
. . . but if you make a real EXE file it converts the Basic
Code into C++ code in temp files that C2.EXE (The C++ compiler)
compiles into an EXE.

This isn't true, and the article (DevX's) doesn't say that. Yes, VB creates the necessary files for the C2.EXE. But my contention is that VB doesn't generate C++ files. I have never found anyone who has hooked the compile process and found C++ files.

Take a look (if you really want to ) at what Eiffel or PowerBuilder does. They generate C/C++ files (at least PBuilder 5 did - I know Eiffel does because they flat-out admit it).

AFAIK, the article is about hooking the compile process such that you can inject your own OBJ files created with tools that support other languages. This does not mean that VB creates .cpp files. In fact, there's no reason for VB to create C++ files. Eiffel does it only for portability issues - it can use C++ compilers for any OS to compile its' generated C++ code. VB doesn't have that need; it's far easier for VB to simply generate the OBJ files and let the final pass create the EXE.

If someone can show me where VB creates C++ files (which was the original contention, not that VB and VC++ generate the same file format for the final link.exe, I will be more than happy to recind my statement and cower in a corner for a while .

Regards,

Jason

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

**Tim Wisseman** · 25 Sep 2000, 07:13 AM

I am looking at the temp files that VB 5 is making in my
C:\windows\temp\ directory.
VB061310GL

I see that the code (In plain text) is making calls to:
__vbaFreeStr
__vbaStrMove
__vbaObjSetAddref
__vbaFreeObj
__vbaStrCopy
__vbaFreeStrList
__vbaStrCmp
__vbaLenBstr
__vbaHresultCheckObj

No, it file is not a formated C++ file that you can play with,
it is a mostly non human readible mess of pcode.

It is in the very same format that the first pass of the Visual
C++ compiler produces.

To turn this into an EXE you need a second pass C++ compiler.

A second pass C++ compiler is making the OBJ files for the
linker. If a second pass C++ compiler is making the OBJ files
what do you think that means? Think about it.

[This message has been edited by Tim Wisseman (edited September 25, 2000).]

**Jason Bock** · 25 Sep 2000, 07:44 AM

Tim,

All of the __vbaXXX methods you found are calls to the VB run-time DLL, so I'm not suprised that you found them. In fact, you could call them from VB or PB directly if you wanted to, but they are undocumented so that's a fun proposition .

No, it file is not a formated C++ file that you can play with,
it is a mostly non human readible mess of pcode.

So is it a C++ file? That's my real question. All I'm trying to find out is if those files are generated in C++. So far, from what you said it's just a weird form of p-code.

A second pass C++ compiler is making the OBJ files for the
linker. If a second pass C++ compiler is making the OBJ files
what do you think that means? Think about it.

I don't know. All I do know is that the first-pass compiler is generating a file for the second-pass compiler. If it's C code, then that's fine. If it's a file format that is written for the VC++ compilers, that's different to me.

Again, Eiffel creates C files to generate the executable. All I'm asking is for someone to show me the output from a VB compilation process that has semi-colons . If it does, that's news to me and I'll stand corrected.

Thanks,

Jason

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

[This message has been edited by Jason Bock (edited September 25, 2000).]

**Tim Wisseman** · 25 Sep 2000, 09:16 AM

The files are not for human eyes, there are no semi-colons
there are no CPP files. It is code for the second pass C++
compiler. VB does not make OBJ files, the C++ compiler makes
the OBJ files. . . and the linker links them.

The temp files are in something that is called by microsoft
“intermediate language”.

The second pass C++ compiler compiles intermediate language.

"If you are familiar with Visual C++, you know C2.EXE
is the code generator that produces the actual machine code."
--- MSJ
http://www.microsoft.com/msj/default...yer0698top.htm
http://msdn.microsoft.com/library/bo...vb5/Ch08_4.htm

Tim

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

Announcement

OOP, be realistic

OOP, be realistic

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment