Page 1 of 2
Old DOS to new Windows = Conversion thoughts
Posted: Mon Dec 16, 2019 6:13 pm
by TimStone
For the past 20 years my primary application(s) have used FWH / Windows development. Prior to that, for 18 years, it was a DOS program.
Over the past couple of years, I have found a lot of clients who I never hear from still run the old DOS program because it simply never fails. Of course that is quite a problem because it's harder to get computers that run 16 bit Clipper applications since all the OS systems are now discontinued.
I'm thinking there might be a market for an upgrade to the OLD DOS program, running on Windows. I would want to keep all the screens and functionality the same as it was. In essence, other than having it open in a Window, I would keep the same menu system, and screen layouts, and of course all the functionality ( and functions ) would be exactly the same.
Yes, I have a far advanced version of the program using all the latest FWH features, but some people like the old program and it meets all their needs, except for the fact it is 16 bit Clipper and needs DOS to run.
I would love to see your ideas for the simplest way to perform this "update" and provide them with a solution. Any thoughts will be greatly appreciated. I know this was broached in another recent thread, but that topic never gained more than two comments before going off track.
Thanks for the ideas. I would love to keep the coding to an absolute minimum if possible.
Tim
Re: Old DOS to new Windows = Conversion thoughts
Posted: Mon Dec 16, 2019 8:28 pm
by Enrico Maria Giordano
Just compile with [x]Harbour in console mode.
EMG
Re: Old DOS to new Windows = Conversion thoughts
Posted: Mon Dec 16, 2019 8:57 pm
by TimStone
Can we run an xHarbour console mode application on a new Windows 10 64 bit install ? Isn't that essentially DOS ?
Re: Old DOS to new Windows = Conversion thoughts
Posted: Mon Dec 16, 2019 9:26 pm
by Enrico Maria Giordano
Yes, we can. And no, it's a Win32 console mode program.
EMG
Re: Old DOS to new Windows = Conversion thoughts
Posted: Mon Dec 16, 2019 9:35 pm
by TimStone
OK ... I can try that. I will have to remove some 3rd party libraries but not really concerned about that.
Re: Old DOS to new Windows = Conversion thoughts
Posted: Tue Dec 17, 2019 2:18 am
by TimStone
I'm making progress on this, though I will want to change it to a Windows very basic layout next. HOWEVER ...
I can create a build, but old Clipper programs were built with Blinker and some of it's functions / capabilities of course cannot be implement ( 16 bit, won't build 32 bit ). I also have some other calls that perhaps someone has worked with ( UNRESOLVED EXTERNALS ). Perhaps someone here has used them:
gfAttr : An assembly language program to derive system attributes for the GrumpFish library
FT_IDLE, IAMIDLE, ON_IDLE.: All functions exist undocumented in Clipper but not in the commercial version of xHarbour
WW_CLP_2 : I don't know where this is from
SWPRUNCMD / Overlay. The overlay function can be used instead of swpruncmd, but it appears both are from blinker
I realize these are Clipper issues, and xHarbour issues, but perhaps someone here has memories of this and can provide an answer. After all, this forum responds far more quickly than the others.
Re: Old DOS to new Windows = Conversion thoughts
Posted: Tue Dec 17, 2019 3:12 am
by hua
>gfAttr : An assembly language program to derive system attributes for the GrumpFish library
Seems to be just for drawing shadow -
http://www.x-hacker.org/ng/grump/ng1295d.html
Maybe you can experiment replacing it with
ft_shadow . Worst case, maybe just rem it out altogether since it's pure cosmetics only.
>FT_IDLE, IAMIDLE, ON_IDLE.: All functions exist undocumented in Clipper but not in the commercial version of xHarbour
Nanforum functions. In Harbour it would be in hbnf.lib. However I would recommend try to just rem them out first. See here for a discussion on these functions
https://groups.google.com/forum/#!topic ... 22Gl343cz4
>SWPRUNCMD / Overlay. The overlay function can be used instead of swpruncmd, but it appears both are from blinker
You won't need this. Overlay is something specific to handle memory issues under DOS. However if you are using swpruncmd() to run another program you can try the RUN command.
HTH
Re: Old DOS to new Windows = Conversion thoughts
Posted: Tue Dec 17, 2019 7:24 pm
by TimStone
Thank you. That information is most helpful.
I need to look at more aggressive work with this project, and in the end, I think it will be best to modify it to run in windows. I can keep all the functionality, and perhaps just redo screens.
Tim
Re: Old DOS to new Windows = Conversion thoughts
Posted: Wed Dec 18, 2019 2:03 am
by Jimmy
hi,
have a look at this Thread
http://forums.fivetechsupport.com/viewt ... =3&t=38167
i have try to run CLICK ( Clipper Documenter ) Source under FiveWin as Console and had Problem
as i know they work on it while it have work before like HMG Constribution but long time not used ...
for function like FT_* i got the Source of NanForum LIB and some OBJ Code i have re-engine to harbour HB_FUNC()
i can provide those HB_FUNC() as replacement for FT_* function if you need.
but not all Clipper Code make Sense in Windows Environment like DOS-Printer ...
---
i guess your Clipper App use Epson ESC Sequence to select Font etc. Problem : hard to find a Printer who understood it.
when you want to use your Windows Printer than you need to re-write all what you want to print ...
i have not work with harhour "Print" yet but remember your are in Windows World and you can "print" much more than before. you do not need to "print" on Paper ... it can be a PDF or send by Email.
welcome in Windows World
Re: Old DOS to new Windows = Conversion thoughts
Posted: Fri Dec 20, 2019 12:07 am
by TimStone
So, I have finished step 1 which is the menu system. Now I want to convert screens from the old DOS display system to a DIALOG. Since the @ SAY / GET was all written in clipper, the code below was perfectly formatted in a DOS box. However, when I use them in a DIALOG, the spacing is "all messed up"
First, the GET boxes are on different rows than the SAY statements. They are higher
Also, the columns don't line up. Of course this is why I never use @ SAY or @ GET with my programs. To put it simply the alignment never makes sense.
Here is the code:
Code: Select all
DEFINE DIALOG oClientDlg TITLE "Client Record Editor" SIZE 1200,800 OF oWnd
@ 4,12 SAY "ACCOUNT"
@ 4,31 SAY "RESALE #"
@ 5,12 SAY "COMPANY"
@ 6,12 SAY "F/L NAME"
@ 7,12 SAY "ADDRESS"
@ 8,12 SAY "CITY"
@ 9,12 SAY "STATE ZIP"
@ 10,12 SAY "H/B PHONE"
@ 11,12 SAY "LEVEL - Parts: Labor: "
@ 11,44 SAY "CODE"
@ 11,55 SAY "TAX ?"
@ 12,11 TO 12,66
@ 12,31 SAY "> MEMO <"
@ 4,24 GET p_acrnum PICTURE "99999"
@ 4,40 GET m_clires PICTURE "@!"
@ 5,24 GET m_clicom
@ 6,24 GET m_clifst
@ 6,41 GET m_clilst
@ 7,24 GET m_cliadd
@ 8,24 GET m_clicty VALID datack('erfcit', 'erfcit', 'city', 'CITIES')
@ 9,24 GET m_cliste PICTURE "!!" VALID ISSTATE(m_cliste)
@ 9,27 GET m_clizip VALID ZIPTST()
@ 10,24 GET m_clipho PICTURE "(999) 999-9999"
@ 10,41 GET m_clibus PICTURE "(999) 999-9999 e#####"
@ 11,27 GET m_clipri PICTURE "!" VALID m_clipri $ 'R1234'
@ 11,38 GET m_cliprl PICTURE "!" VALID m_cliprl $ 'R1234'
@ 11,49 GET m_clirat PICTURE "!!!" VALID datack('erfcod', 'erfcod', 'code', 'CODE', 'detail', 'DESCRIPTION')
@ 11,61 GET m_clitax PICTURE "Y"
ACTIVATE DIALOG oClientDlg CENTERED
Why don't they line up ? To put it simply, @4, x GET is higher on the screen than @ 4, x SAY, and the spacing gets worse as we drop further down the dialog.
Re: Old DOS to new Windows = Conversion thoughts
Posted: Fri Dec 20, 2019 2:51 am
by Jimmy
hi,
as i say there are some Problem with Console see this Thread
http://forums.fivetechsupport.com/viewt ... =3&t=38167
they work on it so let them time to finish it.
Re: Old DOS to new Windows = Conversion thoughts
Posted: Fri Dec 20, 2019 9:06 pm
by Rick Lipkin
Tim
Have a look at dosbox ... Dosbox is a 16 bit emulator that can be used on a 64 bit OS.
https://www.dosbox.com/
I use dosbox if I have to use dbase3 or Foxpro.
Rick Lipkin
Re: Old DOS to new Windows = Conversion thoughts
Posted: Fri Dec 20, 2019 9:57 pm
by TimStone
Rick,
Emulator's or virtual machines may allow for the running of old programs, but what I really want is to translate old code to a compatible 32 bit windows system.
It comes back to my example, and the question about why I can't get @ SAY/GET commands to line up properly on a screen. Every sample that is posted here uses that syntax, and yet for me I must be missing some very key element.
Consider a grid. If I use @ 2,5 SAY "Hello", we shall consider that location to be row 2 of the grid. If I use @2,30 GET cVariable, then it displays on the grid at row 1.5.
Why ?
Re: Old DOS to new Windows = Conversion thoughts
Posted: Mon Dec 23, 2019 4:19 pm
by TimStone
Again, I'm still seeking help to find out why I can't get @ Say and @ Get to line up properly on a Dialog.
Re: Old DOS to new Windows = Conversion thoughts
Posted: Mon Dec 23, 2019 8:40 pm
by Gale FORd
I have several real old programs that were converted to (x)Harbour/XHB
Add this to compile/link [C:\xHB\Samples\GT_wvg.prg]
Link in [C:\xHB\Lib\WVG.lib] so you can use mouse and graphic fonts.
Then I add this to emulate dos screen with mouse.
Code: Select all
SET EVENTMASK TO INKEY_ALL
Wvt_SetCodePage(511) // 255 or 511 for xp
WVt_SetIcon('cic.ico' )
WVT_Core()
WVT_Utils()
♠ Wvt_SetGui( .t. )
Wvt_SetMouseMove( .t. )
SetMode(25,80)
setsize() // see function code below
/// Whatever
Wvt_DrawBoxRaised( 7, 22, 19, 53 )
@ 8, 25 say "Eqpt Control Main Menu"
@ 10,22 say ' 1 - Equipment Inventory '
@ 11,22 say ' 2 - Equipment Bookings '
@ 12,22 say ' 3 - Lift Requests '
@ 13,22 say ' 4 - Equipment Pre-Entry '
@ 14,22 say ' 5 - Invoicing '
@ 15,22 say ' 6 - Reports '
@ 16,22 say ' 7 - Master File Maintenance '
@ 17,22 say ' 8 - System Utilities '
@ 18,22 say ' Esc - Quit '
@ 23,0 SAY "ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ"
menu to nOption
I use this function to set the screen size based on screen width.
Code: Select all
function setsize( lSwitch, lSmall )
static nScreenWidth, lNormal, nSize
if nScreenWidth == nil
nScreenWidth := Wvt_GetScreenWidth()
endif
if lNormal == nil
lNormal := .t.
endif
if lSwitch == nil
lSwitch := .f.
endif
if lSwitch
lNormal := !lNormal
nSize++
if nSize > 3
nSize := 1
endif
endif
if nSize == nil
nSize := 1
endif
do case
case nScreenWidth >= 1400
Wvt_SetFont('Lucida Console',26,14)
case nScreenWidth >= 1280
do case
case nSize = 1
Wvt_SetFont('Lucida Console',30,14)
case nSize = 2
Wvt_SetFont('Lucida Console',26,12)
case nSize = 3
// Wvt_SetFont('Lucida Sans Typewriter',24,10, 600, 2)
Wvt_SetFont('Terminal',12, 10) //, 500, 1 )
endcase
case nScreenWidth >= 1152
if lNormal
Wvt_SetFont('Lucida Sans Typewriter',30,14, 800, 2)
else
Wvt_SetFont('Lucida Sans Typewriter',26,12, 600, 2)
endif
//Wvt_SetFont('Lucida Sans Typewriter',26,12)
//Wvt_SetFont('Orator10 BT',26,12)
//Wvt_SetFont('LettrGoth12 BT',26,12)
//Wvt_SetFont('Lucida Console',26,12)
//Wvt_SetFont('Terminal',20,10)
case nScreenWidth >= 1024
if lNormal
//Wvt_SetFont('Terminal',24,12)
Wvt_SetFont('Lucida Sans Typewriter',28,12, 800, 1)
else
Wvt_SetFont('Terminal',18,10, 500, 1 )
//Wvt_SetFont('Lucida Sans Typewriter',26,12)
endif
case nScreenWidth >= 800
if lNormal
//Wvt_SetFont('Terminal',24,12)
Wvt_SetFont('Lucida Sans Typewriter',21,9, 600, 2)
else
//Wvt_SetFont('Terminal',16,7)
Wvt_SetFont('LettrGoth12 BT',16,10, 400, 2 )
//Wvt_SetFont('Lucida Console',16,-8)
endif
otherwise
Wvt_SetFont('Terminal',12,6)
endcase
return( nil )