I have a serious problem right now.
As a freelance developer I am maintaining a very large project (500.000+ lines of code) of my customer which was written in an old version of C++ Builder.
Years ago I purchased an Enterprise License of Borland C++ Builder 6 and that was the IDE I used to manage this project.
Every time when Windows is updated, C++ Builder required to be re-registered. The last couple of times this meant: Write an E-Mail to Embarcadero, beg for pardon, be nice, wait a couple of days until they increased the Registration maximum.
This time they refused this... WHAT.THE.HELL?
Embarcadero is literally killing their own customers, for absolutly no reason!
What can I do in such a situation?
Upgrade is not an option, the project is far too large (I have several newer licenses of Borland/CodeGear/Embarcadero C++ Builder and have already tried a migration).
Is there a way to purchase a version of Builder6 that does not require this online registration? Or are there any other work arounds?
regards, Herwig
Related
I have installed the Zeos 7 Beta on my own machine but it fails on my client's laptop. We're both running Delphi xe2, his is Entreprise, mine is Pro. His machine is running 64-bit windows 7, mine is running Window 7 32-bit.
When I do Compile all on ZeosDbo or ProjectGoup16 it seems to get through ZCore.dpk but then shows 2 fatal errors:
ZCore.dpk(1) E2225 Never-build package 'ZCore' must be recompiled
ZParseSQL.dpk(33) E2202 Required package 'ZCore' not found
This is production code we are working on, so I hope we can find a solution and get back to working on this
Zeos forum thread: http://zeos.firmos.at/viewtopic.php?t=3633
That is one error, the 1st one. The second is merely post-effect.
Perhaps you can do better than downloading beta ZIPs: until they have mature release you just can download each day "nightly" changes by version-control tools, like Git or SVN or whatever Zeos team is using.
Such errors are usually quickly fixed (they are simple) but long released(they are so moot that no one would bother making release for them).
Just open http://zeos.firmos.at/portal.php and read where to get most instant updates and how to report problems.
Actually - there it is, http://svn.code.sf.net/p/zeoslib/code-0/trunk/
Install TortoiseSVN and be on the edge until 7.0.1 or 7.0.2 final release
The page also says: Please report bugs for this version to our brand new bugtracker on sourceforge https://sourceforge.net/p/zeoslib/tickets/
Please do. Open Source is about participating. At least participate by registering bugs.
About the essence of problem read official documentation and "See Also" section.
Someone should decide about package binary update strategy. And the decision should be kept for all packages (okay, you can mix it in some conditions, but that is not to be suggested). So basically you have three choices:
Make your own decision and put all Zeos packages into the strategy of your choice. That puts the responsibility upon yourself to maintain this fork for a while until you come back to vanilla ZeosDB.
Report the bug to ZeosDB team and ask their suggestion, then change those settings for all the packages as suggested by them.
Report the bug to ZeosDB team and wait until they'd fix it in their SVN and then do SVN Update.
Personally i'd go with 1 option, but i am ready to be FLOSS libraries co-developer.
Option 3 would be the most slow yet the most easy for you.
Option 2... well... i can not see why you should choose that, except for trying to avoid version controls at any cost, which is bad idea per se.
I also suggest you to read http://www.catb.org/esr/faqs/smart-questions.html
That would help you effectively communicate at ZeosDB forums - and you'd have to if you want to be "on the edge" (and if you do not - then wait for public release like 7.0.2).
Does the old Toolbar 2000 package (preferably with the TBX extension) compile and work under Delphi XE?
Are anyone using "Tb2k" and TBX these days?
Do TB2K and TBX compile?
Toolbar2000 does. It is used as part of SpTBX (see below.) TBX I'm afraid I don't know - development ceased a few years ago and I upgraded to SpTBX. I would recommend you do the same - it's actively developed / maintained and you probably won't end up asking questions like this about it in a couple of years (hopefully!)
(I know 'upgrade' wasn't what you asked, sorry. It's what I would recommend. I don't like the situation where I'm using third-party code which is no longer maintained, and I have to take that task upon myself and upgrade it each version.)
Is anyone using TBX?
Most people these days do not use TBX - development on it has ceased. Instead, they use SpTBX, developed by Silverpoint Development. It used to be a patch to TBX (so you'd have three layers: TB2K followed by TBX followed by SpTBX) but these days is directly based on TB2K, so it's only two layers.
The installation instructions are easy to follow, and its installer installs TB2K as well.
SpTBX provides extra controls on top of those provided by TB2K, and also provides skin support. It comes with a skin editor if you want to create your own skins. Many of the ones its shipped with I would never use in commercial software, but the Office 2003- and Office 2007-style skins are excellent.
One of the demo SpTBX applications with the Office 2007 Blue skin
Upgrading from TBX: Most TBX components have direct analogues in the SpTBX library, and renaming them in the DFM and form file and opening the form will be a good start. (Or use GExperts.) Some properties and events have changed or gone, which is annoying. I found I could generally figure out how to achieve the same thing pretty easily - it took a day or so to upgrade a large application for me - but you will find it's not a direct smooth transition.
You can download the 2.2.2 sources and modify them by opening the Delphi 2009 package (tb2k_d11.dpk and tb2kdsgn_d11.dpk) files and saving them as a new name, which creates a new copy. Change the NAME SUFFIX from _d11 to _d15, to follow the existing convention, which is useful although a dated technique. For our purposes d15 in this case means a delphi XE package (delphi version 15.0).
Or you can download my copy, which I did this to already (tb2k22_xe.zip). Just open up the project groups, and install the packages. Note that it seems this code is dual licensed, and to "redistribute" such a trivially modified copy of this code, my changes must be licensed under the GPL, and so, to avoid GPL contamination you should email Jordan Russell and ask for permission to relicense these changes/updates under his Toolbar2000 commercial license, if you wish to use them in a closed source commercial license. Or you can repeat the steps I followed, and avoid GPL contamination. Better still, give Jordan Russell $30 and become a paying customer, and prove that the good-old days are not completely gone, when a guy who wrote a nice component for delphi, got people handing him money, left right and center.
I realize this is an old question.
I am still using TB2K in delphi 5 apps. I've also used TBX in combination.
Some people refuse to use newer delphi versions simply because the old delphi products were almost just as good (not quite but still) since they have an infinitely expandable component system.
Doesn't SpTBXLib and TBX violate the Toolbar 2000 licenses considering that it modifies the TB2K without the permission of Jordan Russell? Or did these products get permision from Jordan Russell to release modifications and patches? This all seems to be jumping through a bunch of annoying hoops that a BSD/MIT style license would solve. Even if SpTBXLib and TBX are violating Russell's terms, he's probably okay with it if someone emails him, but I'm not 100 percent certain - it's a bad assumption to make. These projects should clearly say in their README or on their Github site that they have gotten the permission.
Also, I was one of those people who paid Jordan Russell ... to bring back the good old days of delphi developers paying other developers for their work (instead of GPL cult nonsense where programmers go home starving). The trick would be somehow for Russell to offer it BSD while getting paid still, which might prove difficult. It seems the GPL is actually a way for developers to restrict their software, not to free it up.. what a joke.
Free software foundation = Restrictive Software Foundation
One option would be to make it BSD/MIT and ask for donations, but I doubt Jordan Russell would go for it. Might be worth a try. Or if he is only making a few bucks from this every year, then it would be no big deal to just release it BSD. I'm not sure how many copies he sells per year. It's none of our business - but it sort of is in the sense that we are willing to make improvements to his code and not charge money, so we are part of the source too! May the source be with you.
You can check this
I think XE is very similar to D2010
You should check spTBX at http://www.silverpointdevelopment.com
It builds on tb2k without dependancies, installer is there and it works on unicode delphi.
I've used a component called dcmemo which is part of a component pack from Dream Company which went out of business a few years ago. Now that I'm upgrading to the latest Delphi I can't install this component dispite having the source and making tons of fixes to it.
After looking around on the web everyone pretty much says it's extremely difficult to upgrade the dream company components to work with the latest delphi which leaves me looking for a replacement which can do almost the same stuff.
I'm sure someone has had this exact same problem before. What can I replace dcmemo with?
Try SynEdit. It's free and has been under development for a long time. I'd advise you use the latest sources which includes a code folding and tested and working code/dpks for most every version of delphi.
If you have svn installed, use the command below to get all the files.
svn co https://synedit.svn.sourceforge.net/svnroot/synedit synedit
I've used TPlusMemo for many years and have found it well worth the price. It has been recently upgraded for XE. http://www.ecmqc.com/plusmemo/pmHome.htm
Good luck!
According to a recent blog post by Allen Bauer:
As we’re working on Fulcrum, the next
RAD Studio release with a focus on
cross-compilation for Mac and Linux,
[..]
I figured someone would mention it in the comments, but I thought Mac/Linux support was a few releases further off. Maybe it's just me, but this is huge news.
Does this mean we will see Mac/Linux binaries created with a Delphi release this year?
While I cannot commit to any kind of time frame or release dates, we are working on Mac and Linux targeting. There is also some work going on for 64bit targeting as well, however that will most likely not be in the same time frame as the Mac/Linux targeted releases.
Fulcrum is the code name for the next release, so yes, the next release will include Mac and Linux support. I don't know about the time frame, but "this year" seems reasonable.
Native 64 bit support will be in a future release.
Personally, I prefer this order.
Embarcadero once said that "the release after the next one will support 64-bit". That was supposed to be Delphi 2010. That didn't happen of course - far from it. Not only did it not appear in the release that was indicated, but it now appears it won't be appearing for at least 2 further releases, and in the meantime, things that were NEVER even mentioned have suddenly appeared and been given priority.
So there really is no reason to believe that Fulcrum will happen either, until it has actually been delivered, no matter who talks about it, at least not in the time frame that is being indicated.
Embarcadero have proven less than reliable when it comes to their "roadmap" which is frankly something of a joke - the "current" one still talks about things that have already been delivered as if they have yet to happen, for instance.
FreePascal
I suppose it's not awful news...
If you look at the last road map, you will see Embarcadero is working on Project called "Delphi X"
(source: embarcadero.com)
and according to what Allen said, it seems it's will be compile to Mac OS & Linux at same time, which is great thing.
If Allen said so, it's pretty safe to assume it's true.
The best answer so far is by Michael Rozlog. It is an over hour interview with the Product Manager of RAD Studio and is worth hearing. It covers:
The Delphi Survey
Delphi application showcase
Updates to the Delphi Roadmap
12 Videos of Christmas (later renamed the 12 Holiday videos)
Compiler rewrite
Project Fulcrum: Delphi on Linux and Mac in Beta
Coming soon to more public beta (hopefully)
Delphi Backwards Compatibility
The upgrade cut off policy
Free or low cost versions of Delphi
And a whole lot more.
http://www.delphifeeds.com/go/f/65775?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+delphifeeds+(DelphiFeeds.com)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 1 year ago.
Improve this question
I am responsible for a Delphi/Win32 project management application. I have just completed a move to Delphi 2009.
More and more US based users want to use the application on their Mac computers, while the majority are Windows users.
Are there solutions out there to easily build a Delphi app that will natively run on MacOS?
With the release of RAD Studio XE2 in late 2011, Delphi developers should be able to build once and distribute on Win 32/64 and MacOS 32, with iOS support promised.
You might want to try Lazarus:
http://www.lazarus.freepascal.org/
http://wiki.lazarus.freepascal.org/index.php/OS_X_Programming_Tips
Mac OS X doesn't run Windows programs. It doesn't provide any of the API you'd need, such as the functions in kernel32, user32, etc.
You could try running your program via Crossover. Other options include virtual machines, such as VMware Fusion and Parallels.
Another thing you might try is to use .Net. Convert your program to use the .Net version of Delphi and then run it on Mono on the Mac. I wouldn't put a lot of confidence in this method, though.
Your options to run native Delphi code on OSX are pretty limited. You can use Lazarus/Freepascal but that is a long way behind Delphi. It will produce native code.
Alternately you can use Prism and Mono. That apparently works well. Have a look at http://devcenter.remobjects.com/osx or http://wiki.remobjects.com/. Also, check out the remobjects blogs, and the embarcadero.public.delphiprism.mono.osx newsgroup.
That needs the mono redistributable. However mono also supports linking and ahead of time compilation so you might be able to get something close to native code on it.
In either case, you will need to rewrite your ui as the osx look and feel and conventions are different.
This is a very old thread but for people browsing here and looking for an answer in Q3 of 2011 or later the answer is yes.
With the release of Rad Studio XE2 this year, Delphi Developers will be able to create native applications for Mac OS as well as Win32, Win64 and iOS more platforms coming soon.
There may be some hope for the future for Delphi and the Mac.
The Podcast at Delphi.Org reviewed the closing keynote at CodeRage III (Dec 2008) when Embarcadero’s Wayne Williams talked about the Future. It said this:
I think the most exciting part of Wayne’s talk was the slide marked “The Future” which listed some of the company wide research initiatives underway. It specifically listed Mac, Linux, Cloud, Application Virtualization, FireBird, Touch, 64bit, SMP and Multi-core. When I asked about a Delphi for Mac and Linux they said that today, with Delphi Prism and Mono you could reach Mac and Linux, but in their labs they were working on native support, and that they had a significant head start.
While the Lazarus route is not a no brainer recompile, I've good experiences with it. I tried the (Delphi).NET+mono way before (to WinCE, Linux and OS X), and failed miserably.
Codegear talks a lot, but the next Delphi version will only have a PREVIEW of 64-bit (cmdline compiler). If you assume the version after that is the full 64-bit product, you can be sure that OS X is at the earliest 2 years away.
Lazarus or recoding.
I listened in on one of the recent Delphi 2009 show-off conference calls and they said that it was possible to run on a Mac using Delphi Prism and there is an automatic conversion utility called Oxidizer. I'm not sure if you'd call that native since you'd need Mono, but I think it's better than Wine.
Another alternative would be to develop a web based application. This avoids the "gui is different" problem and allows you to focus on your product. If you look at some of the latest AJAX controls, you can get pretty close to a full desktop application experience without having to sacrifice much. If your application needs to run locally, then developing a local web service in Delphi and translating it to Lazarus specifically targeting OSX seems to me to be a much easier and manageable task.
There's not really a good solution for this. Someone mentioned Lazurus, but it's not "there" yet. Delphi is just not a cross-platform tool. If you really want a Mac version then you probably ought to look at alternatives.
If your app is consumer-based, your users will expect lots of Cocoa goodness. Using anything else to make a Mac app will make them cranky.
However if it's more of a business app, then that's usually less important. I use REALbasic to build lots of Mac/Windows business applications. It's very similar to Delphi so it should be easy to pick up.
We have released a new product for creating cross platform apps (Mac OSX) using Delphi/Free Pascal. have a look at http://twinforms.com/
Welcome to the future/relive the past!
MacOS: https://www.embarcadero.com/products/rad-studio/mac-osx-development
iOS: https://www.embarcadero.com/products/rad-studio/ios-development