I am moving some COBOL code from zOS to Linux and stumbled on this code at the top of a COBOL program:
CBL DATEPROC(FLAG),YEARWINDOW(-90) 004220CB
ID DIVISION. 004220CB
PROGRAM-ID. AL0001. 004220C
Are those compiler options that the COBOL compiler detects, or are they instructions to some kind of third party preprocessor.
My personal guess is that it is a third party processor that deals with Y2K issues in the code.
With IBM's Enterprise COBOL the CBL statement is one of several ways to provide compiler-options.
The options in your example are a bit of a special case since IBM dropped Y2K-support and thus the DATEPROC and YEARWINDOW options when moving from version 4 to version 5. With V5 compilers they should be flagged by the compiler but should not lead to a compile-error.
Related
We have large commercial app that we want to convert from Delphi 6 to 2010. Approx 10 3rd party component sets, all with source code... I have heard warnings about Unicode with 2010 - Does anyone have experience and or suggestions?
There are many resources available that you can read and that you will assist in the migration from Delphi 6 to Delphi 2009/2010 (Unicode).
You can use these articles as a guide.
Unicode Migration Statistics Tool (This utility will hopefully assist you in collecting useful statistics
on how hard (or not) it would be to migrate your older applications to
Unicode.)
Delphi 2009 and Unicode
Delphi 2009 strings explained by example
Upgrading a major project to Delphi 2009
Delphi and Unicode
Dr. Bob Delphi 2009 Unicode
Delphi 2009 - Unicode in Type Libraries
On Strings and Unicode in Delphi 2009
Delphi in a Unicode World Part I: What is Unicode, Why do you need it, and How do you work with it in Delphi?
Delphi in a Unicode World Part II: New RTL Features and Classes to Support Unicode
Delphi in a Unicode World Part III: Unicodifying Your Code
CodeRage 4 : Using Unicode and Other Encodings in your Programs
Bye.
You'll find some useful answers in these StackOverflow questions:
Move project from Delphi 3 to Delphi 2010
When and Why Should I Use TStringBuilder?
Convert function to delphi 2009/2010 (unicode)
Unicode problems with Delphi 2009 / 2010 and windows API calls
Also, for what it is worth, I purchased Marco Cantu's Delphi 2009 Handbook. It was all I needed to make a relatively smooth converstion from Delphi 4 to Delphi 2009 in only a few weeks.
I do, however, recommend that you ensure your 3rd party packages have a Delphi 2009 upgrade, or you may have some real difficulties. Converting your own code is one thing. Converting someone else's is another.
I use two 3rd party packages, both with source code. Both had upgrades available, and the developer of one of them wrote that he had a lot of trouble upgrading his very complex component to the Unicode of Delphi 2009. It took him a few months, but he completed it. And as a result, I had little trouble with my implementation of his component when I did my upgrade.
i've been in the same circumstance recently. you mostly need to pay attention to the "edges" of the app. INI files, file I/O, log files, etc. win API calls from delphi work since they've now connected the unicode API calls instead. check each 3rd party component set to make sure they're at least ready for Delphi 2009...better yet 2010. even my use of databases simply wasn't an issue...nearly everything worked right away. it just wasn't a big deal. anything that relies on the size of a character should be reviewed.
really the transition of most concern is 2007_or_earlier --> 2009_or_later.
there are plenty of discussions/blog entries about it. you could read, read, read...or you could get started & see what happens. (i did some of both). i'm sure there are "stack overflow" issues discussing your question. i'm not pretending to give a detailed description of what could happen.
it's simply not as scary as it sounds.
Approx 10 3rd party component sets, all with source code.
One thing I'd add is if the component doesn't support Delphi 2009/2010, don't try to upgrade it by hacking the code.
Following is what I posted on How do the new string types work in Delphi 2009/2010?:
See Delphi and Unicode, a white paper written by Marco Cantù and I guess
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!), written by Joel.
One pitfall is that the default Win32 API call has been mapped to use the W (wide string) version instead of the A (ANSI) version, for example ShellExecuteA If your code is doing tricky pointer code assuming internal layout of AnsiString, it will break. A fallback is to substitute PChar with PAnsiChar, Char with AnsiChar, string with AnsiString, and append A at the end of Win32 API call for that portion of code. After the code actually compiles and runs normally, you could refactor your code to use string (UnicodeString).
I must add this article from Carey Jensen to others mentioned. It is labeled: "Delphi Unicode Migration for Mere Mortals: Stories and Advice from the Front Lines" (in english).
http://www.danysoft.com/free/delphiunicodemigration.pdf
As you can see in the title of it, you will find many experiences and hints and tips. I think it is the answer to your question. After carefully read it, you will sure knows what to do next. :)
Found in: http://www.danysoft.com/productos/migrar-aplicaciones-a-delphi-xe-o-cbuilder-xe.html
Another point to take care of, is the usage of Variant types with strings and the VarType function testing for strings: one needs to use varUString instead of varString.
Assuming AValue is of type Variant and has being assigned a Unicode string value, the following won't work:
if VarType(AValue) = varString then ...
and needs to be changed to
if VarType(AValue) = varUString then ...
Once 64 bit Delphi will be releases (is it for 2012?) how will components will work?
I mean I use several 3rd party components: will they automatically work on 64 bit or not? Will they need to release 2 separate versions of the components?
I think you can compare it with the first release of the Unicode version of Delphi, Delphi 2009. When Delphi 2009 came out the 3rd party component vendors all supplied Unicode aware components pretty rapidly. Many had components ready at release.
In many ways, I suspect that the changes needed for 3rd party components to support Unicode will have been more onerous than will be needed for 64 bit. The 3rd party vendors will already be looking ahead and making use of NativeInt and NativeUInt types.
As for different versions, the normal practice from 3rd party component vendors is for their source code to compile on all supported platforms. If you are using packages then clearly you need different versions for different compilers but that's true today as well – components are delivered with packages for each supported Delphi version.
One point I would stress would be that if you have not already moved to a Unicode Delphi, then you should do that as soon as possible. You won't be able to move to the 64 bit version of Delphi without doing so and since you can port to Unicode Delphi now you really should get that out of the way.
In short, I have little apprehension over this issue.
In short: components might automatically work in x64 Delphi, however most of them likely need changes, especially when they use pointers or assembly language.
I know that the Delphi team strives for an upgrade path to be as smooth as possible.
But x64 - like Unicode - is a breaking change, so be prepared to update your components too.
Usually, platform vendors will brief 3rd party vendors before the general public so they have time to make their 3rd party products compatible with their new platform version.
Microsoft has done this for .NET, the Delphi team has done this for Unicode and .NET, and other vendors have done similar things.
Like Eugene mentioned, 3rd party library vendors could also use the x64 version of Free Pascal to get a feel of what changes might be needed.
When you look at the source code, you see that some vendors indeed do.
You can get yourself a feel for the changes too.
For instance, Allen Bauer uses his blog and his twitter feed to post some info on x64 Delphi. He also talked about Delphi x64 on this Delphi.org podcast interview.
Embarcadero has shown an alpha version of the Delphi x64 command-line compiler during roadshows and conferences, including the last virtual CodeRage conference.
--jeroen
Those vendors who look ahead, have already started to test their code (wherever possible) with 64-bit FreePascal. In general, the answer to your question is very specific to the component. If pointers are used extensively or if hardware is involved, adaptation of code will be needed. Otherwise there should be no significant problems on recompilation for 64 bits.
And yes, separate versions of code are required in any case for native code.
In which language is F#'s compiler written?
I've heard that F#'s compiler is written in F# :)
(each next version of F# compiler is written on its previous version)
But:
1. Can't google if it's true.
2. If it's true, in which language is the first version of the F# compiler written?
The F# compiler is written in F#. The source code is available.
It was originally bootstrapped years ago using OCaml, I believe (and perhaps a little C++ as well). (There is still a non-trivial subset of F# that cross-compiles with OCaml, though the F# compiler source base has long since diverged from that.)
The current implementation always uses an LKG (last-known-good) set of binaries (.NET DLLs and EXEs) to bootstrap itself when building from source.
I'm writing a program for both Delphi and Lazarus/FreePascal, so I can also reach customers using Linux or Mac OS X.
Is there a cross-platform tool that works in both environments too, so I can add multiple languages?
I tried GNU Gettext for Delphi and C++ Builder, but it does not compile in Lazarus for Mac OS X.
Is there anything comparable?
No, simply since the only system that FPC uses is gettext.
Lazarus afaik uses gettext, also on OS X, but obviously the FPC one, not the delphi one.
I suggest you devote some more attention to getting the gettext solution to work, maybe asking specific questions here.
In reply to your comment:
If I look in the LCL, I see in the translate routines stuff that translates properties of tpersistents, but only for special "TTranslatestrings" fields. So it doesn't seem to translate full forms directly.
Did you have a look at this:?
http://wiki.lazarus.freepascal.org/DxGetText
DKLang Localization Package is an open source project that works very well. It has not been tested under FreePascal, but we would be willing assist with any needed changes.
This one is note entirely free, but parts of it are: (The GUI editor isn't, but the code parts are, and the editor isn't strictly required):
http://www.be-precision.com/products/precision-langs/
In the company that i work, we develop all the GUI in C#, but the application kernel is mainly developed in Delphi 5 (for historical reasons), with a lot of components made in COM+. Related to this very specific sort of application a I two questions:
Experienced guys in Delphi and/or COM, do you have any workrounds to work with the buggy TLB interface ?
Some of the bugs are: IDE crashing during edition of a large TLB, lost of methods IDs, TLB corruption, etc.
Here, we haven't found any good solution. Actually we tried do upgrade do the new 2007 version. But the new IDE TLB interface has the same bugs that we found before.
How do you control TLBs versions ? The TLB file is in a binary format and conflict resolutions are very hard to do. We tried to do it exporting the interfaces descriptions to IDL and commiting into CVS, but we didn't found any good way to generate TLBs from IDL using Delphi. Additionaly, the MIDL tool provided by Microsoft, didn't parse correctly the IDL files that we exported from delphi.
I think you should have a good look at Delphi 2009.
Delphi 2009 has changes to the COM support, including a text-based replacement for the binary TLB files.
You can read more on Chris Bensen's blog.
In the distant past (before I started working for CodeGear) I gave up on the odd Delphi-ized IDL language that the IDE presented, and wrote my own IDL and compiled it using MS midl. This largely worked; the only catch, IIRC, was making sure dispids (id attribute) were correct on automation interfaces (dispinterfaces) for property getters & setters - there was some invariant that tlibimp expected but midl didn't guarantee.
However, now that Delphi 2009 uses a safe subset of midl syntax, and includes a compiler for this midl in the box and integrated into the IDE, these problems should be a thing of the past.
We have also just installed Delphi 2009 and it does seem to have improved the support for Typelibraries. However I have worked with COM and type libraries for quite some time and here are my general gotchas that I have found over the years. I would agree its pretty buggy and is all the way up to Delphi 2006 (our version prior to using 2009).
Always have every file writeable before opening. This may sound obvious, but when working with source control sometimes we forget to do this and try to remove readonly flag after opening a file - Delphi cant deal with this. Ensure tlb is writable before opening.
If editing a standalone typelibrary you MUST have a project open. For some reason if you open a type library on its own it will not save. Create a blank project and then open your typelibrary. For some reason this allows the type library to be saved.
If your type library is used by an application or COM+ ensure that application is shut down or COM+ disabled before opening the type library. Any open apps will prevent the type library from being saved.
However I think your best solution is probably an upgrade. You get Unicode support too.
Using Delphi 2009 has greatly taken much of the pain out of huge TLB files, and conversion of our existing objects was painless, but our com objects don't use any third party libraries.
We will be migrating our gui applications over once the library vendors release supported versions.
Same experience with the TLB interface here: we simply stopped using it.
We work with several separate IDL files (hand-build) for different parts of our framework, making use of the #include construct to include them into the IDL of the actual application, then generate the single tlb using MIDL and tlibimp it. If the application has no IDL of it's own, pre-compiled version of the different framework TLB files are available.
Whenever the framework enters a new version, a script is run to re-generate the GUIDS on all necessary interfaces in the IDL files.
This has served us well for many years, and for us to move over the new Delphi 2009 IDL/TLB toolset will have to be not only integrated into the IDE, but also versatile when it comes to automated builds and whatnot. Can't wait to get my hands dirty with some experiments!