I have been asked to update a program written in 1987 in Delphi (I guess). I have no documentation about this program only a few side notes the programmer took that don't make too much sense to make.
The cd show this files:
Size | Filename
19956 VP.DTA
142300 VP.LEX
404 VP.NDX
126502 VP.RCS
131016 VP.SCR
150067 VP.XEL
101791 vp.exe
Is anyone of this files a database? If so can I access it's data?
I tried several code decompilers but they show a message saying it was not a Win32 compatible application.
The program run in MS-DOS.
Is it possible to obtain the source code? Can I use this code in any way to build a new application?
Update01: I can run the program in MS-DOS. The program conjugate verbs and shows an example sentence where the verb can be used. The GUI is a little bit confusing and there is no help menu so I can't see all the capabilities of the program.
Update02: In conversation with the owner of the program we found another solution. He ask me if it was possible to have the program in a server and the clients could login in with a user and a password and execute the program in a terminal. I have an account in my university server, which I can access throughout ssh and compile and execute c programs in it. The server is in linux so I couldn't try the program in it. If I set up a windows server, can I have multiple people accessing and executing the program in a terminal? The program is an exe. Doesn't this raise some security issues?
Delphi is from mid nineties, so that probably means Delphi's ancestor Turbo Pascal, not Delphi.
Some extensions sound familiar, as shortened versions of words:
ndx = index
dta = data
scr = screen (?)
lex = lexicon (list of words or deduped strings in general) (?)
Screen was sometimes used for e.g. helpscreens, a medieval form of helpfiles, they are typicall ansi screens that can be loaded directly into screen memory
There is a fair chance that this is something handcrafted, specially if that date of 1987 and the general assumption "pascal" is true, and not generated by some known database package at all.
Reverseengineering the fileformat might be a more worthwhile way than trying to reverseengineering the app.
A good start would to be to take a the unix "file" command to see if it can recognize the file types. (the file command searches for signatures inside files, and there are windows ports. I use Cygwin's)
A devel experienced in such matters can also see a lot from a hexdump (specially the first parts of a file)
Is it possible to obtain the source code?
Probably not, you may want to look at something like IDA Pro which can disassemble applications to C using something like Hex-Rays.
Do you know what the application is supposed to be?
If it's ms-dos, you're probably better off just drawing up new requirements and doing new development.
Look for DeDe to reverse engineering a delphi compiled program. But as far as i know, delphi is a real compiler. So there is no way to de-compiled it. If you are able to read assembler code then you can try de-compile it. Clipper and Foxpro (dos version) are another stories cause they not real compiler.
This is definitely not Delphi. It might be one of the database centric languages like Clipper 1. .SCR probably means "screen" and defines I/O masks. .NDX is a table index and .DTA means "data".
If it is clipper, you might actually be lucky, because as far as I remember these programs were P code, so it could be possible to decompile it.
It looks like CLipper (NDX and SCR). If you have a DBF file then it's Clipper for sure. But some people renamed the DBF to something like DAT. If it is Clipper, I believe there was a decompile named Valkyrie.
Related
I have the "wonderful" task of maintaining a legacy program that I didn't write. The Cobol program runs in a z/OS 2.2 environment and is compiled with IBM Enterprise Cobol 5.2. For debugging I would like to compile the program with the option CBL LIST, TEST (EJPD, SOURCE). Unfortunately, my source code has more than 999999 lines, so there is an error when compiling.
Is there a way to circumvent the limitation of the number of lines or is there only a way to split the program?
The 999999 limit on number of lines has been present since at least VS COBOL II, released in the mid-1980s. It's also present in Enterprise COBOL 6.3, the latest version prior to the compiler as of this update.
Perhaps someone is having you on, presenting you with uncompilable source. This is a compiler limit, and as #SaggingRufus has indicated, the solution would be to break the program up into multiple modules.
I would contend that a million+ lines of source code is incomprehensible.
Other mechanisms available to you include evaluating the code, looking for statements that span multiple lines for no good reason...
MOVE
A
TO
B
...is just silly.
As an aside, maintaining code you didn't write is part of the job. It used to be normal to put the new employees through a period of maintaining the existing code base to get them familiar with shop standards, etc.
Depending on the JES version, I believe you can you the WARNING parameter which would look something like this
//JOB10 JOB 1234,ME,LINES=(999999,WARNING)
This tells the system to continue even if the line limit is hit and only issue a warning.
Alternatively, you could output this compile listing to a file rather than a SYSOUT. Then the line limit would not apply
Also keep in a mind the having that many line in the JES spool is not a good thing, so I would recommend going the file route.
I want to evaluate the performance of Rascal for a given rewrite system that I've written. I'm wondering if there's a good way of doing it?
Ideally, I'd generate some compiled Java classes from the system and then run them manually against my inputs. Is there an easy or recommended way to do it?
Cheers,
One way to do this is to use the functions in the library util::Benchmark. Typically, you could write something like
cpuType( (){ call_the_function_I_want_to_observe(); } ). This will execute your function and print the cpu time used.
Note that Rascal can be executed in two ways: interpreted and compiled which makes a big difference when measuring performance. We are working hard at the moment to fully integrate the compiler in the Eclipse IDE, but a stand alone version is available as well. This can be called as java -Xss8m -jar rascal-0.8.4-SNAPSHOT.jar --compiledREPL followed by at least values for directories for sources (--src), and binaries (--bin). Here rascal-0.8.4-SNAPSHOT.jar (but most likely named differently) is downloaded from the https://update.rascal-mpl.org/console/rascal-shell-unstable.jar.
If you need more information, don't hesitate to ask for more details: this part of our tool chain is unfortunately still undocumented.
I'm trying a long-time to find algorithm PSOLA (Pitch Synchronous Overlap Add) or WSOLA (Waveform Similarity Overlap Add) which are Acoustic or Signal Processing Algorithms.
I found it in c++, but I have no experience in c++ and is difficult to pass it to Pascal. Anyone have this code in Pascal or know where to find it to copy?
Something like this example that is in c++
http://sourceforge.net/projects/mffmtimescale/files/v3%20stable/v3.9/WSOLA.v.3.9.zip/download?use_mirror=ufpr
Try the SoundTouch DLL, it comes with a Delphi import unit, so you can use the DLL directly. It should not be too hard to compile it. Just download the free VC++ Express from the MS download site and compile it with that or ask someone with VC++ to compile it for you.
FWIW, who knows, with a few modifications, it might also compile with C++Builder.
About one decade ago, I've used praat in FSeqEdit (Delphi program) to do these type of calculations, but I think the same approach would still work fine today.
I wrote some praat-scripts and execute them via praatcons.exe (console version of praat). You can download the console version from this page:
http://www.fon.hum.uva.nl/praat/download_win.html
That works pretty good.
I usually take this approach:
I manually check what type of conversions and calculations need to be done via the GUI version of praat. Once I find what I need, I create a script for it, and run that with the console version.
Praat is very powerful, so if you didn't know about it yet, make sure to check it out.
There's a page that shows how to work with PSOLA resynthesis here:
http://www.ling.ohio-state.edu/~kyoon/praat-tut/praat-tut2.html
Let me know if you want to see some example code on how to integrate it into your Delphi application (it's pretty straightforward actually).
So here is the problem: Recently someone bought a new PC for server to replace an older dating from before 1985 (i wonder how it is possible to work daily from then) .
He wants to put there the old COBOL software and he isnt willing in any means to rewrite it to something better..
So is there any compiler for 1985 cobol? For nowadays red hat linux? Googling it found opencobol and other few but all converted the code to c... Seems too compilacted too me..
UPDATE AS REQUESTED
AIX was the old system
What's the problem with converting the COBOL to C and then compiling? As long as it works. Early C++ environments were implemented in the same way: they converted the C++ to C, and then invoked the C compiler.
Converting the COBOL to C allows them to use high-level abstractions that implement the COBOL equivalents in C. They can leverage the standard C libraries, and also convert the COBOL data access code into calls to widely available databases like MySQL. Finally, converting to C and then compiling leverages the vast amount of development effort that went into code generation. Were they to try compiling directly to object code, they'd have to generate the intermediate code expected by the GNU compiler subsystem, or they'd have to go directly to object code. Either one of those would be much more complicated than converting to C, meaning that the likelihood of bugs in the COBOL compiler would be much higher.
From where I sit, I'd say OpenCOBOL is worth looking into. Note that they say they implement "a substantial part of the COBOL 85 and COBOL 2002 standards." You probably want to make sure that they implement the parts that you need.
I would also suggest that you look into TinyCOBOL.
You don't mention when the application, or AIX was last updated. If these were updated in the last few years, you may be able to port the application, without re-compiling. You should check to see what COBOL compiler was used originally, e.g IBM, RM/COBOL, AcuCOBOL, etc. It might be possible to buy a run-time only version (will execute, but not compile), which would be cheaper than buying a compiler.
A company called Micro Focus make a cobol compiler for Windows but I can assure you it is not cheap at all!
Standard method for doing this is called migrating and involves a number of steps including converting source file to a textfile format or a filetype compatible with the target computer, using an approved method of converting to a file and writing to magtape with compatible recording method of Phase encoding or to disk or other data medium possibly in the ASN.xx mode, transferring to the new computer to then read in the file (through ASN.yy) and store it in a native or import file format, then either use a utility to convert it to the sourcefile format or by running the program development environment to access the native text file or import file and saving the content as a native sourcefile. Perform manual checks and amendments to the source or script code and then compile the program and repeat alterations until a working version is achieved. Create test data files on the new computer and create a new jobfile or macro to run the job in the development environment. When fully tested the program can be run live using data files and live macros or jobfiles migrated over from the old system or newly created in more or less the same way as bringing over the source code. An important point is that the live data must be read into a specialized data takeon or loading program to achieve a populated database before any new transactions occur in the case of a structured datafile being necessary. When moving from AIX or other versions of Unix to an entirely different operating system the characters for end of line and linefeed and end of record may need specific conversion if they are not handled by a file format convertor or exporter utility.
i have an application which call another console application and pass to it some parameters (console app is a video/audio coverter app) ... is there a way to programmatically "spy" or catch the passed paramters other than hooking/monitoring shellexecute/CreateThread etc ?
Create an executable yourself that just calls the original and passes all parameters on to it. Then move the original somewhere else and replace it with your exe. Your program can then log all calls to it, including all parameters.
Yes, there is - as you write Process Explorer is able to do it, and you could employ the same technique. But AFAIK there's no Delphi translation of the winternl.h file from the Platform SDK, so it is even more tedious and difficult. Also this is extremely version-specific, and there are chances it will break with the next Windows version. It's also not quite clear whether this works for 64 bit processes (from a 32 bit process).
If you really want to do it you will find the necessary information in this blog posting by Matt Pietrek, and in the CodeProject article "Read Environment Strings of Remote process".
If you do not plan to use it for closed source commercial programs then a look into the (GPL licensed) annotated version of the winternl.h file from the ReactOS project would probably also help.
It's a Win32 FAQ since 1992 : just read the PEB.
See on Win32 experts group.