ive a news server Built on Delphi7, using Indy9 TIdTCPServer, and the clients are using TClientSocket from ScktComp for size, and the traffic is encrypted in RC4 (string)
what exactly do i need to make my app work on XE or 2010 with Unicode support? what of these things will i have to change?
Unicode has introduced in Delphi 2009, so if you want the unicode support you can do it with Delphi 2009.
But if you are going to upgrade, get the latest one, you can get all the benefits of Delphi 2010 with less bugs and more Third party tools bundled with Delphi XE.
the other problem may you face is the translation between Indy 9 to Indy 10, because unicode support added to Indy 10, but also it's not 100% compatible with Indy 9.
I suggest you to try to compile your application with Delphi 7 and Indy 10, then move later to Delphi XE with Indy 10.
Don't know if Indy 9 is still supported on XE and 2010. Indy 10 has improvements but also some breaking changes. Moving binary data into strings is IMHO never a good choice, but depending the situation it could just need some minor changes. What you exactly need depends on your application code - without actually looking at it is difficult to say. All string manipulation routine should be checked, especially if you use them as low-level binary buffers, and the select which path is best to port them to the Unicode world.
Related
Delphi 7 and ShellListView it is possible with unicode?
I tried ShellListView, LMD, bsSkinFileListView and TMS Unicode Component. In list i see unicode filenames as i.e.: "????????.txt". Noting works.
Anyone have some idea how to list files/dirs as Windows Explorer with normal visible filenames?
Thanks
Delphi 7 doesn't support Unicode VCL components. You need to upgrade to the latest version of Delphi where all the available shell components have good support for Unicode. Trying to do this in Delphi 7 is simply impractical and nobody is going to invest time doing that nowadays.
Okay -- we have an interesting problem.
Some background:
Our main application uses Indy 10. However, we take the Indy 10
source and fix bugs in it, recompile, and install our own set of Indy
components.
We are migrating to Delphi XE and want to start using DataSnap.
DataSnap requires the "official, shipping" version of Indy which is
incompatible with our customized version of Indy.
Our DataSnap servers will be separate applications, but since we
have our own Indy installed in the IDE, we can't "cross the streams".
Okay, therefore, we are unable to use Delphi XE's DataSnap out of the
box because of this compatibility issue.
So my questions is this:
Is it possible to recompile the DataSnap packages in Delphi XE with a new/different version of Indy?
Your thoughts gratefully accepted.
The common belief is No, that's not possible due to not all sources being provided by Embarcadero and some of these sources are reliant on the build of Indy as shipped. (Which is extremely frustrating to end users as the version of Indy that ships with Delphi is out of date relatively quickly and sometimes the version selected at the time is not necessarily a very good one.)
See related SO question:
Is it possible to use Indy 10.5.8.0 in Delphi XE and DataSnap?
Also see the Indy project page:
http://www.indyproject.org/Sockets/Docs/indy10Installation.de.aspx
which states:
Note: In D/CB/RAD 2009+, DataSnap uses
Indy 10 internally. Installing a new
version of Indy will render DataSnap
unusable, as it will not be able to
load the Indy packages anymore.
DataSnap is compiled against the Indy
packages that ship with the IDE, and
DataSnap cannot be recompiled by end
users. If you need to use DataSnap,
then you will need to maintain the
original Indy 10 packages for use in
DataSnap projects.
It's been said that the next version should hopefully allow for easier updates of Indy.
If all DataSnap source is included, is of course possible using some kind of PE executable analisys program to detect which classes and units are used in BPL (as BPLs are just customized DLLs). An very easy one to use is provided with GExperts.
In BPLs, the exports list lines from GExperts\PE Information have an format like #xp$#[nn][UnitName]#[TypeName] (for types) and #[UnitName]{#[Type>]}#[Unit global element like procedures or variables] (for the rest).
You can save that list to a file and GREP to get an list of Units used on a BPL.
Real Examples (vcl140.bpl):
#$xp$11Forms#TForm
#Appevnts#TCustomApplicationEvents#Activate
#Clipbrd#Clipboard
From what I've read from the previous posts, Delphi 7 is stable and has the best help system but is slow, Delphi 2007 is fast but the help system is bad and the IDE is buggy. Delphi 2009 is stable and fast but the help system is bad too. The posts were made when 2010 isn't available yet. I am planning to upgrade from Delphi 7 to 2010. Is Delphi 2010 stable, fast and has a good help system?
Delphi 2010 is one of the best Delphi releases ever. It stabilizes some of the new features introduced in Delphi 2009. The IDE is fast, and in the project I used it was very stable.
The thing there is that the IDE and the help system are build as a RAD Studio for different languages. Especially the help system tries to be everything for everybody. Even having only one personality installed, it has many entires about other languages I do not care about (but I can filter them). Yet there are many entires missing depth that never made it into the new help format.
The help system starts painstakingly slow (especially at first startup). But, to be fair, this is partially do to the MS Help System being a pain in the neck (this, in my opinion, just was the wrong path to chose).
Embarcadero invests quite some effort into the help system, and it had several updates during the 2010 release.
You do know about the varying expense of conversion to Unicode as 2010 is fully Unicode based?
Here are some reasons why I stick to Delphi 7, having Delphi 2010 at hand to recompile and test what I wrote in Delphi 7, in a cross-version manner:
if your source code compiles on Delphi 7, and you make careful usage of Unicode/AnsiString, it will work as well with Delphi 2010;
if your source code compiles on Delphi 7, it will work as well with Free Pascal, so
cross-platform and 64 bits are open to you;
if your source code compiles on Delphi 7, it can be cross-compiled with CrossKylix directly from the Delphi 7 IDE - see Has any one used CrossKylix for real Cross-platform development?
Delphi 7 runs well on my Windows Seven 64 bits system, if you install it not in "C:\Program Files" but in "C:\Progs" for example;
Delphi 7 starts faster than Delphi 2007, and MUCH faster than Delphi 2009/2010 - see http://andy.jgknet.de/dspeedup
generated code is almost the same since Delphi 7 - when I need speed, I use better algorithms, and assembler if it's worth it;
Delphi 7 IDE is as powerful as Delphi 2010 IDE, if you use some IDE enhancements like http://www.cnpack.org;
Delphi 7 help is still the reference - why waiting for 20 seconds on my Core i7 processor waiting for the awful MS help system to launch? and if you want to create an application able to run under XP, its content will be enough for you; if you want to know about newer OS, just use msdn web site directly, or via google: it sounded to me easier than the help integrated with Delphi 2005/2010;
I use the assembler/CPU view a lot: all Delphi IDE have the Alt-F2, but you can close this window by the escape key on Delphi 7 - I was not able to find such a keyboard shortcut under Delphi 2007/2010, and it's very annoying;
Delphi 7 executable size are small, and even smaller with our LVCL libraries (30 KB for a form with buttons);
I didn't have the need for generics and such up to now - I like knowing which code is generated;
Delphi 7 is Unicode ready, whatever you say - its associated VCL was not, but CharSets are not evil, and work well - what I do is develop under Delphi 7, then compile with Delphi 2010 and get all the Unicode benefits if needed;
I use a large screen (at 1920x1280 resolution), and Delphi 7 makes it easy to have multiple edit windows at once - newer IDE locked layout was not a good idea... at such that EMB officially added the "Delphi 7 way undocked IDE" feature to Delphi 2010: and marketing sell it as a new feature;
and so on, and so on...
You can use Delphi 7 help in Delphi 2010, if you want to.
Use this or this addon. See item 5 here for instructions (sorry, it's machine auto-tranlation).
P.S. You can have more than one help installed. Say, a F1 for Delphi 7 help and Ctrl+F1 for Delphi 2010 help.
delphi 2010 is stable and fast and is actually a good delphi compiler after years of half-baked releases, they have improved help system in delphi 2010 but i still think delphi 7 help system is superior(but thats just my opinion).you do know delphi 2010 has a 1 month trial do you? download it and play around and see if you like it
EDIT: forgot to mention if you buy delphi 2010 you'll get marco cantu's Delphi 2010 Handbook for free ,the book covers whats new in D2010 so if you consider book as part of help system than help system is OK :)
Delphi7 was faster, but it was a lot simpler. I wouldn't worry too much about performance of the IDE, especially if you're working on a modern PC. At work I've got an old P4 machine, and it runs just fine.
New language features like methods on records and generics make it well worth it to switch.
For me it's hard to live without TList<T> nowadays.
For a while I've desperately tried to keep code Delphi7-compatible, but I've ported most of the important applications to D2010 already, and whenever I need to start D7, it all feels so low-tech and simple.
I've always hated the crappy component palette in the older Delphi's. Delphi 2010 has a much better interface, and the filter function is a real time-saver.
I've decided to give up on Delphi7 and just make full use of D2010's capabilities. That makes life a lot easier.
I've just received an assignment to upgrade an old Delphi 3 project that I wrote in 1999 to a newer version and add features (I previously discussed this in related questions here and here). I was assuming that the appropriate route would be to first upgrade my development environment to Delphi 2010 and then port the application.
I'm now considering whether to upgrade the application to my existing copy of Delphi 2007 instead in order to avoid the Unicode complications. The application runs at a single company in the United States and is tightly bound to requirements of a single state, so it would not benefit from Unicode support.
My question is: would the additional hassle of dealing with Unicode issues outweigh the benefit of using the most recent version of Delphi? You may assume that I have no experience with Unicode.
why "upgrade" to a version that is not the latest, it just guarantees an earlier "next upgrade".
I'm very very happy with Delphi 2010, I recommend porting to that version unless you use a 3rd party lib that is not available for D2010
You should try it (the upgrade) on a D2010 trial, and give yourself a day or so to get a feel for the type of complications that result. Generally, if you didn't use a lot of PChar for pointer arithmetic, and you didn't use sub-ranges of strings, e.g. Code[1] := 'A', and so on, there should be few or no upgrade issues. Aside from the unicode upgrade, the D2010 IDE is much nicer to use, and seems faster than D2007.
D2007 may be easier to upgrade, because you it will not require changes of your code to work probably with Unicode, and if your code doesn't require a lot of PChar and others ANSI dedicated functions, it may work in Delphi2010 without a lot of work.
But if you have time and resources to upgrade to Delphi 2010, it will be better options, because sooner or later version from Delphi 2009 and later will be the standard versions.
Also the IDE productivity is higher in D2010, beside new language additions like generics, anonymous methods and others which make your code better, if you going to rewrite some sections of it.
They have done such a good job implementing Unicode in Delphi 2009 that most programs that do not do tricks with characters and bytes convert over with no problem.
The caveat is as long as you are not using any 3rd party packages. If you are, you should upgrade those. If they don't have upgrades and you don't have their source code, then you might be better off not going to Delphi 2010.
But I would make the jump if at all possible. I did and I'm glad I did.
"That depends"
It depends on the number of 3rd party controls and the current state of those controls. (Are they still on the market with updates for 2007 and 2010?)
It depends on code size and code quality. If you have a large, loosely managed code base it will be a harder path to 2010.
It also depends (largely) on project input/outputs... are you reading from files/databases/communications? How will they react to Unicode, or can you easily narrow down all of those touch points to ensure proper handling?
One other major dependancy is the life of the application... "Going Unicode" now might serve you better if you are going to support this application over the long term as eventually they'll stop selling 2007 and you'll be forced into it.
I own 2009 and have built minor applications/utilities with it, but the main work is still in 2007, 2006, D7, and D5 depending on project.
See here. It can confuse the things when coming to D2010.
Currently we use Delphi 2007 because our application and some of our components are not compatible with Unicode. If and when we upgrade is it better to jump directly to Delphi 2010?
Propably, but I wonder if there is other compability issues except unicode?
How is performance, memory requirements and stability of those versions?
If you decide to upgrade, then yes, go with the latest version.
Delphi 2010 is definitely better than 2009, by not much though.
Don't expect your upgrade to be smooth.
For example: Delphi has a new version almost every year.
Then why it never helps you with the transfer of the settings between the versions?
Why all components are written in a way to lock you to the latest known version to the component? (this is not necessarily problem with Emabracadero, but they could provide guidelines)
Check if your components have '2010 version or you might need to fix hundreds of small but problematic lines of code.
No doubts, you should go directly to D2010, not to D2009 - in this aspect D2010 is actually more like D2009 SP1 than a fully new version, just with some nice additions like an updated RTTI. D2010 has no new known compatibility issues, has better stability, etc.