Author |
Message |
BERNARD #1 / 18
|
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 |
|
|
Ira D. Baxte #2 / 18
|
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 |
|
|
Michael Mattia #3 / 18
|
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 |
|
|
Ing. Günter Pred #4 / 18
|
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 |
|
|
BERNARD #5 / 18
|
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:
|
Wed, 06 Aug 2003 07:40:20 GMT |
|
|
BERNARD #6 / 18
|
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 |
|
|
Ira D. Baxte #7 / 18
|
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 |
|
|
Ing. Günter Pred #8 / 18
|
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 |
|
|
BERNARD #9 / 18
|
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 |
|
|
Ira D. Baxte #10 / 18
|
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 |
|
|
Ira D. Baxte #11 / 18
|
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 |
|
|
Ira D. Baxte #12 / 18
|
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 |
|
|
Günte #13 / 18
|
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 |
|
|
BERNARD #14 / 18
|
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. 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? Quote:
|
Sat, 09 Aug 2003 22:45:19 GMT |
|
|
Ira D. Baxte #15 / 18
|
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 |
|
|
Page 1 of 2
|
[ 18 post ] |
|
Go to page:
[1]
[2] |
|