Announcement

**Borje Hagsten** · 6 Sep 2000, 11:58 PM

Yes, it's exactly like that for me too, and just like you, I never
have been any good at waiting for surprises, especially when I know
it will be good news for me.

While I, as a developer myself, know exactly why the PB staff aren't
allowed to discuss any details or start any rumours, I can only
hope they haven't got caught up in the famous "release fright" that
many of us have encountered over the years. For each release, the
demands upon us becomes harder, so it's very easy to end up at a
point where you tend to over-do everything to the extreme (been there,
done that and never seem to learn how to tackle it myself).

Ted Stockwell, a very good C++ programmer, once told me: "Ask yourself
if Bill Gates would release it as it is and start making money on it."
I guess we all know the answer to that one..

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

**Lance Edmonds** · 7 Sep 2000, 01:02 AM

Borje is correct... PowerBASIC staff are not allowed to discuss unreleased products. (I think I'll have to write an FAQ with this answer! )

However, I can tell you that we definitely absolutely positively have something cooking in the kitchen... Unfortunately we don't allow anyone to even smell or taste the receipe in advance!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Steve Hutchesson** · 7 Sep 2000, 01:32 AM

Mike,

I guess you already know the deal that vapourware is not worth the paper
its printed on but judging from the improvements from version 5 to 6, by
the time a new version comes out, it will be well sorted out, have
additional capacity as we got with version 6 and still perform like a real
compiler.

I think the thing that has impressed me is just how good the standard of
programming is with the people who use PowerBASIC, instead of rushing
headlong into visual garbageware, programmers who are using PowerBASIC are
writing true API code, custom controls, CAD, games and who knows what
else.

There is in fact some humour in seeing the older C brigade gingerly
manipulating a mouse in event driven language models while basic
programmers are writing pure API code, inline assembler, using "other"
architectures and doing those things that were once the sole domain of C
compilers.

Now what I am inclined to advise is not to wait for a new version to come
out but keep doing exactly what you are doing, digest more of the basic
architecture of windows and capitalise on it by writing fast, powerful and
small code. There is a lot of grunt in the current compiler and very few
will have ever come near exhausting its capacity.

When version 6 arrived, the code I had written in version 5 took very
little work to get it going but it was faster, there was additional
capacity and it was the only compiler upgrade I have ever seen that did
not build the same files larger than the last version.

From what I have seen in the past, when a new version comes out, it will
be even more fun again and the biggest problem will be to get in early
enough to get a copy.

Regards,

[email protected]

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

**Mark Newman** · 7 Sep 2000, 01:50 PM

"PowerBasic is a riddle wrapped in a mystery inside an enigma"

(Apologies to Sir Winston Churchill)

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

**Michael Meeks** · 7 Sep 2000, 10:15 PM

Acutally we know a little already...

If you did a search on (bugs) within the PB Forum, you will find
many (repeats) addressing certain issues...

Some of these include:
Data Limits, Source Limits, 16Bit/32Bit, Pointers/Udt's...more!

So, if you're keen, you can read-between-lines on some of the
responses from the powers that be!

Mike

------------------
mwm

**Mark Newman** · 8 Sep 2000, 04:50 AM

True enough, but I certainly expect PB to address existing issues
in the next release. I just hope that it's PB 7.0, not PB 6.01.

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

**K Peel** · 8 Sep 2000, 09:34 AM

Hi all,

It seems that PowerBASIC has been releasing their compilers
either on or after the release date of Visual Basic,
and VB7 is just around the corner, so fingers crossed everyone!

Regards,

------------------
Kev G Peel
KGP Software
Bridgwater, UK.
mailto:[email protected][email protected]</A>

[This message has been edited by K Peel (edited September 08, 2000).]

**Mark Newman** · 11 Sep 2000, 07:42 AM

Originally posted by K Peel:
Hi all,

It seems that PowerBASIC has been releasing their compilers
either on or after the release date of Visual Basic,
and VB7 is just around the corner, so fingers crossed everyone!

The best estimates have VS.NET hitting the streets Q2 2001, give
or take a few months. I hope PB doesn't wait that long!

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

**Peter Patzwaldt** · 11 Sep 2000, 09:40 AM

Mark,
I hope PB will not support .NET at this point (maybe usefull if another year
passed bye) because .NET programs running only if the MS .NET runtime
is available. .NET programs are no really binaries, they are virtual P-Code styled
programs. So what about speed and things like that. On the other hand .NET
Compilers must be able to support the new P-Code model (it looks a little bit like
like the JAVA system) and that means OOP only!

So I hope we will not have a PB7 supporting that kind of stuff
right now. Let us talk about .NET end of 2001 and we'll see.

Peter

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

[This message has been edited by Peter Patzwaldt (edited September 11, 2000).]

**Brent Eldstrom** · 11 Sep 2000, 11:56 PM

Peter,

One correction I'd like to make about your .NET comment is that the .NET compiler doesn't produce a pseudo code executable or DLL that is interpreted by a virtual engine. What the compiler produces is IL (Intermediate Language) which can be thought of as platform agnostic assember. The first time that a .NET executable is run the IL EXE or DLL is compiled into native code (It can also be compiled at install time thus saving the first time longer load effect). That is a very important distintion because what we get is an IL EXE that is compiled most of the way and then the job in finished when it finally gets to the intended consumer of the component. The CLR (Common Language Runtime) optomizes that compiled executable very differently for each intended platform. For example MS will show a CLR for all chips that occupy the Windows CE space. Also the new 64 bit Itanium chip will have a CLR and also Intels very popular X86 platform. There is very good information that MainSoft is working on a Linux and Solaris port. The final result is true native app and the runtime handles JIT compilation, memory management, garbage collection, string manipulation, and many more useful services. They even showed the same code being run on a WAP phone, a Pentium computer and an Itanium computer at the PDC. That to me is very interesting and exciting. Now we can argue till the cows come home whether a runtime is a good thing or not but the fact remains that a runtime can be a very useful thing. Look at what Chris Boss has done with EZGui. His app works as well as it does because of the runtime. Granted he has listened to the call for a version that generates raw code so he is providing the best of both sides. Also don't forget that PB relies on many DLLs that are part of Windows such as gdi32.dll, kernal32.dll, or even ole32.dll (i think for string handling). .NET will also be part of the next version of Windows so it will be there whether we like it or not. My point is no matter how much we admire PB for producing small, fast executables and DLLs we are still bound to many dependencies. Microsoft has just spent 2 Billion dollars and 2 years building .NET so there is no going back for them now. From what I've seen so far they should continue their current course.

My primary task now is deciding where I can use PB to extend my .NET apps because I don't intend on dropping PB anytime soon. I've been using it since day 1 and I like it very much but the PB community ingores .NET at their own peril.

Brent...

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

**Steve Hutchesson** · 12 Sep 2000, 02:18 AM

I wonder at some of the comments in this topic, there has never been a
perfect compiler but some are less perfect than others. I would be very
surprised if many had truly exhausted the current compiler, it can do too
many things well.

It is certainly not a visual basic clone and that is why so many people
use it to write serious code, the type of stuff that can't be spat
together in a visual garbage generator.

If you are going to use a script based language, you won't be writing it
in PowerBASIC, you will be using the script language interpreter and
likewise, if JIT ever gets off the ground in performance terms, something
that clearly has not happened yet, you will be using some form of
multiport scripting device to generate the "code".

For anyone who still holds out hope for java style performance, try
running the SUN office pack on a late model pentium with a lot of memory,
the performance is truly pathetic but it still occupies more than 80 meg
of disk space.

As far as new Microsoft technology, most have reason to be suspicious
about their intent, trying to extend the Windows environment to MACS,
UNIX, SUN, MIPS and anything else that can process code may well suit
Microsoft's interests but many are suspicious for exactly that reason. COM
based architecture has been structured to be ported more easily to other
platforms at the expense of the x86 platform that dominates at the moment.

Microsoft's last attempt to control the internet as a large Microsoft
desktop has come to grief for a while because of the DOJ actions against
them, I seriously doubt that the upcoming attempt will fare any better,
ther are too many people who don't want Microsoft to have control of the
internet so while they may have spent big bucks, there is no garrantee
that their technology will give them the result they are after.

There has been for a long time in the computer industry, an unfulfilled
desire to produce a unified language across all platforms, C compilers
have come the closest but any multiport code that works across a big range
of them is necessarily of the lowest common denominator, hardware and
platform differences make much of this style of code unviable so you end
up with command line style C applications.

I support the view on vapourware that has been PowerBASIC policy for a
long time, "not worth the effort" and while I have no doubt that their R&R
department keep a good eye on what is happening, the range of demand is so
wide that they must differentiate on the basis of what suits most of their
customers. For a company that has made its name in a hard market by
putting power into the hands of Basic programmers, I seriously doubt that
they will throw away power and performance to follow speculation based on
Microsoft vapourware.

Now for Mike who has been "bitten by the hardcore programming bug", you
are in the right place, API style code gives you a lot of power and
functionality and PowerBASIC is well suited to exploit it, the inline
assembler is so good that it probably should be kept out of the hands of
mere mortals, (your software may end up being arrested for speeding).

Being able to think in code terms and then write it is the domain of
powerful low level compilers and it is here that PowerBASIC delivers the
goods, just don't let all that power go to your head

Regards,

[email protected]

PS. If there is one thing I know about assembler language programmers is
that if you leave them in a room with a passable box and a good assembler,
something fast will come out of it. Bob Zale's pure assembler written
compiler is a good example of this phenomenon.

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

**Peter Patzwaldt** · 12 Sep 2000, 03:36 AM

Brent,
you are 100% correct. The point of the story was not to discuss good or bad
of runtime systems. I agree 100% with you that .NET is coming and we
have to live with it but at this point (now, today) it will be
very difficult to support .NET from the current PB point of view.
Today: 16-Bit compiler which produce 32-Bit Code, no native COM support,
no visual build in designer, no OOP features.
For .NET support you have to support the new forms engine, the new
"pseudo" native compilation, full COM+ technology, OOP features. The
complete language needs to be changed on important points.
MS itself is not on the market right now with it's own VS software.
So, from my point of view it seems nearly impossible for PB to implement
this features (.NET) right now.
That was my point of the story.

Peter

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

**Mike Doty** · 12 Sep 2000, 06:55 AM

I wouldn't mind PB using a runtime.
Once distributed, it makes programs smaller
so downloads, etc ... are faster.

Disk space is nothing these days and
IBM is supposed to introduce their 100 GB
drive in December for under 100 bucks.

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

**Dave Navarro** · 12 Sep 2000, 07:19 AM

Mike,

For SHAME on you.

That's the same kind of thinking over at Microsoft... "Why create fast optimized code when today's processors are so fast and large hard drives are so cheap?"

Since I left PowerBASIC, I have been doing a LOT of consulting. I've written a LOT of code for a number of small businesses. Most of which do NOT have the latest processors or largest hard drives. I (and my customers) are *EXTREMELY* grateful for the small size and especially the speed of applications that PowerBASIC generates.

I created a RAS/Email application for a national ISP. One of the reasons they chose me over several other bids was because I was the ONLY one to promise them that the finished product would fit on a floppy disk. Two of the other bidding firms used Visual C++ and MFC and one used Visual Basic.

So far, over 6,000 copies have been distributed by email and over 800 disks have been shipped. The ISP would not email the product to all its customers if the file would have been large (if I had a 56k connection and had to download a multi-megabyte file I'd switch ISP's).

You simply can't do that sort of thing in Visual Basic. And most C++ programmers rely on MFC too much to create anything as small.

---

As for the complaints from others about not knowing what's coming with the next version(s) of PowerBASIC. Are you people on drugs?!? Why should PowerBASIC give away its game plan to the competition?

Quite obviously, Bob Zale and PowerBASIC, Inc. know what they are doing, otherwise they wouldn't be in business and the product would be so darned popular. And if you people think that you know better, then why haven't you sent your resume to PowerBASIC? If you're that good, I'm sure they'd love to have you on staff.

So, IN MY NOT SO HUMBLE OPINION , quit your whining. There hasn't been a new product release yet that didn't have some really *AWESOME* features in it. And I have every confidence in Bob Zale and his next outstanding creation.

--Dave

------------------
Home of the BASIC Gurus
www.basicguru.com

**Gary Akins** · 12 Sep 2000, 07:42 AM

Dave Navarro wrote:
As for the complaints from others about not knowing what's coming with the next version(s) of PowerBASIC. Are you people on drugs?!? Why should PowerBASIC give away its game plan to the competition?

The problem I have with PB's "no advance announcements, ever" stance is that it makes it vastly more difficult for me, as a PowerBASIC programmer trying to fight the good fight against co-workers who think C++ is the be-all and end-all of creation, to persuade the powers-that-be to stay with PowerBASIC... Right now, our embedded-systems product is DOS-based, and PB works just fine - but I am constantly having to deal with people coming to me and saying "Well, we might want to do the next generation with Linux / PalmOS / Windows CE" - (take your pick, it changes from week to week) - "because of x, and anything we do in PowerBASIC we'll just have to do all over again in C++, so why don't we just start using C++ now?", and it does me not one damn bit of good to have to answer this charge with "Well, PB is supposed to be coming out with a compiler for that platform... uhhh, no, I don't know when, because they have a policy of never talking about a product until it's released, but it's supposed to be Real Soon Now."

Of course I don't expect PB to give away their game plan to the competition, by announcing a laundry list of anticipated features in the new releases months before the product ships... but please, for the love of God, could y'all possibly find it in your hearts to throw a small bone to those of us out here fighting in the trenches, so that the next time I have to field the above question I can look them in the eye and say "No, we won't have to re-do it all, because PowerBASIC is working on a PowerBASIC For Linux compiler and they anticipate releasing it in the 1st quarter of 2001."

If I can't start giving some kind of definitive answers soon, I may well end up being assimilated by the C/C++ Borgs, and I really, really, really don't want that...
------------------

[This message has been edited by Gary Akins (edited September 12, 2000).]

**Brent Eldstrom** · 12 Sep 2000, 08:52 AM

I'm leaning Gary's way on this one. My own personal experience with this policy has made me stay away from producing any 3rd party add ons for PB because I don't have a clue of what's going to be included in the next version. I really feel sorry for guys like Phillipe (WinLift), Chris (EZGue), or Patrice (JazzAge). They've put in much effort on additions to PB that might get included in the next version. They might have better communication than I but from I can gather in various conversations that is not the case. At the very least PB should set up formal 'PowerBasic Integration Program' and make the members sign over their first born if they talk :-)

Brent...

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

**Brent Eldstrom** · 12 Sep 2000, 09:10 AM

Peter,

Your points are well taken but here's a few more tidbits that might get everyone thinking.

1) .NET is *not* COM. You can consume a COM component very easily in .NET but reference counting is gone. Circular references are now possible without memory leaks. COM will be important for many years but the writing is on the wall.
2) .NET has much stronger abilities to get at C/C++ or PB Win32 DLLs using P/Invoke. You even have the ability to tell the .NET compiler how to align data in structures going back and forth. This will make it much easier for PB to pass data to VB/C#/Eiffel/Python/Perl/etc. This this the item that interests me the most. Java is known to be quite difficult to communicate with much of the legacy code out there. In fact MS did such a good job with J/Direct that Sun sued them. PB will have more opportunities rather than less to step in where it's needed. Granted any PB or C/C++ code that is referenced in this way is considered 'Unsafe' and will not execute if the security settings of the client disallow it.

Brent...

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

**Mark Newman** · 12 Sep 2000, 10:19 AM

Dave Navarro wrote:
As for the complaints from others about not knowing what's coming with
the next version(s) of PowerBASIC. Are you people on drugs?!? Why should
PowerBASIC give away its game plan to the competition?

Jeepers, Dave

I don't think that anyone is asking PB to pass out the keys to
the front door. The title of the thread says it best: A roadmap!

For instance:

* What product is coming out next, PB/Linux or PB/DLL?

* Will the next release of PB/DLL be a bug fix or a major revision?

* Has a given product entered internal/alpha/beta testing?

* Is a given product scheduled be released in 2000? 2001?

Making this type of information available won't give your competitors
any useful product-specific information, but it helps users with
longer-term planning, budgeting and training issues.

I know, in considerable detail, where MS is going with .NET, good
and bad. I don't expect the same detail from PB, but I need to
have something to go on.

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

**Guest** · 12 Sep 2000, 11:52 AM

It is very difficult to hold off the wolves without any specific
details of what is going to be in the next PB release/update. I have already
lost a couple battles and have been using C/C++ for new development.
Vapourware is never released. Announcing some features which are
definitely locked into an impending release is not playing the
vapourware game.

Change the policy! It stinks...

------------------
Ron

Announcement

PowerBASIC roadmap would be nice ;-))

PowerBASIC roadmap would be nice ;-))

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment