Modern Software Experience



LongFamilyHistory (LFH) is a commercial genealogy program published by Philosoft Kft. The first public release was version 1.2.4 in January of this year. I briefly looked at version 1.2.5 in March. That version supported GEDCOM import, but did not support GEDCOM output. In was in fact a clear case of vendor lock-in, as it did not support any export, report or printing capability. There simply was no way to get any you put in out again, so my verdict was Utterly Unrecommendable.

These past months, Philosoft regularly released new versions and they just released version 2.0. Looking over the list of changes on their website, I noted that they added GEDCOM export in April, just a few weeks after I complained about its absence.


LongFamilyHistory is a free download. You can import large databases, but will not be able to edit anything but tiny databases of just 0 persons without purchasing a license. The download is about 2½ MB.


The installation supports both English and Magyar (Hungarian). It detected the older version of LongFamilyHistory and installed the new version into the same directory. I expected a quick install, but experienced minutes-long hard disk rattling while it probably unpacking the setup program. I was given a chance to pick another directory, and the actual install was offer in mere seconds. The setup program always creates a desktop icon.

user interface

Overall, the user interface is simple and straightforward. I find the gradient it uses for the menu distracting, but it is an otherwise unremarkable and easy to use interface. The program has keyboard shortcuts and accelerators now.

The program always opens the last database you had open before you closed it. With larger databases, that can take some time. It hardly saves time, as the the file menu already list the recently opened databases.

The program offers several more views now, but none of these are on the View menu. All the views are on the Tool menu, and all the these are not under the View menu, the view menu offers several options that should be on the Options menu.


An improvement over the previous version is that LFH supports more locales now. Philosoft still claims to support English, it even shows the Union Jack in the language selection dialog box, although it still supports Amglish only, and should therefore be displaying the Stars and Stripes instead. The locales supported by version 2.0 are Amglish, Hungarian, German and Polish. There are two help files, an Amglish one and an Hungarian one. There is no German or Polish help file.

GEDCOM import


Import of the 1 MB GEDCOM took maybe four seconds. It was surprisingly quick. There was dialog box with some import messages, but when I clicked that away, the main screen remained empty. There was no visual confirmation that a database had been loaded at all. However, when I exited and restarted, it immediately showed the data I had loaded.


Import of the 100k INDI GEDCOM took1h28m13s (5293s). During import, memory usage peaked at around 200 MB. After the import, the program was unresponsive for several minutes. Whatever it was doing, it had nothing to do with finishing the import itself, it had already written the database file. The program’s memory usage had shot up to about 380 MB MB already when it crashed and simply vanished from the screen.

When I started it again, and asked it to open the database it had created (LFH is apparently smart enough not to do this automatically when it failed loading it the last time), the program was busy for about four minutes, and when the memory usage was about 380 MB, crashed again. This is repeatable.

16-bit limitation?

There is a several reason that I test with a database containing hundred thousands individual. One is that it is a nice round number that makes it easy to do some mental arithmetic. Another is that it is more than 65.536.

LongFamilyHistory works fine with smaller databases, managed to import the database, and there is plenty of memory left for it to work in, yet it always crashes when I try to load the created database. Perhaps there is some other issue, but my first guess is that some parts of the program use 16-bit arithmetic, and fail when presented with a database that needs 32-bit numbers.

Although the import operation itself seems to have completed successfully, I consider this import failed, simply because the program is unable to show that it imported successfully.

import listing

LongFamilyHistory still shows an overview of messages when the import is done, and still does not create a proper import listing. It does not even write a post-import report. As soon as you click okay, all the import messages are lost.


You may remember from my initial review that LongFamilyHistory is one of those programs that displays all individuals graphically. The program has multiple views, and defaults to the Person List, but probably starts creating the graphical view as soon as you load the database. Perhaps loading the 100k INDI database did not fail because part of the program use 16-bits to enumerate the individuals, but because the 32 bits it uses for its graphical calculation are insufficient for the size of the resulting graphical display.


I tried version 1.2.5 with the royalfam.ged file, a file of f 3.579.808 bytes containing 8753 individuals. I tried the database again, to at least have an import speed a moderately sized database. Version 1.2.5 imported it in 140 seconds, that is 62,5 INDI records per second.

Without the Byte Order Mark, LFH imports the file in 1m08s (68s). That is about 128,72 INDI records per seconds. That is not stunning, but it is more than twice as fast as version 1.2.5.

don’t get excited about that though. If LFH has succeeded in importing and displaying the 100k INDI GEDCOM, its import time of 1h28m13s (5293s) would put LFH firmly among the slow programs at the bottom of the geneapack, in fact in between the two best known laggards, TMG 7 and FTM 2008.

GEDCOM export

GEDCOM export of the 1 MB GEDCOM takes about 3 seconds. Exporting the 100k INDI database was not possible, as the program crashed before I could select that menu item.

The GEDCOM export does not allow you to pick a character, but always uses UTF-8. That is the best encoding a program can use, but it would be nice if a future release added ANSEL support.

A quick look at the generated GEDCOM file did not discover anything out of the ordinary. When I imported it into Ancestral Quest (AQ) as a practical test, AQ complained about the many REFN and TYPE tags it does not understand as if these are errors, but that seems to be an issue with AQ’s GEDCOM reader.

The one fairly obvious mistake I noticed is that LFH exported the file without asking for submitter information, and thus exported an empty submitter record.

A less obvious mistake, but one I will keep mentioning until vendors do it right is using UTF-8 yet labelling the GEDCOM file as GEDCOM version 5.5. The GEDCOM 5.5 specification does not allow UTF-8, support for UTF-8 was introduced in GEDCOM 5.5.1, so any GEDCOM file using UTF-8 must label that file as version 5.5.1 (or later, but there is no later version), not 5.5.


Of course, if the export does not support ANSEL, I have to wonder about the import. Generally, a program will support both or neither, simply because the conversions to and from ANSEL are developed together.

When I tried a small ANSEL test file, the program put up a messagebox stating "The file "anseltest.ged" has data inconsistent with this application, it cannot be loaded". My first thought was that it is not the clearest error message possible, but that he program does at least admit its limitations, but I was actually trying to load the GEDCOM instead of importing it. When I imported it as I should, LFH loaded it just fine.

LFH does support ANSEL on import. It even supports UTF-16 (called "UNICODE" in GEDCOM). Like so many other genealogy programs, its ASCII support is broken, it does not recognise illegal character.

UTF-8 support

When PAF writes a GEDCOM in UTF-8 encoding, it starts that file with with a Byte Order Mark, as it should. That Byte Order Mark tells text processors that the text file, which may superficially look like an ASCII or file or any ASCII-page code page, is an UTF-8 file. So when you load the file into NotePad, it does not have to make guess as it otherwise does with incidentally surprising results, but it will be know the file is UTF-8 and not mess things up when you edit it and save it as something else.

When LFH writes a GEDCOM file, it omits the Byte Order Mark (BOM). Like PAF, LFH will read UTF-8 files with and UTF-8 without a Byte Order Mark. The only point of criticism on the UTF-8 support is that it does not write the Byte Order Mark.


This version will print some charts, but the program still does not support any reports.


LongFamilyHistory (LFH) is improving. It supports GEDCOM export now and the GEDCOM it makes look good. LFH 2.0 will read ANSEL, UTF-8 and UTF-16 GEDCOM files. It additionally reads ASCII and "ANSI" GEDCOM files.
LFH writes UTF-8 GEDCOM files only. You may encounter incidental problems viewing the GEDCOM files in an editor like because the Byte Order Mark is absent, but should never lose any data importing into other programs - unless you use some truly backward programs that still do not support UTF-8. That said, it would still be nice if LFH offered the option to export in ANSEL encoding.

The graphical display of the medium sized file remains looks nice, but LFH still cannot handle large databases. The 100k INDI GEDCOM tests reveals that GEDCOM import and file loading are still slow, and that LFH still just isn’t up to it.

This is still a rather basic program, that does not even provide any reports. The chart-based interface makes this program worth a look, but you are unlikely to make this your primary program. It is still a very basic program.

GEDCOM import

time in seconds4 -
INDI per second1.215,50 -
bytes per second263.973,75 -

product details

companyPhilosoft Kft.
price29 Euro
requirementWindows 2000 or later
notecannot handle large files
Verdictimproved, worth a look


2011-06-12: gone

The domain no longer exists.