SCAN.EXE: incorrect GRAF-F Serial No.

[rafalcode]

Using dosbox in Debian, I mount and run SCAN.EXE merely to test. I run with the defaults, i.e. confirm everything with RETURN. However it fails with
GINOGRAF Version 4.2a(c) Copyright Bradly Associates Ltd 1999
*** Incorrect GRAF-F Serial No. - Program Aborted ***

I ran again and then get yellow screen, purple text. I gather these are GUI issues. Found a gino.con, with the serial number GBBAS044GF0106. Decided it could easily be the unix line endings. So, convert to DOS line endings. Rerun, but no change in behaviour.

Try several times. Incredibly, but just once, it is able to progress beyond this error and produces a SCAN run (i.e. I get several lists of some 15 float values, I take this to be a proper run). It has now settled back to producing the above error.

Have tried in 32-bit Windows COMMAND.EXE and get a garbled screen. Once more, suspect the GUI.

Have tried dosbox in Windows 64bit, but it claims to have trouble finding files.

May I ask, what about compiling the DCFORTRAN from scratch, say with gfortran? I suspect this will throw up a bunch of issues, 64 bit vs. 32 bit ... also the assembly code. Let it be said however, I did randomly try one FOR file, and it actually did compile to object with gfortran 64 bit, so it's not a crazy idea either.

[remislp]

Hi rafalcode,
I can confirm that SCAN.EXE runs in 32bit DosBox on Windows10 64bit machine. I will try to replicate that later in Kubuntu.
Running with defaults is not very good idea. Do not Auto-restart previous analysis and try to load file 'consam2.513'.

[remislp]

We are not maintaining DCFORTRAN programs anymore. Compiling from scratch with gfortran is not simple task.

[remislp]

I could not run SCAN via DosBox on Kubuntu 16.10 64bit. However, I believe it is DosBox problem: "Exit to error: DRC64:Unhandled memory reference". I could not find quick fix, thus, did not insist too much.

About compiling with gfortran. I have never tried to compile SCAN but I have tried some other from the same bunch (eg. HJCFIT, EKDIST, CVFIT). The list of issues was to long. The most problematic issues are related to GUI. We do not hold the GINO license anymore. Removing GUI related code in SCAN and replacing with any other GUI would be to much effort and probably equivalent to writing a new application.

[rafalcode]

Hi remislp,
Many thanks for checking this out. Yes, I also saw diferent behaviour from DosBox depending on the system (and the version of the system). Yes I have no doubt there it is a big job to modernise. My ion channel colleagues say there are alternatives, but none as good as SCAN, so it is a pity. The GUI issue is a big one though.
My experience tells me, that starting from scratch is the best. It does not sound like a good idea (you get accused of re-inventing the wheel) but it is more enjoyable, and could even be faster. In any case, you can use parts of the old code. Debugging old code tends to have more pain than enjoyment, and less satisfaction afterwards: my two cents. Cheers and thanks.

[remislp]

Hi rafalcode,
yes, DOSBox behaviuor is variable. Luckily enough it works well on all our Windows machines. Another option would be to run on virtual Windows XP (or earlier). In that case you would not need DOSBox.
Re-writing from scratch is exactly our intention. SCAN was not first in the line :-(
Cheers