Convert to Harbour from Clipper Winter 85
VTM
I have several very old applications that were written in the original
Clipper, Winter 85 version.
I have been casting about for awhile now trying to find a way to move
them (without a complete re-write) to a more contemporary
environment. I have just stumbled across Harbour and was wondering if
it is truly backwards compatible all the way to Winter 85.
Since this version was text-based and primitive by today's standards,
most of the applications do not push the limitations of the language.
The underlying databases are dBase III+, naturally, and we would not
want to have to perform and conversions on the files themselves.
It would be great (ideal, actually) if Harbour would compile the
ancient code without modification, while providing additional
flexibility for future development.
Any thoughts and comments would be appreciated.
Klas Engwall
The official answer is that yes, your old code will compile without much
(or possibly any) modification. But in reality it depends on the
programming habits you had back then. I discovered my bad habits when I
upgraded to Clipper 5.x and had a few mysterious bugs jump up and bite
me. You will discover yours now. So be prepared to test everything
carefully.
It also depends on whether you used any 3rd party libs or not. But you
did not mention any. And there is no support for the old dBase .NDX
indexes, but switching to .NTX is a simple step if .NDX is what you use now.
Harbour is Clipper 5.2/5.3 compatible, and Clipper 5.x was a big step up
from S87 and earlier but did nevertheless accept all the old code. You
will notice the same with Harbour, with probably a few minor exceptions.
Install Harbour, either the bleeding edge nightly release or the latest
official 3.0.0 from six months ago. Start with a small Hello World
example to get the hang of the tools, and then jump to the smallest of
your old applications as your first project. Read up on how to build
with Harbour in the INSTALL file that can be found in Harbour's root
directory. For the language itself Harbour relies heavily on the Clipper
docs. There are of course a zillion extensions, but you will not need to
learn about them for the initial conversion. Everything new in Harbour
is documented in the changelog, and many times reading the source code
can also give you valuable insight. So download the sources too from the
start, not just the binaries.
Last year we helped a newbee who had inherited an old Clipper app and
had a weird "file not found" problem when testing his Harbour built
version. It turned out that there was a space in front of the file name
in the source code, and apparently Clipper silently removed that space
and found the file, Harbour, on the other hand, took the file name
literally and could not find the file. That is an example of what I mean
with old bad habits that might cause problems.
Hope this helps, and welcome aboard
Regards,
Klas
Przemysław Czerpak
Hi Klas,
> Last year we helped a newbee who had inherited an old Clipper app
> and had a weird "file not found" problem when testing his Harbour
> built version. It turned out that there was a space in front of the
> file name in the source code, and apparently Clipper silently
> removed that space and found the file, Harbour, on the other hand,
> took the file name literally and could not find the file. That is an
> example of what I mean with old bad habits that might cause
> problems.
To clarify.
Harbour and Clipper works in the same way and both compiler pass
given file name to OS functions. The difference is only in the used
operating system. DOS formats passed files names to 8.3 convention
ignoring some set of characters which are not allowed in file names
and this creates the difference. If you need exactly the same behavior
then you have to use one of Harbour DOS builds without LFN support.
best regards,
Przemek
VTM
This would appear to be good news, and hopefully there aren't too many
places where sloppy coding or the use of a "loophole" will bite me.
No 3rd party libraries or extensions were used except one that was
written specifically to convert dates, post Y2K. If I recall
correctly, it is just a few lines of code in a UDF extension that we
wrote ourselves.
As to the .NTX indexes, we are already using them as even the early
versions of Clipper did not support the native dBase .NDX files.
There are a few areas where we did have to resort to "code-arounds"
where the early version of Clipper did not operate as designed. I'll
probably leave these in place as it probably isn't worth the extra
test time to remove them for the sake of "neatness".
VTM
Because this application actually runs in "DOS" (or what is left of it
in Windows, including 7) we only use 8.3 file names. Are you saying
that I can't use simple 8.3 file names in any version of Harbour that
supports LFNs? I'd hope that any version that supported LFNs would
easily support the 8.3 convention.
Thanks!
Massimo Belgrano
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users
Massimo Belgrano
Delta Informatica S.r.l. (http://www.deltain.it/) (+39 0321 455962)
Analisi e sviluppo software per Lan e Web - Consulenza informatica - Formazione
Przemysław Czerpak
Hi Massimo and Klas,
> in clipper if you use use databaseWhantOpen.dbf it open database.dbf
> in harbour open a databasewhantopen.dbf
> incompatible bur right
It's even more restrictive.
On case sensitive file systems (i.e. in Linux, MacOSX and
other *nixes) it's "databaseWhantOpen.dbf" what is different
file name then "databasewhantopen.dbf"
> 2012/1/18 VTM <vtm...@gmail.com>
> > Because this application actually runs in "DOS" (or what is left of it
> > in Windows, including 7) we only use 8.3 file names. Are you saying
> > that I can't use simple 8.3 file names in any version of Harbour that
> > supports LFNs? I'd hope that any version that supported LFNs would
> > easily support the 8.3 convention.
Look at Massimo answer.
By default Harbour passes file names to operating system (OS) "as is"
and what will happen depends on used OS and file system (FS), i.e.
this code works in DOS without LFN support:
dbCreate( "database_Custommer.dbf", aStruct )
USE database
but it does not work in other systems or even in DOS when LFN is
enabled and Harbour was compiled with LFN support,
this code:
dbCreate( "database_Custommer.dbf", aStruct )
USE database_custommer
works in MS-Windows and OS2 but it does not work in POSIX systems
where file systems are case sensitive.
So if you wrote your code carefullly without typos in thigs like
filenames then it should work out of the box (with the exception
to differences between CL5.x and earlier Clipper versions - Harbour
is CL5.x compatible). If not then you should expect that binaries
created by Harbour quite fast exploit problems hidden so far.
Similar situation is in function/procedure and variable/field names
though here it's intentional difference in Harbour core code.
For Clipper only first 10 characters are significant. We found this
as serious limitation so in Harbour this limit was extended upto 63
characters (in default builds) so code like:
public week_salary := 123.45
? week_salaries
works in Clipper but does not work in Harbour.
best regards,
Przemek
Massimo Belgrano
--
Massimo Belgrano
VTM
OK, I'm thinking that, at least initially, I will want to follow
Klas's suggestion and use the latest official 3.0.0 version from six
months ago.
At the risk of asking a dumb "newbie" question, I need to understand
if this version creates object or executable code. Some of the
documentation I read (perhaps old and not updated) seemed to imply
that Harbour will generate "C" source which will then have to be
complied with a "C" compiler that I do not have. Further, even if
Harbour does generate an object module (.OBJ), the only linkage editor
that I have is the one that came with the original version of Clipper
that I have (W85). Will that linkage editor, (PLINK86, I believe)
handle the output of the Harbour compiler and produce a
functional .EXE module?
It appears that unlike the earlier version of Clipper, the Harbour
compiler needs to be "installed" in Windows. Is that really
necessary, or is there a way to run it as a "stand-alone"? If
installation is required, is there a clean "uninstall" should I have a
need to do that?
Sorry about the "dumb" questions, but i want to know as much as
possible before jumping into this.
Thanks!
Klas Engwall
Thanks for jumping in. I agree I could have been more careful about the
technical reasons for the problems that developer had. My point, though,
was that there may be bugs in old Clipper code that do not matter in
Clipper/DOS but matter now after porting the same code to a new environment.
Regards,
Klas
Klas Engwall
> Because this application actually runs in "DOS" (or what is left of it
> in Windows, including 7) we only use 8.3 file names. Are you saying
> that I can't use simple 8.3 file names in any version of Harbour that
> supports LFNs? I'd hope that any version that supported LFNs would
> easily support the 8.3 convention.
Don't worry, it works just fine.
Regards,
Klas
Klas Engwall
> OK, I'm thinking that, at least initially, I will want to follow
> Klas's suggestion and use the latest official 3.0.0 version from six
> months ago.
>
> At the risk of asking a dumb "newbie" question, I need to understand
> if this version creates object or executable code. Some of the
> documentation I read (perhaps old and not updated) seemed to imply
> that Harbour will generate "C" source which will then have to be
> complied with a "C" compiler that I do not have. Further, even if
> Harbour does generate an object module (.OBJ), the only linkage editor
> that I have is the one that came with the original version of Clipper
> that I have (W85). Will that linkage editor, (PLINK86, I believe)
> handle the output of the Harbour compiler and produce a
> functional .EXE module?
If you decide to use the 3.0.0 version, then go to this page:
http://sourceforge.net/projects/harbour-project/files/binaries-windows/3.0.0/
The page states that the MinGW C compiler is included in the download,
so you get everything you need. The hbmk2 project manager calls both the
Harbour compiler to generate C code and the MinGW compiler + linker to
create object files and the final exe. It all happens in one single step.
Your old tools like PLINK86 will not work, and you can also not use any
old 16-bit object files or lib files in your new environment.
> It appears that unlike the earlier version of Clipper, the Harbour
> compiler needs to be "installed" in Windows. Is that really
> necessary, or is there a way to run it as a "stand-alone"? If
> installation is required, is there a clean "uninstall" should I have a
> need to do that?
The installer is just a convenience. It does not change your
environment. There is also an option to download a .7z file instead of
the .exe and unzip it manually.
> Sorry about the "dumb" questions, but i want to know as much as
> possible before jumping into this.
No problem. There is some info to start with on the page I linked to.
I use Harbour in a similar way to how I use Clipper: Open cmd.exe, run a
batch file that sets up paths etc, cd to the work directory, run the
tools from the commandline. There is an included IDE that you
investigate later, but start by working from the commandline just like
you always did.
Regards,
Klas
Klas Engwall
> This would appear to be good news, and hopefully there aren't too many
> places where sloppy coding or the use of a "loophole" will bite me.
I will keep my fingers crossed for your :-)
> No 3rd party libraries or extensions were used except one that was
> written specifically to convert dates, post Y2K. If I recall
> correctly, it is just a few lines of code in a UDF extension that we
> wrote ourselves.
It should be an easy conversion then.
> As to the .NTX indexes, we are already using them as even the early
> versions of Clipper did not support the native dBase .NDX files.
>
> There are a few areas where we did have to resort to "code-arounds"
> where the early version of Clipper did not operate as designed. I'll
> probably leave these in place as it probably isn't worth the extra
> test time to remove them for the sake of "neatness".
If your goal is just to survive when Ballmer kills the NTVDM, then there
should be very little need to change what you already have.
Regards,
Klas