Posted 18 years ago on 2/18/2006 and updated 6/12/2008
Take Away: Converting Your 16-bit Paradox for Windows applications to 32-bit Paradox for Windows
KB100309
Converting Your 16-bit Paradox for Windows applications to 32-bit Paradox for Windows
by Mike Prestwood
As a 32-bit Windows logo-compatible product, the 32-bit versions of Paradox (32-bit Paradox 7 and Paradox 8 and above) take full advantage of the 32-bit architecture and high performance of Windows 95, 98, NT and 2000, while maintaining compatibility with the Windows 3.x product. 32-bit versions of Paradox supports existing 16-bit versions of Paradox for Windows applications as well as data. In addition, it co-exists and shares data with Windows 3.x applications on the same network server. This allows you to add new 32-bit Windows applications while keeping existing Windows 3.x applications.
In the past, Borland advertised 100% compatibility with 16-bit versions of Paradox. I hope they soften this message. Perhaps they can say full compatibility. 100% compatibility implies you will have no problems. In fact, when you convert a large application from 16-bit versions of Paradox to 32-bit versions of Paradox, you are bound to run into a plethora of problems you will have to deal with. Most of which are unavoidable since Borland is porting Paradox from Windows 3.x, a 16-bit operating system, to Windows 95 and Windows NT, 32-bit operating systems.
Any time a product goes through a major overhaul, any files from previous versions may need to be touched. 32-bit versions of Paradox is no exception. As a Paradox developer you will need to modify existing 16-bit versions of Paradox applications to get them to work with 32-bit versions of Paradox. This article deals with current areas of concern in the beta version of 32-bit versions of Paradox. Remember, however, Borland may address some of these issues before the product ships.
Real problems
Let's start our discussion with the meat and potatoes of this article: the "real" problems facing you when you convert a large 16-bit versions of Paradox application to 32-bit versions of Paradox.
16-bit DLLs need to be recompiled
It is common knowledge that 32-bit Windows can run Windows 3.x 16-bit applications and those 16-bit applications can call existing 16-bit DLLs. 32-bit Windows accomplishes this by using a cooperative multitasking model used in Windows 3.x. All 16-bit applications share the same virtual address space, the same message queue, and the same thread of execution. By contrast, each 32-bit Windows-based application has its own address space, a private message queue, and one or more preemptively multitasked threads of execution. Since 32-bit Windows in a since emulates Windows 3.x, 32-bit applications can not call Windows 3.x DLLs. Since 32-bit Windows and Windows NT are 32-bit operating systems, you will need to convert all existing 16-bit DLLs to 32-bit DLLs. If the DLLs were written using Delphi, you simply need to get your hands on Delphi 32 and compile your existing 16-bit Delphi DLLs again. If your DLLs are written using another compiler, than refer to the company of that compiler for instructions.
Windows 3.x API Calls need to be updated to 32-bit Windows API Calls
Microsoft has upgraded the Windows 3.x API to support 32-bit variables. In addition, Microsoft has changed the names of most of the files the functions are in. For example, USER.EXE is now USER32.EXE. As a 32-bit Windows programmer, you will have to learn the new 32-bit Windows API.
IDAPI.CFG File Used Differently
In previous versions of Paradox, the IDAPI.CFG file contained all BDE data. You could use saveCFG() to save the current session settings to IDAPI.CFG. Now IDAPI is renamed to Borland Database Engine (BDE) and it's configuration is stored in both the registry and IDAPI.CFG. Alias info is stored in IDAPI.CFG and info like drivers and system are stored in the registry. You need to take this into account when you use saveCFG() and setRegistryValue().
No .INI files
Since 32-bit Windows use the registry database instead of .INI files, 32-bit versions of Paradox does not use .INI files. You can still use your own .INI files for your applications, however, you should use the registry instead.
One exception to this is the PDOXWORK.INI file. As you may recall, the PDOXWORK.INI file stores the references used in the Project Viewer. In the current beta version of 32-bit versions of Paradox, it is still used. I assume that Borland will get rid of all .INI files and move all settings into registry.
No PXDLITE.INI File
In 16-bit versions of Paradox, it was possible to customize the IDE menus so that they could launch custom forms, executables, etc. using the PXDLITE.INI file. Since 32-bit Windows use the registry database instead of .INI files, Borland moved the settings to it. The settings are in Paradox\7.0\PXDLITE.
Obvious & Trivial Problems
Let's move our discussion to obvious and trivial problems. An obvious problem is a problem you may have already thought about. Generally, obvious problems are problems any Windows 3.1 application will have when moving it to 32-bit Windows. A trivial problem is a change in Paradox that is easy to overcome or probably not used in most applications.
Redeliver all Forms, Reports, Scripts, and Libraries
As with previous Paradox upgrades, you will need to deliver all objects again in 32-bit versions of Paradox.
Filenames have changed
I don't think this next one will break many existing applications, but it will break a few. Many of the filenames have changed. For example, PDOXWIN.EXE is now PDXWIN32.EXE and IDAPICFG.EXE is now BDE.EXE. Some of us have enjoyed writing utilities for Paradox and giving easy access to the executables that come with Paradox. If this includes you, you will have to rewrite some code.
Minimized icons are now different
One of the changes Microsoft made in 32-bit Windows was to change minimized icons. Now you only get a small title style box. This severely limits the number of characters you can display while a form is minimized. If your application took advantage of this, then you will need to redesign it. For example, some developers liked to change the title of a form to reflect the name of the current record. They did this so that when it was minimized, you could see which record it was displaying. This was particularly handy when you had several copies of the same form open.
Constants are reshuffled in 7.0
Borland has warned consistently since 1.0 that you cannot rely on the values of a constant to remain the same. In 32-bit versions of Paradox, they were reshuffled. If you have broken this coding rule in order to expedite your development time, then you will be spending the time debugging your application when you run in 32-bit versions of Paradox. Borland added constants to the system to humanize the ObjectPAL experience. Rather than asking users to memorize and rely on numbers, you get to use constants like MenuFilePrint and DataBeginEdit.
Conflicting Short Cut keys
Paradox has its own short cut keys. With every version of Paradox, Borland figures out new an better ways to enhance its usability. If you use the standard Paradox menus and additional shortcut keys, then you may need to rewrite part of your application to be compatible with 32-bit versions of Paradox shortcut keys.
SendKeys() Problems
Since the user interface and shortcut keys are reorganized in version 7, any code you have that uses sendKeys() might need to be rewritten.
No Private Tables in open dialog box
Finally let's end with a real trivial change that I don't think will break any applications. In previous versions of Paradox, when you selected File | Open | Table, the tables in your private directory were listed at the end of the list of tables in your working directory. All dialog boxes were changed to match the 32-bit Windows dialog boxes and therefore the private tables are no longer included. I don't think this will break any existing applications, but I included the information here for completeness.
If you liked having the tables in the private directory listed on the Open Table dialog box, don't worry you still have easy access to them. When you select the Tables icon in the Project Viewer, the tables in your private directory are listed after the tables in your working directory.
After Conversion
Now that you have done the minimum amount of work needed to make your application work with 32-bit versions of Paradox, you're still not done. Your final task is to take advantage of some of the new 32-bit versions of Paradox and 32-bit Windows features.
New Windows Interface
The obvious change from Windows 3.1 to 32-bit Windows is the enhanced user interface of 32-bit Windows. You should seriously consider upgrading the look and feel of your application to the new 32-bit Windows look and feel. 32-bit versions of Paradox has all the new objects needed to upgrade your user interface including tabbed notebook, control slider, spin box, and others.
On the not quite so obvious, due to the Win'95 interface you may have to resize some forms that used to fit in a full screen. If you don't, they might show up with a scrollbar.
Move Code in the Form Open
In addition to upgrading your user interface, you also want to take a advantage of the new features of 32-bit versions of Paradox. Probably the biggest change to Paradox is the addition of the new init method which occurs just before the open method. The change to your code is simple, move all the code in the form open method to the form init method that does not need to work on every object. In other words, if the code in your open method is not in the prefilter section of the open method, then consider moving the code to the form's init method. This change will greatly speed up the time it takes to open the form.
Extended Uses
Of the many new features of 32-bit versions of Paradox, the new extended Uses syntax is probably the most important. Extended Uses syntax gives Paradox users compile time binding for the first time. Extended uses is similar in nature to include files in Pascal and header files in C. You can put all your constants and custom types in a library and use extended Uses syntax to bind them at compile time. In addition, you will no longer need to prototype your custom methods from a library because extended Uses can auto-prototype the custom methods for you.
Summary
Although Borland is claiming 100% compatibility, you have seen that 32-bit versions of Paradox is not 100% compatible. However, it is extremely compatible with your existing 16-bit versions of Paradox applications and you potentially will not have to change a line of code. The problems that do exist are a result of the new 32-bit operating systems of 32-bit Windows.
Converting Your 16-bit Paradox for Windows applications to 32-bit Paradox for Windows
by Mike Prestwood
As a 32-bit Windows logo-compatible product, the 32-bit versions of Paradox (32-bit Paradox 7 and Paradox 8 and above) take full advantage of the 32-bit architecture and high performance of Windows 95, 98, NT and 2000, while maintaining compatibility with the Windows 3.x product. 32-bit versions of Paradox supports existing 16-bit versions of Paradox for Windows applications as well as data. In addition, it co-exists and shares data with Windows 3.x applications on the same network server. This allows you to add new 32-bit Windows applications while keeping existing Windows 3.x applications.
In the past, Borland advertised 100% compatibility with 16-bit versions of Paradox. I hope they soften this message. Perhaps they can say full compatibility. 100% compatibility implies you will have no problems. In fact, when you convert a large application from 16-bit versions of Paradox to 32-bit versions of Paradox, you are bound to run into a plethora of problems you will have to deal with. Most of which are unavoidable since Borland is porting Paradox from Windows 3.x, a 16-bit operating system, to Windows 95 and Windows NT, 32-bit operating systems.
Any time a product goes through a major overhaul, any files from previous versions may need to be touched. 32-bit versions of Paradox is no exception. As a Paradox developer you will need to modify existing 16-bit versions of Paradox applications to get them to work with 32-bit versions of Paradox. This article deals with current areas of concern in the beta version of 32-bit versions of Paradox. Remember, however, Borland may address some of these issues before the product ships.
Real problems
Let's start our discussion with the meat and potatoes of this article: the "real" problems facing you when you convert a large 16-bit versions of Paradox application to 32-bit versions of Paradox.
16-bit DLLs need to be recompiled
It is common knowledge that 32-bit Windows can run Windows 3.x 16-bit applications and those 16-bit applications can call existing 16-bit DLLs. 32-bit Windows accomplishes this by using a cooperative multitasking model used in Windows 3.x. All 16-bit applications share the same virtual address space, the same message queue, and the same thread of execution. By contrast, each 32-bit Windows-based application has its own address space, a private message queue, and one or more preemptively multitasked threads of execution. Since 32-bit Windows in a since emulates Windows 3.x, 32-bit applications can not call Windows 3.x DLLs. Since 32-bit Windows and Windows NT are 32-bit operating systems, you will need to convert all existing 16-bit DLLs to 32-bit DLLs. If the DLLs were written using Delphi, you simply need to get your hands on Delphi 32 and compile your existing 16-bit Delphi DLLs again. If your DLLs are written using another compiler, than refer to the company of that compiler for instructions.
Windows 3.x API Calls need to be updated to 32-bit Windows API Calls
Microsoft has upgraded the Windows 3.x API to support 32-bit variables. In addition, Microsoft has changed the names of most of the files the functions are in. For example, USER.EXE is now USER32.EXE. As a 32-bit Windows programmer, you will have to learn the new 32-bit Windows API.
Paradox
Print This
