Old DOS to new Windows = Conversion thoughts

[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

[Enrico Maria Giordano]

Just compile with [x]Harbour in console mode.

EMG

[TimStone]

Can we run an xHarbour console mode application on a new Windows 10 64 bit install ? Isn't that essentially DOS ?

[Enrico Maria Giordano]

Yes, we can. And no, it's a Win32 console mode program.

EMG

[TimStone]

OK ... I can try that. I will have to remove some 3rd party libraries but not really concerned about that.

[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.

[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

[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

[Jimmy]

hi,

have a look at this Thread http://forums.fivetechsupport.com/viewtopic.php?f=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

[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  Expand view

   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.

[Jimmy]

hi,

as i say there are some Problem with Console see this Thread http://forums.fivetechsupport.com/viewtopic.php?f=3&t=38167

they work on it so let them time to finish it.

[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

[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 ?

[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.

[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  Expand view

 
   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  Expand view

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 )