李
李衍智
Unregistered / Unconfirmed
GUEST, unregistred user!
1) CBX is targetting more platforms and more of the overall C++
marketplace
(there is much more out there than just VCL for Windows). Win32/GUI
development is just a piece of the overall market, and with Microsoft
pushing away the native developers in favor of .Net, Borland wants to be
there to pick up the slack for the Win32 users, and then
to branch out in
the other platforms where C++ is in high demand (Unix, mobile, etc) as well.
As such...
2) ... In its first release, CBX was NOT targetting VCL users at all (that
has been officially stated now). That is not to say that VCL users were
ignored, far from it. They just weren't being targetted until later.
3) There is a v2.0 release of CBX in the works, targetted for release within
the next few months.
4) CBX v2.0 will include the full featured compiler, the full featured
Designer and Object Inspector (they did demonstrate the current Designer and
it did work for a couple of different frameworks, namely wxWindows and Java
Beans for demonstration purposes).
5) Many VCL who did attend the CBX sessions did (quite verbally and
articulately) voice their concerns, frustrations, and wishes for VCL's
future with C++. As such, JP LeBlanc has stated that there will *most
likely* be a VCL bridge implemented in CBX v2.0 such that existing BCB
projects *can* be opened, edited, designed, and updated natively under the
new CBX environment using the current VCL (whether that will be BCB's or
Delphi's current VCL, they did not say - hopefully it will be the latter).
6) If/Once implemented, the VCL bridge will allow current projects to be
brought into the CBX IDE and maintained from there instead of needing BCB
anymore. However, the VCL probably *will not* be updated any further after
that point. Win32/VCL development as it currently stands is not being
focused on anymore for long-term plans, expect for in Delphi. In C++, it
would only be a stepping stone to allow existing projects to live on within
the CBX environement using the existing VCL until the programmer sees fit to
eventually migrate their code to one of several new future directions later
on as Longhorn approaches release. Namely, either re-write the code to use
the wxWindows framework for cross-platforms, or else
re-write the code to
Managed C++ for .NET (which CBX will eventually support directly, possibly
with VCL.Net from Delphi v in order to continue with Windows-only
development. Microsoft is really pushing Windows developers to .Net, and
Borland is following along with that strategy. Borlanddo
es recognize that
Win32 is not dead yet, and that Longhorn (the next version of Windows) is
several years away, and that current applications need to be maintained.
Thus the VCL bridge will probably be included in the meantime to keep things
rolling until then
.
7) ActiveX/COM and other existing BCB technologies will probably be
introduced into CBX later on as well (and yes, they will probably get new
updates for fixes to existing problems and such, at least at first).
TELL BORLAND EXACTLY WHAT YOU WANT/NEED IN CBX AND WHY!!!!!! Send an
email to cpp_open_letter@borland.com and make your voices heard!
Exactly. That was exactly the point that JP was trying to make sure
everyone asking for it understood. If/Once introduced, that's it. It will
not progress beyond the point it is already at. It would only be for
maintaining *existing* projects, not really for making *new* projects for
the future.
That is not all Borland's fault, though. Microsoft is changing the C++
market for the Windows platform. That effects a LOT of things. Hell,
Borland even entertained the idea of porting the existing VCL to native C++
at one point. But it did not happen in the end.
You have to understand,
there is a long history leading up to CBX's existence. JP went into some of
it, explaining why certain decisions came about, and why certain decisions
were made (or not made). So there are reasons for everything that happens.
The VCL itself? Probably nothing. The point here, though, is that the VCL
would officially exist in CBX, whereas currently itdo
es not. CBX is
Borland's C++ product from this point on, so they want C++ users to migrate
away from BCB to CBX. Most people aren't going todo
so until the existing
BCB pieces are implemented in CBX. That is where CBX v2.0 will come into
play, since that version will target more of the exiting BCB userbase
whereas v1.0 did not.
> It would seem that if they can transition Delphi users
> to .net it is not a major undertaking to transition BCB users
> to .net.
The thing is, with Delphi v8, the Delphi language has been updated for the
.NET platform. Its incorporated directly. And since the VCL is already
written in Delphi to begin
with, migration is much easier on the Delphi side
than on the C++ side. 90+% of the existing Delphi VCL has already been
ported to the .NET platform with little change to the source code at all,
except at the core levels to use .NET primitives/functionalities now.
On the other hand, where C++ is concerned, the VCL is just an add-on
library, it has nothing todo
with the C++ language itself at all. However,
Borland as always had to go through a whole bunch of issues to make a
Delphi-based library work under a C++ environment (and now, with the release
of CBX, under a Java environment as well). Compiler extensions, IDE
extensions, non-standard behaviors thatdo
n't even follow the rules of C++,
etc. C++ shouldn't need to be used that way.
vcl:
Let me make something clear. It has *not* be stated *which* version of the
VCL will be included into CBX. I never said it would be BCB6's VCL
specifically. I merely stated that it would be the VCL *in general*. If
Borlanddo
es "the right thing", they would include the VCL from Delphi 7,
maybe 8 (if they ignore the .NET extensions), which is an updated version of
the VCL over BCB6. That is the *least* they cando
for us, and it has been
stated as much to them.
> What about the new C++ compiler, and the bugs fixed that
> are part of that.
The new compiler is a complete re-write over the previous compiler. New
front end, new back end.
You can't compare the two.
> Will that make it into CBX for compiling VCL code ?
The new compiler is one of the key features of CBX's design, so yes, CBX
will include the new compiler. Whether that will support compiling VCL
code, Ido
not know, it was not mentioned. However, if theydo
include the
VCL, then
obviously they're going to have to be able to compile it as well,
don't you think?
> What is really hard to understand: for two years Borland
> ignored nearly all bugs and problems with BCB6.
Probably because they were working on CBX instead. CBX is at least 2 years
in the making.
> All are commendable end results. But then
release 1 of CBX is put out, at
> ridiculous prices, and neither the updated compiler nor support for the
VCL
> is part of the release.
Do I really need to get into that again? CBX v1.0 *did not target* VCL
users. Period. It was not meant to be. That has been stated over and
over. They always intended it that way. That was meant for trying to draw
in the larger non-VCL C++ userbase - the other platforms, the dispelled
Microsoft users, etc. VCL users are targatted for CBX v2.0. They have been
that way for awhile now. Wait for CBX v2.0. You will not have to wait
long.
> Didn't Borland realize that their BCB customers would be
> greatly disappointed in this new "version" ?
They were not targetting the BCB users yet.
> What is currently CBX 1.0 can't possibly be the work of
> a programming staff over a period of two years. It is way
> too crude.
You have to understand that there is a lot going on behind the scenes that
youdo
not see up front. So yes, I can image this kind of product taking
that long, there is an entirely new infrastructure that takes time to design
and implement. This is this just the begin
ning.
> 1) Put out the latest VCL for it, along with RAD VCL tools to
>do
RAD programming like we have in BCB.
That has already been stated. RAD programming has always been planned for
CBX, that is what gives Borland the competitive edge in all of its products.
VCL was never planned for v1.0. However, it was not ignored, either.
> 2) Put out the Ansi C++ standard compiler with it with hooks
> to compile VCL extensions.
That depends on EDG and how thei front-end actually works for plugging into
the back-end.
If they put support for parsing extensions into their
front-end (which they would have had to in order to be 100% compliant), then
there is nothing preventing Borland from adding support for the extensions
into their backend.
> If these conditions are met in CBX 2.0, then
BCB customers can
> switch to CBX and plan on going the Managed C++ route for
> Windows and/or the wxWindows route for native cross-platform
> programming, while maintaining their investment in VCL
> components and programming.
Umm, isn't that what I have already been talking about all day today?
> I hope Borlanddo
es the right thing !
Write to them and tell them what you want!
Libraries and correct headers must be generated.
Well, if they use the existing VCL, then
the libraries and headers already
exist, theydo
n't need to be re-created. People have already been able to
use BCB6's VCL in CBX, just not the design-time aspects of it.
> My suggestion was actually to update BCB6 with new VCL,
> compiler, and IDE fixes
That won't happen.
> and not bother with supporting VCL in CBX.
That would dissuade too many users.
> They will give as a reason that the new compiler is Ansi C++
> standard and that adding support for it for VCL-isms will break
> standardization.
Ido
ubt they woulddo
that. Extensions are supported by the standard.
> If it comes to pass, it will be alright, but Borland should really
> keep on supporting VCL until .NET takes hold. I think that is
> still a few yearsdo
wn the line even if I am aware of many
> programmers are using it now. Pulling the plug from C++ VCL
> programming immediately is very unpleasant for developers.
That was specifically stated to JP at the sessions.
> Start the development with the BCB 6.0 form designer and
> then
port it to CBX later. Is it possible to port it without rewriting it?
Probably not. Especially since youdo
want cross-platform, which you can't
use BCB6 for anyway. Well, you could, using CLX, however CLX is now dead as
far as Borland is concerned, so there's no point in using it since you'll
just have to re-write it later anyway.
> Start the development with CBX without form designerdo
ing
> the work manually.
Yes. For what it is worth, you can use the preview designer, it is just
simplistic in functionality, that's all. Also, there are third-party
wxWindows designers available that you can look into in the meantime until
the full features designer is released.
> So big that they have even demonstrated how big it was by dropping it.
They dropped it for a number of technical and logical reasons.
It was actually interesting to discover at one of the BorCon sessions that
this is not the first time wxWindows has crossed Borland's path. Back when
they were first designing CLX, wxWindows was one of the technologies looked
at alongside Qt and a couple of others. Ultimately, Qt was picked, and now
Borland admits to that being the wrong decision, as history has already
shown. They guy who told this story is actually one of the architects of
the new framework, and who brought wxWindows to Borland's attention several
years ago. I guess they decided to try listening to him this time around.
Asside from CLX being a bad implementation when wrapping it? There is also
the fact that Qt actually ran very slowly on Windows, which is the largest
market Borland caters to, so that annoyed a lot of users. There are other
reasons, but Ido
n't recall them right now.
Ok. I didn't catch that. JT said (in public) that CBX 2 was hopefully
going to be available in the first half of 2004 (or did he say first
quarter). I would be impressed if they could get two designers ready in
such a short time. But who knows. Hopefully, the response from users
will impact their priorities.
> You really think wxWindows is viable?
Why not?
> It has been around for many years and hasn't
> attracted hordes of developers.
I would attribute that to lack of publicity. Ido
n't know about you, but I
have been programming in C++ for the better half of a decade now, and I had
never even heard of wxWindows until Borland told me what they were basing
the new framework with. But that's not very surprising given Borland's lack
of experience in cross-platform developments in general. For those who
actually use it, it works quite well for them. There are a lot of markets
wxWindows caters to that Borland previously didn't at all (or barely, such
as Linux). Just because is not well-known to everyonedo
es not necessarily
mean that it is a bad thing to use. How many people still haven't even
heard of (or at least seen) Boost, for example? A lot, actually. And yet,
Boost is becoming part of the next C++ standard. Lack of publicitydo
es not
mean lack of functionality.
> To put it another way: Is anyone here expecting to see hordes
> of developers writing wxWindows third party controls the
> way it has happened for VCL on Windows?
Yes, when the time comes, especialy since (from what I've heard, anyway)
wxWindows has many equivilents to VCL controls. However, in its current
form, wxWindows was not geared towards component development. That is one
of the things that Borland is bringing to it, to help mold it, so to speak,
to better fit into Borland's component model.
> VCL was and still is far more popular than wxWindows.
Well, lets think about it for a minute.
On the one hand, we have VCL, written by one of the biggest software
companies around, one that has world-wide recogniztion, for many programmers
is even a household name. They introduce the same VCL library into two of
the major programming languages they support (and an offshoot of it into the
third). Marketing galoure over the years. Primarily targets only the
largest market around (Windows). Any GUI running under Windows that is not
written in Microsoft tools is probably going to be written in Borland's
tools. So we have wide recognition of the framework across a very large
portion of the marketplace.
Ok, now on the other hand, we have wxWindows, an open-source library written
by something like a thousand unknown developers from around the world
working on it in their spare time. No public marketing. Targets smaller
platforms that many end usersdo
n't see or use (in addition to the large
ones that theydo
). Popularity by word-of-mouth or references from other
projects. However, is used by some major vendors for their in-house
projects, but again is not widely publicized.
So, whichdo
you think is going to be more popular? A world-famous library
that has at least been heard of by everyone, or a library thatdo
es some
great things for what it is but has hardly been heard of by anyone except a
few?
> If Borland supported VCL on more operating system platforms (basically
> make a *nix port with open source for the portable Win emulation layer)
> so that VCL apps can be recompiled on other operating systems that will
> be more popular.
It is not that simple, for a number of technical reasons that have already
been discussed before so I would jump into them again.
marketplace
(there is much more out there than just VCL for Windows). Win32/GUI
development is just a piece of the overall market, and with Microsoft
pushing away the native developers in favor of .Net, Borland wants to be
there to pick up the slack for the Win32 users, and then
to branch out in
the other platforms where C++ is in high demand (Unix, mobile, etc) as well.
As such...
2) ... In its first release, CBX was NOT targetting VCL users at all (that
has been officially stated now). That is not to say that VCL users were
ignored, far from it. They just weren't being targetted until later.
3) There is a v2.0 release of CBX in the works, targetted for release within
the next few months.
4) CBX v2.0 will include the full featured compiler, the full featured
Designer and Object Inspector (they did demonstrate the current Designer and
it did work for a couple of different frameworks, namely wxWindows and Java
Beans for demonstration purposes).
5) Many VCL who did attend the CBX sessions did (quite verbally and
articulately) voice their concerns, frustrations, and wishes for VCL's
future with C++. As such, JP LeBlanc has stated that there will *most
likely* be a VCL bridge implemented in CBX v2.0 such that existing BCB
projects *can* be opened, edited, designed, and updated natively under the
new CBX environment using the current VCL (whether that will be BCB's or
Delphi's current VCL, they did not say - hopefully it will be the latter).
6) If/Once implemented, the VCL bridge will allow current projects to be
brought into the CBX IDE and maintained from there instead of needing BCB
anymore. However, the VCL probably *will not* be updated any further after
that point. Win32/VCL development as it currently stands is not being
focused on anymore for long-term plans, expect for in Delphi. In C++, it
would only be a stepping stone to allow existing projects to live on within
the CBX environement using the existing VCL until the programmer sees fit to
eventually migrate their code to one of several new future directions later
on as Longhorn approaches release. Namely, either re-write the code to use
the wxWindows framework for cross-platforms, or else
re-write the code to
Managed C++ for .NET (which CBX will eventually support directly, possibly
with VCL.Net from Delphi v in order to continue with Windows-only
development. Microsoft is really pushing Windows developers to .Net, and
Borland is following along with that strategy. Borlanddo
es recognize that
Win32 is not dead yet, and that Longhorn (the next version of Windows) is
several years away, and that current applications need to be maintained.
Thus the VCL bridge will probably be included in the meantime to keep things
rolling until then
.
7) ActiveX/COM and other existing BCB technologies will probably be
introduced into CBX later on as well (and yes, they will probably get new
updates for fixes to existing problems and such, at least at first).
TELL BORLAND EXACTLY WHAT YOU WANT/NEED IN CBX AND WHY!!!!!! Send an
email to cpp_open_letter@borland.com and make your voices heard!
Exactly. That was exactly the point that JP was trying to make sure
everyone asking for it understood. If/Once introduced, that's it. It will
not progress beyond the point it is already at. It would only be for
maintaining *existing* projects, not really for making *new* projects for
the future.
That is not all Borland's fault, though. Microsoft is changing the C++
market for the Windows platform. That effects a LOT of things. Hell,
Borland even entertained the idea of porting the existing VCL to native C++
at one point. But it did not happen in the end.
You have to understand,
there is a long history leading up to CBX's existence. JP went into some of
it, explaining why certain decisions came about, and why certain decisions
were made (or not made). So there are reasons for everything that happens.
The VCL itself? Probably nothing. The point here, though, is that the VCL
would officially exist in CBX, whereas currently itdo
es not. CBX is
Borland's C++ product from this point on, so they want C++ users to migrate
away from BCB to CBX. Most people aren't going todo
so until the existing
BCB pieces are implemented in CBX. That is where CBX v2.0 will come into
play, since that version will target more of the exiting BCB userbase
whereas v1.0 did not.
> It would seem that if they can transition Delphi users
> to .net it is not a major undertaking to transition BCB users
> to .net.
The thing is, with Delphi v8, the Delphi language has been updated for the
.NET platform. Its incorporated directly. And since the VCL is already
written in Delphi to begin
with, migration is much easier on the Delphi side
than on the C++ side. 90+% of the existing Delphi VCL has already been
ported to the .NET platform with little change to the source code at all,
except at the core levels to use .NET primitives/functionalities now.
On the other hand, where C++ is concerned, the VCL is just an add-on
library, it has nothing todo
with the C++ language itself at all. However,
Borland as always had to go through a whole bunch of issues to make a
Delphi-based library work under a C++ environment (and now, with the release
of CBX, under a Java environment as well). Compiler extensions, IDE
extensions, non-standard behaviors thatdo
n't even follow the rules of C++,
etc. C++ shouldn't need to be used that way.
vcl:
Let me make something clear. It has *not* be stated *which* version of the
VCL will be included into CBX. I never said it would be BCB6's VCL
specifically. I merely stated that it would be the VCL *in general*. If
Borlanddo
es "the right thing", they would include the VCL from Delphi 7,
maybe 8 (if they ignore the .NET extensions), which is an updated version of
the VCL over BCB6. That is the *least* they cando
for us, and it has been
stated as much to them.
> What about the new C++ compiler, and the bugs fixed that
> are part of that.
The new compiler is a complete re-write over the previous compiler. New
front end, new back end.
You can't compare the two.
> Will that make it into CBX for compiling VCL code ?
The new compiler is one of the key features of CBX's design, so yes, CBX
will include the new compiler. Whether that will support compiling VCL
code, Ido
not know, it was not mentioned. However, if theydo
include the
VCL, then
obviously they're going to have to be able to compile it as well,
don't you think?
> What is really hard to understand: for two years Borland
> ignored nearly all bugs and problems with BCB6.
Probably because they were working on CBX instead. CBX is at least 2 years
in the making.
> All are commendable end results. But then
release 1 of CBX is put out, at
> ridiculous prices, and neither the updated compiler nor support for the
VCL
> is part of the release.
Do I really need to get into that again? CBX v1.0 *did not target* VCL
users. Period. It was not meant to be. That has been stated over and
over. They always intended it that way. That was meant for trying to draw
in the larger non-VCL C++ userbase - the other platforms, the dispelled
Microsoft users, etc. VCL users are targatted for CBX v2.0. They have been
that way for awhile now. Wait for CBX v2.0. You will not have to wait
long.
> Didn't Borland realize that their BCB customers would be
> greatly disappointed in this new "version" ?
They were not targetting the BCB users yet.
> What is currently CBX 1.0 can't possibly be the work of
> a programming staff over a period of two years. It is way
> too crude.
You have to understand that there is a lot going on behind the scenes that
youdo
not see up front. So yes, I can image this kind of product taking
that long, there is an entirely new infrastructure that takes time to design
and implement. This is this just the begin
ning.
> 1) Put out the latest VCL for it, along with RAD VCL tools to
>do
RAD programming like we have in BCB.
That has already been stated. RAD programming has always been planned for
CBX, that is what gives Borland the competitive edge in all of its products.
VCL was never planned for v1.0. However, it was not ignored, either.
> 2) Put out the Ansi C++ standard compiler with it with hooks
> to compile VCL extensions.
That depends on EDG and how thei front-end actually works for plugging into
the back-end.
If they put support for parsing extensions into their
front-end (which they would have had to in order to be 100% compliant), then
there is nothing preventing Borland from adding support for the extensions
into their backend.
> If these conditions are met in CBX 2.0, then
BCB customers can
> switch to CBX and plan on going the Managed C++ route for
> Windows and/or the wxWindows route for native cross-platform
> programming, while maintaining their investment in VCL
> components and programming.
Umm, isn't that what I have already been talking about all day today?
> I hope Borlanddo
es the right thing !
Write to them and tell them what you want!
Libraries and correct headers must be generated.
Well, if they use the existing VCL, then
the libraries and headers already
exist, theydo
n't need to be re-created. People have already been able to
use BCB6's VCL in CBX, just not the design-time aspects of it.
> My suggestion was actually to update BCB6 with new VCL,
> compiler, and IDE fixes
That won't happen.
> and not bother with supporting VCL in CBX.
That would dissuade too many users.
> They will give as a reason that the new compiler is Ansi C++
> standard and that adding support for it for VCL-isms will break
> standardization.
Ido
ubt they woulddo
that. Extensions are supported by the standard.
> If it comes to pass, it will be alright, but Borland should really
> keep on supporting VCL until .NET takes hold. I think that is
> still a few yearsdo
wn the line even if I am aware of many
> programmers are using it now. Pulling the plug from C++ VCL
> programming immediately is very unpleasant for developers.
That was specifically stated to JP at the sessions.
> Start the development with the BCB 6.0 form designer and
> then
port it to CBX later. Is it possible to port it without rewriting it?
Probably not. Especially since youdo
want cross-platform, which you can't
use BCB6 for anyway. Well, you could, using CLX, however CLX is now dead as
far as Borland is concerned, so there's no point in using it since you'll
just have to re-write it later anyway.
> Start the development with CBX without form designerdo
ing
> the work manually.
Yes. For what it is worth, you can use the preview designer, it is just
simplistic in functionality, that's all. Also, there are third-party
wxWindows designers available that you can look into in the meantime until
the full features designer is released.
> So big that they have even demonstrated how big it was by dropping it.
They dropped it for a number of technical and logical reasons.
It was actually interesting to discover at one of the BorCon sessions that
this is not the first time wxWindows has crossed Borland's path. Back when
they were first designing CLX, wxWindows was one of the technologies looked
at alongside Qt and a couple of others. Ultimately, Qt was picked, and now
Borland admits to that being the wrong decision, as history has already
shown. They guy who told this story is actually one of the architects of
the new framework, and who brought wxWindows to Borland's attention several
years ago. I guess they decided to try listening to him this time around.
Asside from CLX being a bad implementation when wrapping it? There is also
the fact that Qt actually ran very slowly on Windows, which is the largest
market Borland caters to, so that annoyed a lot of users. There are other
reasons, but Ido
n't recall them right now.
Ok. I didn't catch that. JT said (in public) that CBX 2 was hopefully
going to be available in the first half of 2004 (or did he say first
quarter). I would be impressed if they could get two designers ready in
such a short time. But who knows. Hopefully, the response from users
will impact their priorities.
> You really think wxWindows is viable?
Why not?
> It has been around for many years and hasn't
> attracted hordes of developers.
I would attribute that to lack of publicity. Ido
n't know about you, but I
have been programming in C++ for the better half of a decade now, and I had
never even heard of wxWindows until Borland told me what they were basing
the new framework with. But that's not very surprising given Borland's lack
of experience in cross-platform developments in general. For those who
actually use it, it works quite well for them. There are a lot of markets
wxWindows caters to that Borland previously didn't at all (or barely, such
as Linux). Just because is not well-known to everyonedo
es not necessarily
mean that it is a bad thing to use. How many people still haven't even
heard of (or at least seen) Boost, for example? A lot, actually. And yet,
Boost is becoming part of the next C++ standard. Lack of publicitydo
es not
mean lack of functionality.
> To put it another way: Is anyone here expecting to see hordes
> of developers writing wxWindows third party controls the
> way it has happened for VCL on Windows?
Yes, when the time comes, especialy since (from what I've heard, anyway)
wxWindows has many equivilents to VCL controls. However, in its current
form, wxWindows was not geared towards component development. That is one
of the things that Borland is bringing to it, to help mold it, so to speak,
to better fit into Borland's component model.
> VCL was and still is far more popular than wxWindows.
Well, lets think about it for a minute.
On the one hand, we have VCL, written by one of the biggest software
companies around, one that has world-wide recogniztion, for many programmers
is even a household name. They introduce the same VCL library into two of
the major programming languages they support (and an offshoot of it into the
third). Marketing galoure over the years. Primarily targets only the
largest market around (Windows). Any GUI running under Windows that is not
written in Microsoft tools is probably going to be written in Borland's
tools. So we have wide recognition of the framework across a very large
portion of the marketplace.
Ok, now on the other hand, we have wxWindows, an open-source library written
by something like a thousand unknown developers from around the world
working on it in their spare time. No public marketing. Targets smaller
platforms that many end usersdo
n't see or use (in addition to the large
ones that theydo
). Popularity by word-of-mouth or references from other
projects. However, is used by some major vendors for their in-house
projects, but again is not widely publicized.
So, whichdo
you think is going to be more popular? A world-famous library
that has at least been heard of by everyone, or a library thatdo
es some
great things for what it is but has hardly been heard of by anyone except a
few?
> If Borland supported VCL on more operating system platforms (basically
> make a *nix port with open source for the portable Win emulation layer)
> so that VCL apps can be recompiled on other operating systems that will
> be more popular.
It is not that simple, for a number of technical reasons that have already
been discussed before so I would jump into them again.
。Borland的 .NET战略构筑在对Microsoft .NET框架的完全支持上面，包括ADO.NET，ASP.NET， Windows®