I'm looking for a light-weight database engine for Delphi 1 (don't ask, it's a long story). Delphi 1 is 16-bit. The engine should compile into the EXE. SQL would be nice, but not mandatory. Any info would be great. Thanks, Carl
A 16-bit version of Microsoft Jet should be easy to integrate even with older versions of BDE (ODBC driver).
Otherwise you can use .db files (dBase - xBase), BDE should be able to handle them directly.
How about sqlite?
Turbo Power Btree Filer ? IIRC TP's is open source and TP was 16-bit.
Maybe this or the other DBF tool has 16-bit options. However the one I used (TDBF) doesn't afaik.
A long time ago I used VB/ISAM with Delphi 1. It works well with Delphi 16bit even though it was originally made for VB. It is from Software Source. I think we were using v4.x.
why not check on Delphi Super Pages web site. They use to maintain a complete code and component collections for Delphi 1.
I don't know the current situation though ;)
If you want I have a VBX based DB engine called VSData.
I never used Delphi 1 so I don't know as to how good it was at handling VBX. I have used this db engine as at that time this was the only engine to support storing multimedia files!
Related
I would like to know if it's possible to read a .mdb file without the use of ODBC.
I need to write a Delphi application that reads 2 columns from a mdb file and writes those columns in a postgreSQL database.
Is there a trick, Delphi component or method that I can use that does not depend on ODBC.
(For some reason ODBC on my devel-laptop is broken).
If need be I can also use Delphi 2007, and I even have a version of Delphi 1,2 and 3 somewhere as well.
You can use ADODB. It is part of Delphi 2007, at least. It does not depend on ODBC or BDE: it uses OleDB/ADO instead.
long long ago, there was Data Access Objects DAO, but it appears that these are deprecated (all the way at the bottom). Still, with a bit of luck you could still find documentation for it and use it.
in C# you can easily open an assembly (just another word from an EXE) and then get reflection information from that assembly. I've been looking for something similar for Delphi where I can write a Delphi program that can point to a Delphi EXE then get me reflection information. How can I archive this? Thanks
There are a handful of programs that can extract RTTI from Delphi programs and DLLs. It's not as rich as what's available for .NET, but it can be done to a limited degree. There's a lot more RTTI available in Delphi 2010 and later versions, but as far as I know there's no program out yet that can extract info from them.
I was at the conference where this system was formally announced, and a bunch of people asked how this would affect security. Barry Kelly, who created the new RTTI, said that there would not be enough metadata available to create a "Delphi Reflector".
Well, sad news is, you probably can't. You can easily view .NET assemblies because they a) are compiled to what is called intermediate language (thus you can even get the code back using the likes of Reflector etc.), and b) contain metadata. Delphi, on the other hand, compiles to native code that and produces regular PE files that do not include rich metadata like a .NET assembly.
Delphi just doesn't work that way.
There are tools that can assist in reversing (Delphi written) executables but it will never be easy and it requires good x86 assembly knowledge.
Some examples of such tools are:
IDA Pro and/or Hex Rays
DeDe
Interactive Delphi Reconstructor
PE Explorer
The resource sections of a Delphi Executable also reveals usefull info like the form and it's components.
See also Is there a program to decompile Delphi?
If you have Delphi2010+ you can load a bpl and then use the rich rtti over it lik. e you do with c# and a .net assembly. If you need to do this in a .exe AFAIK you can't.
TestComplete seems to identify most objects in a running Delphi executable. You can extract this information with a script. A demo can be downloaded from http://www.automatedqa.com/downloads/testcomplete
This is maybe not the type of application you want as it is big and made for GUI-testing, but yes it can identify the objects.
As mentioned Remko, IDR (Interactive Delphi Reconstructor) can extract all RTTI information (if program contains it!) for Delphi version from 2 to 2009. Version 2010 will be available later. Moreover IDR can use all information that it finds in program to create a lot of comments to disassemled program code (this is a first step of analyses). You can also look forms and easy go to event hadlers associated with controls.
I'm trying to generate _TLB import units for Outlook 2003, 2007 and 2010 (and also other OLE servers) analogous to the ones bundled with Delphi for Outlook 2000 and 2002. However, I couldn't get the type library importer to also generate the code for capturing events from the OLE servers that is found in the bundled units. The option to "Generate component wrappers" only creates wrappers for servers that are directly instantiatable but not for objects that are only returned via methods of other objects like TInspector, TExplorer, etc.
I could of course create the event handling code myself but that would be really tedious work.
Does anyone know if the importer contained with Delphi 2010 (tlibimp.exe) can be tweaked to generate that code? I really doubt that back in the day Borland created the existing Outlook2000.pas and OutlookXP.pas units manually...
Are there maybe any other tools around that can do this?
Good question! I never noticed that those components were not created (I only use Word_TLB). After playing a bit with tlibimp I found out that you need the -Yc+ flag. Probably all ignore flags are default on.
NB: this is on Delphi 7 with tlibimp.exe version 7.0.4.453
I have a few Delphi 6 third party components which I need to add to Delphi 2010 to begin my migration. Is it possible? The interface seem a lot different and I can't seem to find a way to do this?
This help...
My components: DBGridEasy, TSerial, Varian Async32.
Thanks a lot.
As has been mentioned this is not straightforward. But you do have options.
Check with Vendor and get update
if you have source you can try to update yourself.
I don't agree that it is neccesarily too complicated to upgrade. Delphi 2009 did add (finally - about a decade after it should have) very good Unicode support into the heart of delphi, but this was done down to the level of almost every built in function.
We upgraded a large (700,000 lines) project in only a couple of days. There is info on the net on what to do, there are a number of functions you need to replace if you use them (such as any funcion with Ansi in the title). Its worth a try at least.
If you dont have the source I'm afraid you have no choice but to contact the vendor, there is nothing you can do since the binary format for each Delphi version is differnt.
I don't know for sure about those particular components, but it probably won't work even if you have the source for them because there were many changes between those versions, such as the string type changing. You would be better off finding out if the vendor has updated them.
The biggest change between Delphi 6 and Delphi 2010 is the changing of the default strings to Unicode in Delphi 2009.
I highly recommend against using any pre-Delphi 2009 component with your upgrade. They will not know about Unicode and you will run into problems.
First, you should see if the new version of Delphi already has the functionality you want built in. Many things have been upgraded over the years. You may find you don't need some of your old components at all.
For the ones you still need, try to find an upgrade, or some other similar component that is ready for Delphi 2009. There are many grids around. I am not familiar with Serial or Async programs to recommend one.
This might already help you: Varian Async was acquired by TMS, the same component is now known as TMS Async32
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!