converting to powerbasic 
Author Message
 converting to powerbasic

I have a huge program about 11 meg of source. It is big alright. It was
written by a team of programmers almost 10 years in VBDOS 1.0. This is a
dead end. It has plenty of assembler codes. It uses chain , read ,
restore and data and so on.

Now the client want to move it to a windows environment. I am thinking of
using PB/CC or PB/DLL.

I presume that PB/CC is the quickest way. Can it be done fairly quickly
assuming that I know VBDOS well.  Is there a tool kit that can make it at
least a little look like a windows program.

Is PB/DDL I believe has a long term future unlike I have been told PB/CC.
Would it be much longer a project if I use PB/DDL.

Any feed back would be appreciated.



Tue, 05 Aug 2003 22:47:14 GMT  
 converting to powerbasic
I don't know specifically which target basic is the right choice.
That's a negotiation between you and your client, and his future platform
for support.

You could hack the conversion by hand, but it will be truly painful,
and you will spend months or years in debugging H---.
I assume the original team still wants to continue enhancing the app
while the conversion takes place.  If you do the conversion
by hand, they will not be able make enhancements to the original,
or you will not be able to capture the enhancements in the converted
results.

With this much source (300K SLOC?) you probably want automated conversion
help.
We build translators using our generalized compiler technology, DMS.
See http://www.semdesigns.com/Products/DMS/DMSToolkit.html.

DMS allows us to define a grammar for the orginal BASIC (and perhaps even
some of the assembler), to define a grammar for the target language
(e.g., PB), and to write rules that say how to translate one construct
in the source langauge to the other language.   One tests the translation
repeatedly until it is right; this actually takes a fair bit of time,
and requires good testing strategies.  Up to that moment, the original
developers
keep on modifying the original application.   Once the translation is right,
it is run, and everybody switches to working in the translated application
langauge.

--

Semantic Designs, Inc.              web: http://www.semdesigns.com
12636 Research Blvd. C-214    voice: (512) 250-1018 x140
Austin, TX 78759-2200             fax: (512) 250-1191


Quote:
> I have a huge program about 11 meg of source. It is big alright. It was
> written by a team of programmers almost 10 years in VBDOS 1.0. This is a
> dead end. It has plenty of assembler codes. It uses chain , read ,
> restore and data and so on.

> Now the client want to move it to a windows environment. I am thinking of
> using PB/CC or PB/DLL.

> I presume that PB/CC is the quickest way. Can it be done fairly quickly
> assuming that I know VBDOS well.  Is there a tool kit that can make it at
> least a little look like a windows program.

> Is PB/DDL I believe has a long term future unlike I have been told PB/CC.
> Would it be much longer a project if I use PB/DDL.

> Any feed back would be appreciated.



Wed, 06 Aug 2003 01:02:10 GMT  
 converting to powerbasic


Quote:
> I have a huge program about 11 meg of source. It is big alright. It was
> written by a team of programmers almost 10 years in VBDOS 1.0. This is a
> dead end.
> It has plenty of assembler codes.

Any (DOS) assembler will NOT convert to PB/Windows (or any Windows) anyway

Quote:
> It uses chain ,

PB/win does not support CHAIN  (do not need it)

Quote:
> read ,  restore and data

PB/Win has a form of DATA, READ and RESTORE, but it works differently enough
that if you do not have all your READ$ fuctions in a small procedure (i.e.,
you have READ and RESTORE all over the program) you won't want to convert
it. (Also, DATA statements are scope-limited to a single procedure).

Quote:
> and so on.

Like, what more is there?

Quote:
> I presume that PB/CC is the quickest way.

Bad assumption given the above UNLESS the code is ALREADY *highly* modular.

Quote:
> Can it be done fairly quickly

No

Quote:
>   Is there a tool kit that can make it at  least a little look like a

windows program.

Yes. There are several "graphics" addons for PB/CC; but using PB/DLL with
the DDT verbs will be about the best way.

MCM



Wed, 06 Aug 2003 06:14:48 GMT  
 converting to powerbasic

Im still having about the same problem like you. My VBDOS program has 9,7 Mb source. For a conversion, even to PB CC, theres quite a lot of areas to look at:

- Did the program make use of the event engine? If yes, maybe, its easier to convert to GUI. Though Im Using VBDOS, I do not use the event model. I moved over from 7.1 just because of the flaws of 7.1 in the area of overlays. It crashed and crashed ... the VBDOS compiler/linker works fine. I do make extensive use of separate compilation and the linker. PB CC does not know separate compilation and has no linker. Whether this presents a problem to you or not, depends on the structure of your program.

- Database. As a regular case, you cant take your DOS-database with you. Youve got to choose another database. Each and every call to the DOS-database (mine is Btrieve 5.10a) has to be translated. Will you find the abilities of the DOS-database system correspondingly in your 32-bit-windows system? Ah, after inspecting this one, youll perhaps decide for SQL, perhaps not. However, the new database will force a harsh rewrite in the file access part on you.

- Functions. Ive been used to extensively employ QuickPak Professional (Crescent) and PDQ Comm (Crescent) within VBDOS programs. Theres nothing like this for PB CC and, of course, not for any other console compiler. If you want to use the program structure of your existing VBDOS program, you will be forced to rewrite most of the used functions and subroutines resembling the formerly used as closely as possible. This is quite a job under a very differing environment.

- Windows console. Windows offers about 50 API functions related to console. If you decide for PB CC its adviceable to buy Console Tools and Grafix Tools as well as the Full Power Toolkit plus SQL Tools just to get a start. But you have to take into account, Microsoft does not love programmers for console applications and thanks to Bill G. youll run into some artificially built walls.

- What remains, most probably not very much, could be easily converted to PB CC.

You can read my personal decision somewhere down in this newsgroup. Whatever you do, it will be a hell of a job. Dont expect any easy walk!
Gnter



Wed, 06 Aug 2003 07:26:07 GMT  
 converting to powerbasic
Thanks for your comments

Quote:
> > and so on.
> Like, what more is there?

It was a state of the art program ten years ago. Now its a dinosaur
thanks to Microsoft dumping VBDOS.  

I went though one of the programs and it uses the following key words.

REM $INCLUDE: 'COMMON.INC'
CLEAR
SCREEN
WIDTH
CALL : EXIT SUB : END SUB
COLOR
CLS
LOCATE
PRINT
PRINT using "###.##";
format$(
ON ERROR GOTO
DEF SEG
BLOAD
GOSUB : RETURN
FIELD
GET : PUT
REDIM
FOR  :EXIT FOR: NEXT
UCASE$
ENVIRON$
RIGHT$  LEFT$  MID$
INSTR
SPACE$()
VAL
SELECT CASE
OPEN "" FOR RANDOM SHARED AS  LEN =
lock : UNLOCK
LSET
PUT
CLOSE
IF : END IF
PUT
ASC
do : exit do: LOOP
COMMAND$
RESTORE
SHELL
GOTO
GOSUB  : RETURN
INKEY$
LEN
UCASE$(
chr$(
STRING$
PCOPY
MKS$ : MKI$ : MKL$
CVI : CVL : CVD
IN : OUT

The biggest problem I think is that it uses QTREE. Its a Btree written in
assembler. I assume that it has to go. I saw an add-on for powerbasic
that had a BTREE library, what is it like? Or should we be looking at
something else.

Quote:

> > I presume that PB/CC is the quickest way.
> Bad assumption given the above UNLESS the code is ALREADY *highly* modular.

It aint. It started off okay but since then its been hacked to pieces.
Internally it looks a mess.

But what in a perfect world I would like is to port it across.Get it
working and then do stuff to it once it working.

Quote:

> > Can it be done fairly quickly
> No

Shit. But I expected that.

Quote:

> >   Is there a tool kit that can make it at  least a little look like a
> windows program.

> Yes. There are several "graphics" addons for PB/CC; but using PB/DLL with
> the DDT verbs will be about the best way.

Would the logic not have to be changed if we used PB/DLL. Is there going
to be a growth path for PB/DDL?
Quote:

> MCM



Wed, 06 Aug 2003 07:40:20 GMT  
 converting to powerbasic
Thank you. I found this discussions fasinating.

You are right if there are many companies out there with a lot of VBDOS
and QBASIC. If some company came up with a conversion package. Say they
said send us your source, we will convert it to PB/CC or PB/DDT for
$5000. Even if they said to us, we have to do a months work and make
several attempt before we convert it. They could have a cheque from my
company in 24 hours.

I have been told I can have 2 programmers for 3 months. Which translated
means I will work my {*filter*}off for three months and they will give me an
assistant who will work 9:00 to 5:00. That is going to cost them $20,000.

Quote:
> Im still having about the same problem like you. My VBDOS program has 9,7 Mb source. For a conversion, even to PB CC, theres quite a lot of areas to look at:

> - Did the program make use of the event engine? If yes, maybe, its easier to convert to GUI. Though Im Using VBDOS, I do not use the event model. I moved over from 7.1 just because of the flaws of 7.1 in the area of overlays. It crashed and crashed ... the VBDOS compiler/linker works fine. I do make extensive use of separate compilation and the linker. PB CC does not know separate compilation and has no linker. Whether this presents a problem to you or not, depends on

the structure of your program.

No.

Quote:

> - Database. As a regular case, you cant take your DOS-database with you. Youve got to choose another database. Each and every call to the DOS-database (mine is Btrieve 5.10a) has to be translated. Will you find the abilities of the DOS-database system correspondingly in your 32-bit-windows system? Ah, after inspecting this one, youll perhaps decide for SQL, perhaps not. However, the new database will force a harsh rewrite in the file access part on you.

All the system has is a call with a code (like a debtors name) which
returns a record number. Then the program  goes to a random files and
uses a GET and PUTs with FIELDed varables.

I was hoping I could hack a BTREE data-calls and make calls that simulate
the old database. I don't want to go to something different like SQL if I
can help it.

Quote:

> - Functions. Ive been used to extensively employ QuickPak Professional (Crescent) and PDQ Comm (Crescent) within VBDOS programs. Theres nothing like this for PB CC and, of course, not for any other console compiler. If you want to use the program structure of your existing VBDOS program, you will be forced to rewrite most of the used functions and subroutines resembling the formerly used as closely as possible. This is quite a job under a very differing environment.

We will have the same problem, it we uses Mach2 and some  shareware
products.

Quote:

> - Windows console. Windows offers about 50 API functions related to console. If you decide for PB CC its adviceable to buy Console Tools and Grafix Tools as well as the Full Power Toolkit plus SQL Tools just to get a start. But you have to take into account, Microsoft does not love programmers for console applications and thanks to Bill G. youll run into some artificially built walls.

Which are.

Quote:

> - What remains, most probably not very much, could be easily converted to PB CC.

> You can read my personal decision somewhere down in this newsgroup. Whatever you do, it will be a hell of a job. Dont expect any easy walk!

From what I read at the end you decided PB/CC is useless.

See there no way they could justify a total rewrite to VB 6.0 and yet the
VBDOS is really holding us back. Its a really good program. Somehow I
think we are like you. Stuck between a rock and a hard place.

Quote:
> Gnter



Wed, 06 Aug 2003 08:58:46 GMT  
 converting to powerbasic


Quote:
> You are right if there are many companies out there with a lot of VBDOS
> and QBASIC. If some company came up with a conversion package. Say they
> said send us your source, we will convert it to PB/CC or PB/DDT for
> $5000. Even if they said to us, we have to do a months work and make
> several attempt before we convert it. They could have a cheque from my
> company in 24 hours.

And there are some of us who are capable of building such translators.
However, while there may be lots of demand for translation, somebody has to
build one that works for you.
(See short discussion below about idiom translation).
And *that* is expensive.  So $5000 for a month's work doesn't make it
economically sensible, because the engineering cost never gets amortized.

Quote:
> I have been told I can have 2 programmers for 3 months. Which translated
> means I will work my {*filter*}off for three months and they will give me an
> assistant who will work 9:00 to 5:00. That is going to cost them $20,000.

I think I estimated you have 350,000SLOC.  If I count you and your two
helpers,
you have 9 available man-months = 9 * 21 * 8 = 1500 man hours.
So each of you will convert 300 lines of code a day, every day, without
error.
No time to go back and fix yesterday's code.

I don't believe you can do it by hand.   You shouldn't believe it either.

Quote:
> [lots of dicussion about how to handle various idiomatic constructions,

such as windows, btrees, etc.]
The upside to an automated conversion solution can be "taught" to watch for
the idioms ("CALL BTREE_READ(P1,....)"
and replace them by idiomatic target system calls.     The downside is that
each such
conversion project has to determine which idioms *they* are using, and how
they want them translated.
The net effect is, that you cannot get an off-the-shelf-converter for you
applications.
It has to be custom.

Quote:
> > - What remains, most probably not very much, could be easily converted
to PB CC.

> > You can read my personal decision somewhere down in this newsgroup.

Whatever you do, it will be a hell of a job. Dont expect any easy walk!

Quote:

> See there no way they could justify a total rewrite to VB 6.0 and yet the
> VBDOS is really holding us back. Its a really good program. Somehow I
> think we are like you. Stuck between a rock and a hard place.

The rock you are stuck on is twofold:
1) The insistence on doing it by hand.   Yeah, I can see that's impractical.
    This clearly also rules out a VB conversion.
2) The apparant economics.  $20K clearly isn't enough to justify (or enable)
anybody moving this package.
     The economics should be driven by a) the value of the package and its
future viability,
     and b) comparative costs of converting it manually,
     and c) the value of doing the conversion is a way which is least
disruptive to your company's time frame
               and development team members.
An automated conversion can remove these obstacles, but aren't cheap because
they always have
signifcant custom aspects.

See http://www.*-*-*.com/
that can be
used to implement a custom translator.

--

Semantic Designs, Inc.              web: http://www.*-*-*.com/
12636 Research Blvd. C-214    voice: (512) 250-1018 x140
Austin, TX 78759-2200             fax: (512) 250-1191



Thu, 07 Aug 2003 01:17:38 GMT  
 converting to powerbasic


Quote:
> You are right if there are many companies out there with a lot of VBDOS
> and QBASIC. If some company came up with a conversion package. Say they
> said send us your source, we will convert it to PB/CC or PB/DDT for
> $5000. Even if they said to us, we have to do a months work and make
> several attempt before we convert it. They could have a cheque from my
> company in 24 hours.

And there are some of us who are capable of building such translators.
However, while there may be lots of demand for translation, somebody has to
build one that works for you.
(See short discussion below about idiom translation).
And *that* is expensive.  So $5000 for a month's work doesn't make it
economically sensible, because the engineering cost never gets amortized.

Quote:
> I have been told I can have 2 programmers for 3 months. Which translated
> means I will work my {*filter*}off for three months and they will give me an
> assistant who will work 9:00 to 5:00. That is going to cost them $20,000.

I think I estimated you have 350,000SLOC.  If I count you and your two
helpers,
you have 9 available man-months = 9 * 21 * 8 = 1500 man hours.
So each of you will convert 300 lines of code a day, every day, without
error.
No time to go back and fix yesterday's code.

I don't believe you can do it by hand.   You shouldn't believe it either.

Hi BernardZ and Ira,

here Im totally with Ira. I do not believe this could be done within a reasonable time / cost frame. Though Im highly respecting translation tools, I dont believe there could be any reasonable machine translation from VBDOS to PB CC either. PB CC hasnt got a FIELD statement. Sounds simple to be replaced by TYPE and so on and in fact its one of the simpler jobs for human beings. But I cant see this done by a machine translation. Of course, everything could be defined. But having done the definition work most probably Id have finished the (correct) coding meanwhile. The whole thing boils down to a "mission impossible", at least not for $20,000,- and not for a limited 3x3 men-months. I would estimate three full man months alone just for planning the conversion, finding and purchasing the necessary tools. Another three man-months to write the function library and after that, god help you, the conversion thing starts, open end. Employing additional manpower means to train them and to maintain communication within the team plus documenting everything. The whole process will, Ive estimated that for my own program, take at least one year, under the assumption, that you get 2 additional programmers after the first 6 months, thiss a total of 2 man-years (no overtime calculated). Given my hourly rate for programming this was a whopping $211,200.-. Now you know, why so many companies decide for SAP R/3, Baan, Navision or some other standard software. Besides that, I wouldnt accept this job at all ....

Fine. And what do you and your customer have after that? Character oriented screens, no GUI. Some closed database, no SQL/ODBC to externally connect to reporting tools, to Access or to Excel. No Browse-Form paradigma and so on. If youd start right now youd hand over a finished character oriented program in spring 2003. But this will not happen, this customer just wants to bet about 10% of the necessary funds. What type of program is it? Perhaps theres already something on the market, just needing some adjustments? Look for that, drop in as a consultant, charge for converting data, dealing with the new supplier, for analyzing the new program and defining the changes. A conversion would only make sense in case you could resell this program, lets say, for a 100 times.

Ira says it with other words, but clearly enough:

The rock you are stuck on is twofold:
1) The insistence on doing it by hand.   Yeah, I can see that's impractical.
    This clearly also rules out a VB conversion.
2) The apparant economics.  $20K clearly isn't enough to justify (or enable)
anybody moving this package.
     The economics should be driven by a) the value of the package and its
future viability,
     and b) comparative costs of converting it manually,
     and c) the value of doing the conversion is a way which is least
disruptive to your company's time frame
               and development team members.
An automated conversion can remove these obstacles, but aren't cheap because ....

--

Semantic Designs, Inc.              web: http://www.*-*-*.com/
12636 Research Blvd. C-214    voice: (512) 250-1018 x140
Austin, TX 78759-2200             fax: (512) 250-1191

In my case, its much easier. Ive got 500 customers already with the same VBDOS-program running. No single customer can or is willing to pay for conversion. However, $200,000.- divided by 500 gives a reasonable $400.- for each of them. But its me, whos paying the $200,000.- in advance and whod get this money more than 2 years later. Of course, the upgrade would be a "little" more than $400.-.  So, my decision is a different one: Im rewriting the program by use of a 4GL (WinDev, French product, full 32-bit Windows/GUI) and with a rather reduced feature set (about 60% of the original), which will enable about 80% of my customers to move over to the new program. Additional goodies: its a no-charge SQL-multiuser database, ODBC-connection possible, features for sending / receiving e-mail, doing internet connections, reading / writing Excel files. Everything looks fine with tables, combo-boxes, look-up buttons and so on. Later, much later, Ill add the remaining 40% of features during 2-3 upgrades. No one can argument about a "DOS-program" for this much money, no one can whine over missing "windows-features". I hope, to have the program finished in Sept. 2001.

Best regards,

Gnter Predl



Thu, 07 Aug 2003 07:33:07 GMT  
 converting to powerbasic
I would like to thank Gnter and Ira for their comments. I took the  
conversation and showed them to the powers that be.

I also went over our code. Ira not far off. I estimate I have 350,000
lines of code in  350 programs. Another 50,000 lines in 50 library's.  I
also have another 10,000 lines of fielded statements for accessing the
data base. The code however is quite nice internally.

Unfortunately I doubt whether I would be given the opportunity to change
it over. The powers that be, reckon if we do it, what is it going to do
better then what we got now. I replied it would take a few months after
the conversion before it would have any effect. But there would probably
be some new problems to work out during that period. They are not
interested.

My offer is still available I think if there was a quick fairly cheap
solution my company would probably go for it. Otherwise they will just
keep struggling with what they have.



Fri, 08 Aug 2003 16:11:29 GMT  
 converting to powerbasic


Quote:
> I would like to thank Gnter and Ira for their comments. I took the
> conversation and showed them to the powers that be.

> I also went over our code. Ira not far off. I estimate I have 350,000
> lines of code in  350 programs. Another 50,000 lines in 50 library's.  I
> also have another 10,000 lines of fielded statements for accessing the
> data base. The code however is quite nice internally.

> Unfortunately I doubt whether I would be given the opportunity to change
> it over. The powers that be, reckon if we do it, what is it going to do
> better then what we got now.

One answer is,  "have a future life as a viable product".
A cautionary tale: I know one vendor that waited for VAXen to die before
they were motivativate
enough to move their VAX-based application to something else.
Of course, when the VAXen died, their customers were *very* interested
in an alternative.  The company thus went into panic mode, and did
the first thing that came to mind as a conversion.... which failed after
9 months.   The customer based decided the vendor was incompetent and/or
stupid,
and fled to other sources.    The original vendor ... died.  Pfft.

So.. what is the expected lifetime of PB?   What do customers
think when you tell them you huge app is implemented in PB?

Quote:
>I replied it would take a few months after
> the conversion before it would have any effect. But there would probably
> be some new problems to work out during that period. They are not
> interested.

Management always has a problem with a conversion task.  It apparantly
doesn't add anything
(modulo the cautinary tale), and so this is always this pressure to not only
convert,
but to add some  amazing new feature (green screens to GUI, hierarchical DB
to SQL,
proprietary data formats to XML, ...).     While its nice to tout amazing
new features,
and it is possible to integrate such a change with a conversion,  it
seriously delays the conversion
and raises its costs.     These are really two seperate activities, and best
thought of and handled that way.

Quote:
> My offer is still available I think if there was a quick fairly cheap
> solution my company would probably go for it. Otherwise they will just
> keep struggling with what they have.

Doesnt't sound like fun.

-- IDB



Fri, 08 Aug 2003 22:32:56 GMT  
 converting to powerbasic

Gunter suggests that instead of rewriting a large application by hand,
that he will be successful rewriting 80% of by 4GL.

I respectively think his customers will hate him, if he succeeds, because they *use* that other 20%,
oftentimes in surprising ways on which they are dependant, and *their* organizational costs to work around
the absence of that 20% in the "new" version will prevent them from upgrading.
Backwards compatibility to a very large degree is important in smooth upgrades.

Secondly, I'm surprised that he thinks this will be cheaper than doing it "plain by hand".
First, he assumes that he can do it himself (if I read his message correctly).
Given say, 350K sloc, he will be hard put to even look at the whole system in 9 months by himself.
Of course, he can *not* look at the source, and implement what he *thinks* the application
does.... but that jis ust more very strong reason for his customers to reject the result.
Secondly, when you "change the function", the temptation to "enhance" or "improve" usually
proves irrestistable to either the programmer (Gunter) or the marketing people (Gunter?).
This widens the gap between the original and the "improved", making the customer
acceptance problem worse, and increasing the delay.

I'll remark that automating FEILD translations is painful, but doable, even if the target langauge hasn't
got FEILD statements.   The value in an automated translation, is that it can do pretty ugly things,
successfully and reliably.

--

Semantic Designs, Inc.              web: http://www.semdesigns.com
12636 Research Blvd. C-214    voice: (512) 250-1018 x140
Austin, TX 78759-2200             fax: (512) 250-1191




  > You are right if there are many companies out there with a lot of VBDOS
  > and QBASIC

  I don't believe you can do it [translate] by hand.   ....

  Hi BernardZ and Ira,

  here Im totally with Ira. I do not believe this could be done within a reasonable time / cost frame.

  Though Im highly respecting translation tools, I dont believe there could be any reasonable machine translation from VBDOS to PB CC either. PB CC hasnt got a FIELD statement. Sounds simple to be replaced by TYPE and so on and in fact its one of the simpler jobs for human beings. But I cant see this done by a machine translation.
  ...
  Given my hourly rate for programming this was a whopping $211,200.-. Now you know, why so many companies decide for SAP R/3, Baan, Navision or some other standard software.

  But this will not happen, this customer just wants to bet about 10% of the necessary funds
  In my case, its much easier. Ive got 500 customers already with the same VBDOS-program running. No single customer can or is willing to pay for conversion. However, $200,000.- divided by 500 gives a reasonable $400.- for each of them. But its me, whos paying the $200,000.- in advance and whod get this money more than 2 years later. Of course, the upgrade would be a "little" more than $400.-.  So, my decision is a different one: Im rewriting the program by use of a 4GL .... I hope, to have the program finished in Sept. 2001.

  Best regards,

  Gnter Predl



Fri, 08 Aug 2003 22:46:14 GMT  
 converting to powerbasic



Quote:

> So.. what is the expected lifetime of PB?   What do customers
> think when you tell them you huge app is implemented in PB?

Oops.. I meant, "what is the expected lifetime of  VBDOS" etc.


Fri, 08 Aug 2003 22:48:12 GMT  
 converting to powerbasic

Every word you wrote may become reality .... wise words are to be respected.

- I know the program in and out and nearly know every line, because Ive written the whole damn stuff on my own during 18 years, starting with a CP/M-version, upgrading and revamping it month by month, year by year. I know the line of business what its written for and Ive got 72% market share. So, I hope, maybe people will convert just because of a missing alternative. Not a nice point of view ...

- the problem has other sides to look at too. Cash flow. Rewriting takes my time. a) The faster I can get a working program, complete with help, tutorials and documentation, the faster Ill get *any* customers for buying the upgrade. b) Marketing and image. Many customers are getting tired of their DOS-program and are looking eagerly for a GUI-version. They simply start to think, the company who made this program (us!) was too dumb to bring out anything under windows. Nonwithstanding the fact, that many of them would not be able to use a windows program. Lost confidence in a supplier presumably is not the best basis for future business. c) New customers. A new product draws new customers. Once upon a time weve got about 70 new customers a year for this program. This year, well be down to 15-25 new customers at best. Some market saturation for pricy software too. However, theres no problem, this years the year of the Euro conversion, each and every customers buying the Euro-upgrade :-)) But next year without a new version would be a dirt dry year .... d) pricing. Reducing the price of this oldie would still attract some new customers, but would leave us without income. This old program has to be trained and explained after installation .. so many features, only little help on screen. We plan to sell the new GUI-program via demo versions and we plan, not to come to the customers site for installation and training - everythings on the CD. This makes it cheaper and fit for export into the Euro-zone.

- Acceptance. This one will be hard. The whole GUI-program looks very much different now and Ive taken the chance to throw out old features (not needed anymore, laws have changed), throw out rarely used features and straighten out the program logic, just to make things better to learn for newcomers. Yes, its multilingual as well, for the first time we are not locked into our country. It had be quite an effort to train new customers lastly, hundreds of features, a matrix-printer printed handbook with 570 pages, no online help. A pain in the .. sometimes.However, most of our customers (~70%) were newbies to computers when they bought one (mostly from us) and most of them still have problems to handle windows programs and a mouse device. Normally, they would turn on their computer and choose the program from the start menue. Once inside *their* program, they feel quite at home. This is going to change radically ...

Ing. Gnter Predl
Systemhaus Predl

  Gunter suggests that instead of rewriting a large application by hand,
  that he will be successful rewriting 80% of by 4GL.

  I respectively think his customers will hate him, if he succeeds, because they *use* that other 20%,
  oftentimes in surprising ways on which they are dependant, and *their* organizational costs to work around
  the absence of that 20% in the "new" version will prevent them from upgrading.
  Backwards compatibility to a very large degree is important in smooth upgrades.

  Secondly, I'm surprised that he thinks this will be cheaper than doing it "plain by hand".
  First, he assumes that he can do it himself (if I read his message correctly).
  Given say, 350K sloc, he will be hard put to even look at the whole system in 9 months by himself.
  Of course, he can *not* look at the source, and implement what he *thinks* the application
  does.... but that jis ust more very strong reason for his customers to reject the result.
  Secondly, when you "change the function", the temptation to "enhance" or "improve" usually
  proves irrestistable to either the programmer (Gunter) or the marketing people (Gunter?).
  This widens the gap between the original and the "improved", making the customer
  acceptance problem worse, and increasing the delay.

  I'll remark that automating FEILD translations is painful, but doable, even if the target langauge hasn't
  got FEILD statements.   The value in an automated translation, is that it can do pretty ugly things,
  successfully and reliably.

  --

  Semantic Designs, Inc.              web: http://www.semdesigns.com
  12636 Research Blvd. C-214    voice: (512) 250-1018 x140
  Austin, TX 78759-2200             fax: (512) 250-1191




    > You are right if there are many companies out there with a lot of VBDOS
    > and QBASIC

    I don't believe you can do it [translate] by hand.   ....

    Hi BernardZ and Ira,

    here Im totally with Ira. I do not believe this could be done within a reasonable time / cost frame.

    Though Im highly respecting translation tools, I dont believe there could be any reasonable machine translation from VBDOS to PB CC either. PB CC hasnt got a FIELD statement. Sounds simple to be replaced by TYPE and so on and in fact its one of the simpler jobs for human beings. But I cant see this done by a machine translation.
    ...
    Given my hourly rate for programming this was a whopping $211,200.-. Now you know, why so many companies decide for SAP R/3, Baan, Navision or some other standard software.

    But this will not happen, this customer just wants to bet about 10% of the necessary funds
    In my case, its much easier. Ive got 500 customers already with the same VBDOS-program running. No single customer can or is willing to pay for conversion. However, $200,000.- divided by 500 gives a reasonable $400.- for each of them. But its me, whos paying the $200,000.- in advance and whod get this money more than 2 years later. Of course, the upgrade would be a "little" more than $400.-.  So, my decision is a different one: Im rewriting the program by use of a 4GL .... I hope, to have the program finished in Sept. 2001.

    Best regards,

    Gnter Predl



Sat, 09 Aug 2003 05:18:52 GMT  
 converting to powerbasic

says...

I put the changes in for PB to VBDOS

Quote:



> > I would like to thank Gnter and Ira for their comments. I took the
> > conversation and showed them to the powers that be.

> > I also went over our code. Ira not far off. I estimate I have 350,000
> > lines of code in  350 programs. Another 50,000 lines in 50 library's.  I
> > also have another 10,000 lines of fielded statements for accessing the
> > data base. The code however is quite nice internally.

> > Unfortunately I doubt whether I would be given the opportunity to change
> > it over. The powers that be, reckon if we do it, what is it going to do
> > better then what we got now.

> One answer is,  "have a future life as a viable product".
> A cautionary tale: I know one vendor that waited for VAXen to die before
> they were motivativate
> enough to move their VAX-based application to something else.
> Of course, when the VAXen died, their customers were *very* interested
> in an alternative.  The company thus went into panic mode, and did
> the first thing that came to mind as a conversion.... which failed after
> 9 months.   The customer based decided the vendor was incompetent and/or
> stupid,
> and fled to other sources.    The original vendor ... died.  Pfft.

This is not likely to happen here as the software works and VBDOS is dead
for quite awhile.

Management I can assure you is hardly in panic mode.

Quote:

> So.. what is the expected lifetime of VBDOS?  

Its dead. Dead. Dead. I hate Microsoft over the way they have dumped us.

Quote:
> What do customers
> think when you tell them you huge app is implemented in VBDOS?

This is interesting. The current users don't really care. Every now and
then they get an update with some new feature and they are happy. It does
the job.

Its really the new users who are dubious. They do want windows. But its
not that high on there list of priorities. More importantly is can the
program do the job and the answer is "yes". For what it does its the best
on the market. Nothing comes close.

I am ashamed to say that most of the programmers don't care either. They
have a fairly easy job.

- Show quoted text -

Quote:

> >I replied it would take a few months after
> > the conversion before it would have any effect. But there would probably
> > be some new problems to work out during that period. They are not
> > interested.

> Management always has a problem with a conversion task.  It apparantly
> doesn't add anything
> (modulo the cautinary tale), and so this is always this pressure to not only
> convert,
> but to add some  amazing new feature (green screens to GUI, hierarchical DB
> to SQL,
> proprietary data formats to XML, ...).     While its nice to tout amazing
> new features,
> and it is possible to integrate such a change with a conversion,  it
> seriously delays the conversion
> and raises its costs.     These are really two seperate activities, and best
> thought of and handled that way.

Agreed. The question is in my case does management even care about these
features. I have got VBDOS to write CSV files. That means they can get it
into EXCEL. I thought they would be happy. Nope they did not even bother.
That was too hard so they asked us to write some more reports for them.

Quote:

> > My offer is still available I think if there was a quick fairly cheap
> > solution my company would probably go for it. Otherwise they will just
> > keep struggling with what they have.

> Doesnt't sound like fun.

No but what alternative can I offer them. After spending a lot of time
and some money (which is not the issue) they will have something just as
good as they have now.

Advantages - similar to what they have
----------
) Users do not have to be retrained
) Long term benefits

Disadvantages - in doing the conversion
-------------
) New equipment is need to run CC
) Resources maybe better spent on a re-write. It could use a re-write.
) Time taken up in conversion
) Nothing changes
) Commitment is required by management. - they are typically OZZIE's if
it ain't broken, don't touch it and you are a fool if you try to fix it.

Questions
----------
) Does the system have a longer life span. They know they are going to
dump it. Its just a question of time.

If I could do it quickly and accurately then there would be nothing to
stop me. As I can see it I have four problems.

1) FIELD - I was stunned how right Gnter is about it. Its everywhere. I
have lines with 200 variables in one FIELD statement and I cannot see any
automatic way of fixing it. Many variables and a fair chunk of logic has
to be checked. As such the project is stalled.

The others are
2) RESTORE - We use it a lot. I can get around this but it will be a lot
of work. That is okay I don't watch TV anyway.

3) QTREE - Our Btree. It is full of assembler code. Okay I have to write
some routines to duplicate these functions. It will look lousy the final
product but so what its the same as now. This I think will be at least a
month.

4) Microhelp assembler routines. I can simulate almost all of these with
powerbasic. If not, many I can dump.

As a result the only point stopping me is the FIELD statement.

But I am a bit confused. I went to your site and downloaded a version of
the software. It seems that you do not have a conversion process for
Qbasic to powerbasic. So how can you help me?

- Show quoted text -

Quote:

> -- IDB



Sat, 09 Aug 2003 22:45:19 GMT  
 converting to powerbasic


Quote:

> As I can see it I have four problems.

> 1) FIELD - I was stunned how right Gnter is about it. Its everywhere. I
> have lines with 200 variables in one FIELD statement and I cannot see any
> automatic way of fixing it. Many variables and a fair chunk of logic has
> to be checked. As such the project is stalled.

Its been a long time since I looked at a FEILD statement, and this memory
crosses a whole variety of BASICs, which don't all agree..  If I get this
wrong,
cut me a bit of slack.  IIRC, one uses a FIELD statement to break up a
record into
a bunch of strings and/or values.   This seems straightforward to simulate.
In any case, it does have a well-defined
semantic interpretation, which impacts the meaning the program.

"All" one has to do is to replace the FEILD statement,
and any references to the FEILD slots, with corresponding equivalents.

This may not be easy to do with a conventional text editor, or even PERL,
but that is the point of our tools.   Would you care to post a small
example,
and explain what you think it does in VBDOS?  Then I can respond concretely.

Quote:

> The others are
> 2) RESTORE - We use it a lot. I can get around this but it will be a lot
> of work. That is okay I don't watch TV anyway.

Similarly, it has a well defined meaning, and can be treated
correspondingly.

Quote:

> 3) QTREE - Our Btree. It is full of assembler code. Okay I have to write
> some routines to duplicate these functions. It will look lousy the final
> product but so what its the same as now. This I think will be at least a
> month.

For this, you buy an off-the-shelf BTREE package, and replace
the custom calls with equivalent calls.    It should take 2 days
to buy the package, and about an hour to replace it.

Quote:

> 4) Microhelp assembler routines. I can simulate almost all of these with
> powerbasic. If not, many I can dump.

Right.

Quote:

> As a result the only point stopping me is the FIELD statement.

> But I am a bit confused. I went to your site and downloaded a version of
> the software. It seems that you do not have a conversion process for
> Qbasic to powerbasic. So how can you help me?

What we are good at is processing langauges we've never seen before.
Our tools work by accepting an extremely concise description of  langauges,
and then allow us to write transforms in those languages.  So for instance,
we can accept a definiton of VisualBasic (which we already have),
and a definiton of VBDOS (which we don't have, but can build
very quickly... we are good at what we do), and then write transformations
from on to the other.

Imagine you have GOSUB statements to a particular line number  9375 to do
cursor positioning,
with arguments bound to variables X and Y:

                ... X=CUSTOMER_ITEM_ROW*4; Y=LEN(CUSTOMER_NAME)
    900 GOSUB   9375
             ....

Then you can say the following to our tools, after defining VBDOS and C to
it:

           source domain VBDOS.  -- means patterns matched against are in
VBDOS notation
           target domain VBASIC. -- means changed patterns are in "C"

          rule
translate_cursor_position(l:line_number,x_position:expression,
y_position:expression) +
              " X= \x_position; Y=\y_position
               \l GOSUB 9375" rewrites_to
"position_cursor(x_position,y_position)".

This rule can simply be applied everywhere, and voila, the GOSUB 9375 calls
are all changed
to the "C" position_cursor call.    Our tools do "syntax" pattern matching
in terms
of the language constructs, not on strings,
but on compiler data structures called Trees, and thus reliably pick up the
"expressions"
no matter what is in them, even including constant strings containing line
breaks.
String based languages like PERL simply cannot do this, because they match
strings,
not language constructs.

This example is pretty easy; others get more complicated,
but you get the idea.  We code several hundred of these rules, and apply
them in a batch,
and they collectively convert the program.  Typical rules take 10 minutes to
code.
Some rules take 2 months to code, if they are complex enough.  We code
rules, try them,
and adjust repeatedly until we think they are right.  But the point is we
tune
the rules to match your translation problem.

And thus you get an automated conversion.   And the developers keep working
in VBDOS
until the day that everybody thinks the conversion is ready, and then we do
a last conversion run.

So we help by accepting your language definition, by definiting the
translation rules, and by executing them.
You can do this yourself, if you have the time and skill to learn how the
tools work.

--

Semantic Designs, Inc.              web: http://www.semdesigns.com
12636 Research Blvd. C-214    voice: (512) 250-1018 x140
Austin, TX 78759-2200             fax: (512) 250-1191



Sun, 10 Aug 2003 01:25:42 GMT  
 
 [ 18 post ]  Go to page: [1] [2]

 Relevant Pages 

1. converting assemby code for use in PowerBASIC v3.xx instead QB45/PDS71

2. convert powerbasic to Fortran

3. looking for powerbasic 3.x

4. PowerBASIC at Davar Web Site

5. PowerBASIC at Davar Web Site

6. PowerBASIC at Davar Web Site

7. PowerBASIC at Davar Web Site

8. New PowerBASIC compilers!

9. PowerBASIC at Davar Web Site

10. PowerBASIC at Davar Web Site

11. PowerBasic and FreeDOS32

12. Compiling an OBJ module into a basic program in version 3.5 PowerBasic for DOS

 

 
Powered by phpBB® Forum Software