Wish for compatibility in the next versions of PB.

[E B Knoppert]

One of my big concerns of future versions is that PB2(?) and PB7 is that the conditional metastatements probably will change.

PB2 uses $... and PB6 #... and $...
Like the removal of $SEGMENT results in a 16bit meta around this statement.

I certainly hope that PB2 will do #.. staments or keeping the next version of 32bits using $.

In fact it would be a contradiction by selling 2 compilers in 1 package being incompatible.

Thanks,

[Dave Navarro]

One of the problems of many implementations of various programming languages has been the "baggage" they continue to keep from one version to the next just to support some outdated feature used by only a few people.

At some point in the future all meta-statements in the PowerBASIC language will require a leading "#" sign. Both PB/DLL 6.0 and PB/CC 2.0 support that feature now as well as the *old* "$" sign for compatibility. Start changing your code now. Write new code using the new method.

"$" is now used to designate string constants.

You have been sufficiently warned.

--Dave


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

[E B Knoppert]

But how about our 16bit code?
Then it would no longer able to use them both in one app.

I meant with pb2 PB/DLL20..

We still do 16bit for at least 1 (or 2) years

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

[Dave Navarro]

I suspect that with the release of the next major 32-bit compiler(s), we'll no longer *officially* support 16-bit.

The overwhelming majority of PowerBASIC programmeers using PB/DLL do nothing with 16-bit, so why should they be *punished* because you choose to use an older operating system?

If you wish to continue writing 16-bit code, then it will be your responsibility to use conditional compiling to handle the differences between the 16-bit and 32-bit versions.

Now, if there are more 16-bit programmers out there than we are aware of, please speak up. Especially if you are maintaining projects in both environments (16-bit and 32-bit). If there are a significant number of customers, we'll certainly change our minds.

--Dave


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

[Michael Mattias]

Now, if there are more 16-bit programmers out there than we are aware of, please speak up.. If there are a significant number of customers, we'll certainly change our minds.

I write stuff to the specs of Health Care Financing Adminstration, an agency of the US Government which spends about $300,000,000 (your tax dollars at work!) annually on Medicare.

Part of the current HCFA spec for Medicare TPAs includes that PC-based software for viewing the ANSI 835 remittance advice must run on 16 bit systems (Win 3.x). (It also has to be supplied free to providers, but I don't think you guys would be interested in that).

So, 16-bit support is going to be important for at least a little while!



------------------
Michael Mattias
Racine WI USA
[email protected]

[Dave Navarro]

Michael,

Here's the important question.

Do you maintain your code using conditional compiling for both 16-bit and 32-bit?

E.B.'s problem is that he's using conditional compiling to maintain the same project as both 16-bit and 32-bit projects. The fact that future versions of PowerBASIC may not support "$" to designate meta-statements will cause him undue hardship. ( Sorry E.B., couldn't help myself)

--Dave

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

[E B Knoppert]

I'm not part. interested in $ but if PB/DLL20 could handle # it's perfect for me..

So, this might be a simple patch or recompile the current compiler to use #. (That's the way i think.)
I don't know if this is a big question.
If you request from people on this site, i can imagne that you will receive < 5% who use this combination.
Imo not a practical test in this case.
Therefore i posted this request.
The (simple) $segment for example, was also discarded from pb6 (comming from 5)

To live without the 16<>32 bit combination is much more important to me for now.

I hope you can reconsider for ~1PB version/1.5year, then we would be switched to 32bit too.

Thanks,


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

[Mike Doty]

Stephane,
1 Why do you keep asking for OOP.  Work in 
  Visual Basic and convert the code to DLL's.
  You can also buy programmable editors.
2 Use include files for your projects.
3 // comments.  Why?  "REM" and "!" are for this.
4 Run-time modules.  What language are you talking
  about?  This started out being about PB/DLL PB/CC.
  This is the Windows forum.

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

[Dave Navarro]

E.B.,

I think you hit the nail on the head!

I would go for PB/DLL 2.0 being updated to a 2.01 with support for "#".

--Dave


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

[E B Knoppert]

Thanks Dave,
That's exactly what i need i guess.

Cond. c. is the last step a programmer is able to take action upon. (is this english? )



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

[stephane fonteyne]

Originally posted by Mike Doty:
<font face="Courier New, Courier" size="3"><pre>
Stephane,
1 Why do you keep asking for OOP. Work in
Visual Basic and convert the code to DLL's.
You can also buy programmable editors.
2 Use include files for your projects.
3 // comments. Why? "REM" and "!" are for this.
4 Run-time modules. What language are you talking
about? This started out being about PB/DLL PB/CC.
This is the Windows forum.
</pre></font>

Hi,
OOP is very good en great.
You can make very large programs (example : Borland Delphi)
Visual Basic Don't like true OOP only Object Pascal and C++
I don't like Visual Basic it's very large and slow exe's!!!! No, I don't like Visual Basic

Greetings,
Stephane

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

[Michael Mattias]

Dave, I was not so much worried about the ability to use conditional compilation as I was about:

I suspect that with the release of the next major 32-bit compiler(s), we'll no longer *officially* support 16-bit.

If HCFA changes specs and retains the 16-bit requirement, what are we supposed to do if we have problems using PB/DLL-16 bit to add the new data requirements?

At the vary least, *IF* PB drops support for the 16-bit compiler, I would hope you would consider a two or three year period in which you would support it only with bug fixes/user response etc even though there are to be no new features or new releases.

By the way, let me correct a typo. HCFA does not spend about $300,000,000 tax dollars each year; they spend about $300,000,000,000 tax dollars each year!




------------------
Michael Mattias
Racine WI USA
[email protected]

[E B Knoppert]

For that kind of money they can build there own compiler!

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

[Michael Mattias]

For that kind of money they [HCFA, agency of the US Government] can build there own compiler!

What? Our government build a compiler?

That could result in a compiler as user-friendly as the Internal Revenue Service, as efficient as the Postal Service, and as reliable as the last two Mars probes.

MCM

[Matthew Berg]

I would go for PB/DLL 2.0 being updated to a 2.01 with support for "#".

And at the same time add string constants?

[Steve Hutchesson]

It seems to me that something basic has been missed, there is already a
miriad of old 16 bit packages that will write 16 bit windows code. A heap
of different resource editors, tools, toys etc...

It is simply a matter of fact that the last 16 bit version of windows is 8
years old and 3 operating system versions down the tubes. For people who
still need to write 16 bit code, it is hardly a developing area where
anything has changed so the old tools will still do it well.

Economic viability says that developing tools for 16 bit windows is a dead
issue. The world wide demand is so small that it cannot justify the cost
of doing it, especially as it was more difficult code to write and was a
lot more limited in its range.

I hope Dave is right that later versions of PB compilers will not be
saddled with 16 bit leftovers so that the company can put its resources
into keeping up with the current 32 bit operating systems which is
changing fast.

Anchoring a modern 32 bit compiler like PowerBASIC's PBCC and PBDLL60 to
out of date technology like 16 bit windows would not be in the interests
of either the customers or the company. I am fully in support of the
position where the two product lines need to be seperated and developed on
the basis of market demand.

Wasting time with developing new 16 bit tools and technology is like
learning to tune a T model ford, complicated, interesting but who cares.

[email protected]

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

[E B Knoppert]

>It is simply a matter of fact that the last 16 bit version of windows is 8 years old and 3 operating system versions down the tubes. For people who
still need to write 16 bit code, it is hardly a developing area where
anything has changed so the old tools will still do it well.

You call that 3 operating systems ?
pffft.. never seen a bigger mess.

After w95 until now there where only visible changes and a few others concerning IE wich consists of 90% of windows

But you're right about leaving that 16bit platform.... if we could so quick...


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

[Matthew Berg]

Economic viability says that developing tools for 16 bit windows is a dead issue. The world wide demand is so small that it cannot justify the cost of doing it, especially as it was more difficult code to write and was a lot more limited in its range.

"Old" does not mean "useless" or "obsolete". Some programmers, as Michael pointed out, have a requirement to continue to support 16-bit OSs, or it may still be worthwhile for some to continue to support their customers who may still be using 16-bit versions of their software. Some people still use DOS for various tasks, and it predates 16-bit Windows by many years. Just look at the popularity of projects like FreeDOS and DJGPP. Even the latest incarnations of Micro$oft Windows still support DOS.

However, I don't think any PB customers seriously expect PowerBASIC to continue support of 16-bit PB/DLL indefintely - that just isn't reasonable. It will eventually fade away to be replaced by something better - just not yet.