xHarbour & Funcky ?

"bill robertson" <marydick2007@comcast.net> wrote in message
news:-I2dnSHo7tg9VinVnZ2dnUVZ_o3inZ2d@comcast.com...
>
> Mel,
>
> Here's a link to an online listing for the missing functions and their
> calling parameters. I have the ng files that came with v2.6 if you can't
> find the functions descriptions on line. Dave Pearson has an ecellent
> reader called web on his web site for the guides.
OK, so I forgot to paste the link!

http://www.ousob.com/ng/funcky/ng314.php

Using the link provided by Bill and for curiosity sake I saw that
(excluding the mouse functions) the missing functions are easily
replaceable. Strcenter seems to be a perfect clone of padc.
alltrimlen is len(alltrim( PAR ))
alen and amaxstrlen need to traverse the array but they are really basic
functions.

The "problem" may arise by the encrypt/decrypt couple. If they are used
only for login then no problem, you may switch methods and recreate users.
If they are used to store encrypted data you probably need to find a
compatible routine.

Francesco

Bill & Francesco:

Thanks for the tips but I have to leave in a few minutes to go golfing.
Back late today.

Thanks !
-Mel Smith

Mel,

>>>btw, I started with a simple xHarbour version of one of her simpler
>>>executables. But even *that* came apart because of an old 1991 Funcky
>>>conflict.

Does this mean that the list of unresolved externals will grow when
you move on to the less simple executables? I agree with Francesco
that what you have shown us so far should be pretty easy to replace,
but the real question is how representative the list is for the whole
project.

After removing the mouse related stuff there are around 20 functions
left to fix in your list:

>OBJ\UTIL1.OBJ(UTIL1) : 'CSRPUT' : unresolved external
>OBJ\UTIL1.OBJ(UTIL1) : 'PRINT' : unresolved external
>OBJ\UTIL1.OBJ(UTIL1) : 'STRCENTER' : unresolved external
>OBJ\UTIL1.OBJ(UTIL1) : 'NSTUFF' : unresolved external
>OBJ\UTIL1.OBJ(UTIL1) : 'CSRON' : unresolved external
>OBJ\BACKGROU.OBJ(BACKGROU) : 'SETATTR' : unresolved external
>OBJ\BACKGROU.OBJ(BACKGROU) : 'DECRYPT' : unresolved external
>OBJ\EYECOLOR.OBJ(EYECOLOR) : 'WAITKEY' : unresolved external
>OBJ\EYE_UP.OBJ(EYE_UP) : 'CSROFF' : unresolved external
>OBJ\FUN.OBJ(FUN) : 'BEEP' : unresolved external
>OBJ\P_MENU.OBJ(P_MENU) : 'ENCRYPT' : unresolved external
>OBJ\TS_BOX.OBJ(TS_BOX) : 'BOX' : unresolved external
>OBJ\INSTALL.OBJ(INSTALL) : 'ISFILE' : unresolved external
>OBJ\TS_PSCRN.OBJ(TS_PSCRN) : 'ALLTRIMLEN' : unresolved external
>OBJ\TSPROMPT.OBJ(TSPROMPT) : 'ALEN' : unresolved external
>OBJ\TSPROMPT.OBJ(TSPROMPT) : 'AMAXSTRLEN' : unresolved external
>OBJ\TS_HELP.OBJ(TS_HELP) : 'MX_VIEW' : unresolved external
>OBJ\NSETCOLO.OBJ(NSETCOLO) : 'ATTRTOA' : unresolved external
>OBJ\NSETCOLO.OBJ(NSETCOLO) : 'ATOATTR' : unresolved external
>OBJ\NSETCOLO.OBJ(NSETCOLO) : 'STREXTRACT' : unresolved external

Some of these are fancy replacements for standard Clipper functions,
like for example waitkey() that takes a number of clock ticks instead
of a number of the seconds that inkey() takes as argument, strcenter()
which seems to do what padc() does, alltrimlen() which is the same as
len(alltrim()), there are a couple of functions replacing loops that
look at content of arrays, etc.

The encrypt() and decrypt() functions in Funcky are very basic, xoring
the character string with the encryption key, character by character.
Much too basic for any serious encryption needs, actually. The code
below (it needs more testing, I think, so let's call it preliminary)
is based on a comp.lang.clipper discussion in 2004. The decrypt()
function is identical to encrypt(). Only 7-bit ASCII is supported (see
the Funcky docs).

function encrypt(cString,cKey)
local i,cNewString := ''
i := int((len(cString)/len(cKey))+1)
cKey := replicate(cKey,i)
for i := 1 to len(cString)
cNewString += chr(numxor(asc(substr(cString,i,1)),;
asc(substr(cKey,i,1))+128))
next
return cNewString

If there are additional executables that you need to convert, maybe
you should create a combined list of the Funcky functions you need in
all of them so you can evaluate the size of the project more easily.

Regards,
Klas

-------
klas dot engwall at engwall dot com

http://www.engwall.com/clipper/

The LFN Library for Clipper
The LanMan Library for Clipper
The NFPAT1A Timeslice release patch for the Nanforum Toolkit

(Before discussing Klaus's struff, Let me say that Frank van Uffal (of our
ng) found why my Clipper conversion failed with a DPMI Protection error: He
determined that removing the 'ctusp.obj' file reference from the script
cured the crash ! And I've had that file in *all* my old Clipper aps for
years !! I wonder why removal of that file now crash ?? All of my currnt
(but old and running Clipper apps) use ctusp.obj with no problem ??? )

Anyway,

Klas said:


"> Does this mean that the list of unresolved externals will grow when
> you move on to the less simple executables?

Very probably ! There are another three major executables that I have
yet to tackle The Gun Shop maintenance program and two Cash Register
proggies. Both are sizeably bigger and more complex than the current Util
program which handles re-indexing and other utility tasks)

>
> After removing the mouse related stuff there are around 20 functions
> left to fix in your list:
>
>>OBJ\UTIL1.OBJ(UTIL1) : 'CSRPUT' : unresolved external
>>OBJ\UTIL1.OBJ(UTIL1) : 'PRINT' : unresolved external
>>OBJ\UTIL1.OBJ(UTIL1) : 'STRCENTER' : unresolved external
>>OBJ\UTIL1.OBJ(UTIL1) : 'NSTUFF' : unresolved external
>>OBJ\UTIL1.OBJ(UTIL1) : 'CSRON' : unresolved external
>>OBJ\BACKGROU.OBJ(BACKGROU) : 'SETATTR' : unresolved external
>>OBJ\BACKGROU.OBJ(BACKGROU) : 'DECRYPT' : unresolved external
>>OBJ\EYECOLOR.OBJ(EYECOLOR) : 'WAITKEY' : unresolved external
>>OBJ\EYE_UP.OBJ(EYE_UP) : 'CSROFF' : unresolved external
>>OBJ\FUN.OBJ(FUN) : 'BEEP' : unresolved external
>>OBJ\P_MENU.OBJ(P_MENU) : 'ENCRYPT' : unresolved external
>>OBJ\TS_BOX.OBJ(TS_BOX) : 'BOX' : unresolved external
>>OBJ\INSTALL.OBJ(INSTALL) : 'ISFILE' : unresolved external
>>OBJ\TS_PSCRN.OBJ(TS_PSCRN) : 'ALLTRIMLEN' : unresolved external
>>OBJ\TSPROMPT.OBJ(TSPROMPT) : 'ALEN' : unresolved external
>>OBJ\TSPROMPT.OBJ(TSPROMPT) : 'AMAXSTRLEN' : unresolved external
>>OBJ\TS_HELP.OBJ(TS_HELP) : 'MX_VIEW' : unresolved external
>>OBJ\NSETCOLO.OBJ(NSETCOLO) : 'ATTRTOA' : unresolved external
>>OBJ\NSETCOLO.OBJ(NSETCOLO) : 'ATOATTR' : unresolved external
>>OBJ\NSETCOLO.OBJ(NSETCOLO) : 'STREXTRACT' : unresolved external
>
> Some of these are fancy replacements for standard Clipper functions,
> like for example waitkey() that takes a number of clock ticks instead
> of a number of the seconds that inkey() takes as argument, strcenter()
> which seems to do what padc() does, alltrimlen() which is the same as
> len(alltrim()), there are a couple of functions replacing loops that
> look at content of arrays, etc.
>
> The encrypt() and decrypt() functions in Funcky are very basic, xoring
> the character string with the encryption key, character by character.
> Much too basic for any serious encryption needs, actually. The code
> below (it needs more testing, I think, so let's call it preliminary)
> is based on a comp.lang.clipper discussion in 2004. The decrypt()
> function is identical to encrypt(). Only 7-bit ASCII is supported (see
> the Funcky docs).
>
> function encrypt(cString,cKey)
> local i,cNewString := ''
> i := int((len(cString)/len(cKey))+1)
> cKey := replicate(cKey,i)
> for i := 1 to len(cString)
> cNewString += chr(numxor(asc(substr(cString,i,1)),;
> asc(substr(cKey,i,1))+128))
> next
> return cNewString
>
> If there are additional executables that you need to convert, maybe
> you should create a combined list of the Funcky functions you need in
> all of them so you can evaluate the size of the project more easily.

Yes, I'm going to newly 'clipperize' the proggies I noted above, and
then get a comprehensive list of Funcky funcs that I need.

But Francesco said he had no problem using Funcky with xHarbour -- but
*which* version of Funcky ??? (I'm currently testing on Version 2.6)

I would like to be 'free' of Funcky for the xHarbour work if possible,
and a set of replacement functions would be a good step in that direction.

Also, I note there are a lot of Files with start with TS??????.prg or
TS_?????.prg. Anyone know what/who is TS ???

(and yes David, I have a copy of the 2.6 documentation -- thanks for
your pointer)

Thanks Klas for your helpful guidance. I'll go after the encrypt/decrypt
stuff first. btw, I removed all the great struff on *lanman* from the
script file before presenting it in this forum above. I guess I can put it
back in again )

Another btw, I'm low man in the clubhouse today on the first of two
Senior's Golf Championship rounds (next round is next Wednesday. Today I
shot a 78. Very good for me. (But as the old British saying goes: "After the
Lord Mayor's Parade comes the sh%t wagon" ) )

-Mel Smith

> "> Does this mean that the list of unresolved externals will grow when
>> you move on to the less simple executables?
>
> Very probably ! There are another three major executables that I have
> yet to tackle The Gun Shop maintenance program and two Cash Register
> proggies. Both are sizeably bigger and more complex than the current Util
> program which handles re-indexing and other utility tasks)

I don't remember exactly what the lady requested, just a functional
upgrade or a full GUI rewrite (depending on the budget)...
in the first case it is really important that you can get the programs
compiling with no code changes
in the second case you may go via another route: complete code
refactoring....

I never wrote mouse handling code in clipper - probably you should
check that no special mouse handling is requested (I mean "gestures" and
the like). If it's all standard mouse... then no problem.

You should also check if they use a "form engine" or if the forms are
hard coded with @ say/get... In a GUI conversion it can be tedious to do
all the work...

Also the print system can be an issue if you have to interface to old
serial/parallel only printers....

I'd conitnue trying to compile all the source code, listing the
unresolve functions.
I'd then rewrite the standard ones as functions or as #command (they are
simple enough)
For the mouse related... I'd "grep" the source code to see haw these
calls are distribuited in the code. If they are "shielded" by a
class/function level or not... then decide how to proceed depending on
the lady request...

Francesco
PS: yes, I know, no real information here, I was just "thinking aloud"...
PPS:
> But Francesco said he had no problem using Funcky with xHarbour -- but
> *which* version of Funcky ??? (I'm currently testing on Version 2.6)

It was Rene ....

Dear Mel Smith:

"Mel Smith" <medsyntel@aol.com> wrote in message
news:6hmgvlFmm61aU1@mid.individual.net...
> (Before discussing Klaus's struff, Let me say
> that Frank van Uffal (of our ng) found why my
> Clipper conversion failed with a DPMI Protection
> error: He determined that removing the
> 'ctusp.obj' file reference from the script cured
> the crash !

Because you cannot use 16-bit binaries in a 32-bit application.
Clipper was 16 bits... object and library files for clipper are
16-bits. Clipper was DOS and in a WinDoze "DOS box", was allowed
to do certain things that are not permitted of a true WinDoze
application.

> And I've had that file in *all* my old Clipper aps
> for years !! I wonder why removal of that file
> now crash ?? All of my currnt (but old and
> running Clipper apps) use ctusp.obj with no
> problem ??? )

Now you know.

David A. Smith

Francesco said:

> For the mouse related... I'd "grep" the source code to see haw these calls
> are distribuited in the code. If they are "shielded" by a class/function
> level or not... then decide how to proceed depending on the lady
> request...
>
>> But Francesco said he had no problem using Funcky with xHarbour --
>> but *which* version of Funcky ??? (I'm currently testing on Version 2.6)
>
> It was Rene ....

Francesco:

Thanks for your thoughts ! (I' guess I'll have to re-direct my query to
Rene )

-Mel

David said:

>
> Because you cannot use 16-bit binaries in a 32-bit application. Clipper
> was 16 bits... object and library files for clipper are 16-bits. Clipper
> was DOS and in a WinDoze "DOS box", was allowed to do certain things that
> are not permitted of a true WinDoze application.
>
>> And I've had that file in *all* my old Clipper aps
>> for years !! I wonder why removal of that file
>> now crash ?? All of my currnt (but old and
>> running Clipper apps) use ctusp.obj with no
>> problem ??? )
>
> Now you know.

David:

I guess I missed something in your explanation ?

I can freshly recompile/link all my own old Clipper apps in protected
mode (where ctusp.obj is linked in), and I 'run' them on my Windows XP Pro
machine in a Command Prompt box (using CMD.EXE), and all with no problem !

But this other newly compiled/linked app crashes unless I remove
ctusp.obj ?? (Is there something in the Funcky libs that would cause
ctusp.obj to cause the fault ??)

So I don't quite understand your note above. Whay am I missing please ?

-Mel

Dear Mel Smith:

On Aug 28, 8:27*am, "Mel Smith" <medsyn...@aol.com> wrote:
....
> * * I can freshly recompile/link all my own old Clipper
> apps in protected mode (where ctusp.obj is linked in),
> and I 'run' them on my Windows XP Pro machine in a
> Command Prompt box (using CMD.EXE), and all with
> no problem !

Compiled with... what? xHarbour? Remember the newsgroup you are
posting to.

> * * But this other newly compiled/linked app crashes
> unless I remove ctusp.obj ?? *(Is there something in
> the Funcky libs that would cause ctusp.obj to cause
> the fault ??)
>
> * * So I don't quite understand your note above. Whay
> am I missing please ?

Same here from your description. Which is why I worry about mystery
OBJ files and libs from the age of DOS.

Yes, it is entirely possible that Funcky triggers a call to a bit of
code in that object file that performs a forbidden operation in the
WinNT platform (inclusive of XP). Such forbidden operations include
IN and OUT to serial ports... like for mice / trackballs, perhaps in
initialization required when using DOS (which was blind to pointing
devices). The OBJ may overlay valid bits of code since it is linked
in later, providing no error when removed, and no error when the bad
code is not called (your first application).

Yet another reason to avoid 3rd party libs... *always*, unless you get
source code.

David A. Smith