It seems that Microsoft not only does not need the classic Visual Basic
developer army (the largest army of developers the world has ever seen), but
now they don't need ANY Windows developer at a small or mid-sized business.

http://groups-beta.google.com/group/microsoft.public.msdn.general/browse_thread/thread/9d7e8f9a00c1c7da/459ca99eb0e7c328?q=%22Proposed+MSDN+subscription+changes%22&rnum=1#459ca99eb0e7c328

Damn!  To be that powerful....to be so rich and smug.......  It must be
nice.

Jim Hubbard

I have made no attempts to hide my displeasure at the way Microsoft has
treated the VB6 developers - as you will notice in the Microsoft.public.vb
newsgroup postings.

And, with the current pricing structure of MSDN and rising costs of
Microsoft's desktop software, I truly believe we need a valid alternative to
Microsoft developer tools.  Currently, I am looking into REALbasic
(www.REALbasic.com) as just such an alternative.

Now, REALbasic still has some growing to do.  Don't expect it to be anything
except REALbasic.

If you are a classic Visual Basic developer (pre-VB.Net), you will find the
interface and syntax very familiar.  You will be able to upgrade your VB6
apps better than Microsoft's transition tool to VB.Net.  And, the coming
2005 interface (60 days until release) has a much enhanced UI (screenshots
at http://www.realsoftware.com/demo15/).

REALbasic 5.5 is even FREE to former Visual Basic developers and they will
receive a discount on REALbasic 2005 when it gets released in 60 days (or
less).  Just sign up here -
http://www.realsoftware.com/realbasic/vb6/index.php - BEFORE APRIL 15, 2005.

Although those reasons are all good enough to at least take a look at
REALbasic, the true value of REALbasic, for developers AND end users, is
freedom of choice with the OS.  REALbasic applications are truly
cross-platform and will run on MAC, Linux or Windows machines.  This means
that, as prices continue to climb for Microsoft MSDN subscriptions (almost
$10,000 for the top MSDN subscription) Microsoft OSs and Microsoft software
(like $499 for Office 2003 Pro) you and your customers have the option of
choosing a less expensive OS like MAC, a supported (but way less expensive
than XP) Linux OS like Novell's Linux desktop, Red Hat Workstation or even a
FREE OS like one of the hundreds of free Linux distros.

Microsoft has shown that they no longer value (or even listen to) their
customers.  They will be the next IBM.....decimating the empire that they
have built by ignoring customer needs and pricing themselves out of Windows
development.

Make no mistake about it, Microsoft IS pricing themselves out of the
software market by pricing the small and mid-sized business out of Windows
development.

Microsoft seems to be forgetting that the ability for small and mid-sized
shops to do their own development is a large part of what has made Microsoft
the largest software company in the world.  Its what drew small companies to
Windows - the ability to develop their own relatively inexpensive software
solutions in-house.  Not to mention the millions of developers that used
Windows tools to develop and sell their own software.

And, while there are certainly alternatives other than REALbasic (Mono +
Linux, C++ + MAC, Java, Borland's Delphi, etc.)  None of them offer the
platform dependence that REALbasic does........nope, not even JAVA.

I humbly suggest you take a look at REALbasic.  Even if you don't choose it
as your development platform, at least you know what's out there and the
possibilities for true cross-platform development.

Whatever development platform you choose, may I suggest that it be
cross-platform.  Not because Microsoft is big and should be crushed.  I'm
not now (nor have ever been) anti-Microsoft.  But, I am pro-me and pro-my
customers.

Being pro-me and pro-my customers, I have to make hard decisions to protect
them and me from future harm.  One of those decisions is the decision to
begin developing cross-platform solutions for my customer base, so that they
have the freedom to move to a more-affordable OS and more affordable
development platform for their company's specific needs.

For most small businesses, not being on a Microsoft OS is not a problem.
Most, if not all of the software they write is for internal use.  So, their
OS and desktop software decisions can be more financially driven.  This
means that using Linux (even the MAC OS is cheaper than XP) for a desktop
solution in many small and mid-sized businesses is an easy call.

Their daily task is not to use Microsoft products.....it's to get business
done in a manner that saves time and money while not sacrificing quality.
Microsoft would do well to understand that.

I believe that responsible developers and ISVs owe it to their customers to
give themselves and their customers the option of OS independence.  Giving
REALbasic a look might help you towards that goal.

Jim Hubbard

(I will not respond to flames.....although serious questions or debate is
welcomed.)

Jim,

You told us a week ago that you was starting to investigate how you could
use Visual.Studio Net and its tools. Are you proceeding already with that?

Cor

I have been playing with VB.Net 2005 Beta.  It looked much better than the
2003 version and even got it's groove back a little with the simplified
interface.

But, faced with the outrageous pricing of the MSDN subscriptions, I am
forced to look at alternatives in making my decisions.

I also have to have my customers' best interest at heart, as well as my own.
I cannot, at this time, justify the continuation of the purchase and use of
the Microsoft OS, software and development tools when taking their pricing
into consideration VS the alternatives available to myself and my customers.

A company that makes Widgets can make and sell Widgets on Linux or MAC just
as easily as on Windows if they choose their development tools and desktop
software wisely.

So, why continue to pay the high "tea taxes" of Microsoft?

Although I have not made my final decision, I am leaning towards throwing
the Microsoft desktop into the harbor.

Jim Hubbard

why use the IDE at all? the framework and compilers are free, so there is
really nothing to complain about and get all biased about when you can do it
all for free anyways.. there are 3rd party IDE's out there for the .NET
framework that are free also. Why don't you look into them if you dont want
to pay for microsoft's IDE. Just because it's visual studio doesn't mean you
need visual studio to create programs for .NET. just get the .NET framework
SDK and you have all you need, then pick up a free IDE if you need a
graphical experience also.


Show quoteHide quote

Sure you need the .Net IDE to develop for .NET....well, if you want to be
competitive with other .Net development shops.

The 3rd party IDEs are always behind (sometimes WAAAY behind) Microsoft's
development tools in features because they don't innovate - they copy.  That
puts you at a disadvantage among other .Net framework developers.

Like the Mono project.  It's far behind the Microsoft C# IDE and the VB
version of the Mono project is even worse.

You have to be able to compete in the arena that you choose to fight in.
That's one reason all developers want the highest MSDN subscriptions.
Besides having to wear many hats at their jobs (especially at small
businesses), they also need to be able to do anything that is possible with
..Net (like when your boss sees another competing app do something and says
to make your do it too) .  With free IDEs, most of the time, this simply
isn't possible.

The IDE is only the tip of the iceberg.  Breaking backwards compatibility
and the ridiculous cost of the Microsoft OS and software ($500 for Office
2003 pro - give me a break) are also main factors in the decision that needs
to be made by all small businesses before they got to .Net and on to
Longhorn.

If you can do your business on a different OS for less money, that's the
financially responsible thing to do.

Increasingly I am coming to see that there's simply no reason to continue to
allow your business to be held for ransom by Microsoft.

Jim Hubbard

I don't know anything about you, Jim, but Brian was right about doing it for
free, and if you've had an MSDN subscription in the past, then you already have
a license to use the tools that came with it forever.  So why don't you continue
to use the tools you have (the MSDN subscription has included VB6 since it's
release, so you have a copy of it) and get on with making money instead of
whining.  I suspect you spend more time writing crap like that below than
working anyway...

just my opinion.  I could be wrong.

Show quoteHide quoteOtis Mukinfus
http://www.otismukinfus.com

Otis,

Hubbard's opinion is shared by a lot of companies. For instance, the
previous company I worked for (small company) decided to switch to Java just
because MS development environment became too costly compared to the benefits.

I can imagine that other small companies will drop MS development
environment for cheaper environments. I'm neither for nor against this
strategy; it all depends on how much money you can make with a certain
project. If MS env. is too costly people/companies will change environment.
That's pure economy.

Another sad thing perhaps, is that prices of other software products will
increase because of this.

I'm very curious where this will lead...

TT

Show quoteHide quote

Show quote Hide quote You are right.  You can use the tools forever.  But, Microsoft is actively
breaking backwards compatability with the old tools.  Case in
point....Outlook 2003.

Now, you'd think that Outlook 2003 would be backwards compatible with Office
2002.  I mean, most professional companies provide backwards compatability
for 2 major versions.  Microsoft used to.....but now they've chosen a path
of abandonment and intentionally breaking backwards compatibility.  Why?

Nevermind the why......that's another thread.....

VB6 runtimes will not be supported on Longhorn.  So, if you keep using the
VB6 tools, your audience dwindles to nothing.  Can't do that.

Show quoteHide quote

Jim Hubbard wrote:

So Microsoft has been lying about the VB6 runtime being included in
Longhorn and supported? I think not..

I hadn't seen anything from Microsoft indicating support of the VB6 runtime
in Longhorn.  And, since you did not feel the need to back up your statement
with a link - I went on a fact-finding mission to see if Microsoft said
anything like this on their website.

After searching for over an hour, I finally found somebody at Microsoft that
says (via his blog - not on an official Visual Basic page on the Microsoft
website) that the VB6 runtime will be shipped with Longhorn and supported
for the lifecycle of Longhorn.  Read it here - http://blogs.msdn.com/JRoxe/.

I doubt this is the reference that you had in mind as it was just posted
yesterday. Could you please post your Microsoft references?  I am curious as
to when this was first stated openly by Microsoft.  Was it yesterday, or did
I miss something earlier (which could also be the case).

In fact, the blog directly speaks to the millions of concerned VB6
programmers and directly addresses the petition at
http://classicvb.org/petition.  It seems Microsoft is trying to make the
petition go away without actually DOING anything to make up for tossing out
a language that so many are so dependent on.

In part, Jay's blog states "There are strong feelings on all sides of the
issue that sparked this petition and I know that this note is not going to
address all of these concerns.  However, I hope that we can continue to have
an open dialog around this issue.  Some of these discussions will continue
in the public forum, but please also feel free to contact me directly."

That's just great.  Whenever a company doesn't want to do anything about a
problem, but they want the bad press and problem to go away, they send out
the talkers.  I'm tired of talking.  FIX THE DAMNED ISSUE BY PUTTING
UNMANAGED VB6 SUPPORT INTO THE VISUAL STUDIO IDE!  Nothing else is going to
make this go away.

You did it for C++, and you can do it for classic Visual Basic......the
question is will you?  Or, will you continue to walk away from the largest
army of programmers the world has ever seen......the people that made you
great?

Speaking of going away, I am setting up my Novell Linux box and MAC today to
do more thorough testing of REALbasic.  Looks like fun.  At least I won't
have to worry about Microsoft abandoning me if I finally choose the
MAC/Linux/REALbasic route.  (Go to www.realbasic.com for your FREE copy of
REALbasic 5.5 standard until April 15, 2005.)

There is one thing, and only one thing, that will get Microsoft's attention.
Mass defection to Linux/MAC and a different programming language.  They have
forgotten that the customer is always right.  And, only something big will
drive that point home for them.

Although that sounds quite radical, it is no more radical than the change
that classic Visual Basic developers already have to go through with
Microsoft.  And, you will at least be the partial master of your own destiny
then.....not a gnat to be swatted by the monopolistic hand of Microsoft.

And, it's much cheaper than the Microsoft solutions.  Only $89.95 for a
COMPLETE desktop in Novell Linux (SUSE) 9.2 Professional.  That includes
Open Office, free email clients, free IM clients, free photo editing
clients......really everything you need for day-to-day operations in most
businesses.  Contrast that to XP Professional at $279.99 (for a new install)
and Office Professional 2003 at $499.99 and the $89.95 option is at least
worth a test drive.

The $780 for basic daily activities with a Microsoft desktop is more than
the hardware needed to run it......twice as much as the hardware for a
simple business workstation.  And, for what?  So we can say we work on a
Windows desktop?  Who gives a rat's ass what desktop is in place as long as
I can accomplish my daily job of making more, cheaper and better widgets to
sell.

Most company's don't get paid because they are using Microsoft
products.....they get paid to deliver goods and services, and their clients
really don't care what OS or desktop the company uses internally.  Come to
think of it.....neither do the workers.

So, who does care (besides Microsoft, of course)?

Jim Hubbard

Jim Hubbard wrote:
Show quoteHide quoteOfficial comment from Eric Rudder at Microsoft:
'We have heard a large number of folks ask for VB6 runtime support on
Longhorn. We will do this. We will also continue to monitor how this
situation is working and make sure it works as smoothly as possible. For
VBA, we will continue to have support in "Office 12."'

Via a microsoft chat:
http://msdn.microsoft.com/chats/transcripts/vstudio/05_0318_VS05.aspx

This is nothing new. I've heard this for quite a while...

Never going to happen. I personally don't want it to happen. If the apps
run for the next 5 years, that will be long enough for me to convert my
customers over to .Net. Most of my customer's are just now upgrading to
XP, so I really won't have to worry about it for a long time, if at all.
By the time they start to migrate to Longhorn, they will need to upgrade
our software too.. Selling upgrades and new features in software is what
makes us money. If a customer buys it and wants to use it for 15 years,
that's fine, but we only make money on that initial sale and then
support contracts. I'd rather sell them better software with more
features every few years plus the support contracts.

Don't compare C++ to Visual Basic.

Show quoteHide quoteSo, let me get this straight... You would rather spend your time and
your customer's money by downgrading them to real basic, than upgrading
them to a .Net language? Especially when that company is really small in
comparison to Microsoft? Hmm... If I were your customer, I'd be pissed
and running from you.

Show quoteHide quoteYou get what you pay for.

Really? What market are you in? In ours, it matters. In fact, some IT
departments kicked us out before we switched to VB because they didn't
want non-Microsoft products in house. The same went for MySQL. Open
source? No way.. They were having none of that.... And the workers want
to get their job done. If they can't, they get fired. Try putting a
linux desktop in an manufacturing environment. It won't last. I've seen
it happen.

I personally don't really care what happens to VB6 at this point. I've
started to upgrade my skills from it to VB.Net, because I saw the need.
My customers need more advanced features and better support for newer
technologies. I can do that and stay with Microsoft by moving everything
to VB.Net, or even C# if I wanted to.

I look at this as an opportunity, not a hinderance.

But, what happens when a .Net patch breaks your code?  Not many people have
caught onto the fact that Microsoft issues patches for .Net (although you
have to call them to get one).

If you find an error (or just some weird behavior) in the .Net framework,
Microsft may have a patch for it that you can get and apply to your systems.
You can even have it installed with your application (which would be
neccessary if you used it - as others most certainly won't have it
installed).

Problem is, if another application is already installed (or gets installed
later) that writes around the error in .Net, your patch will cause that
author's app to malfunction.

It works the other way too.  If you code around all of the bugs found in
..Net (yes, I know....every program has bugs - I'm not digging at Microsoft
for not having perfect code - remeber, I liked VB6) but, another author
patches the framework, (BAM!) your code malfunctions.

It looks like trading DLL Hell for Patch Hell.  What's the difference?

All valid points.  But, usually business changes dictate that software be
updated and enhanced regardless of the OS or programming language status.
That's where we make most of our money.  We service clients with volatile
business climates.  They always need a change for something.

(awww crap!  One of *those*.....)

Show quoteHide quoteI guess it depends on how you look at it.  I consider creating applications
that link everything into a single executable (as opposed to a framework
that may or may not be "patched") a more stable solution - therefore an
UPgrade.  I consider being able to service my clients needs on Windows, MAC
or Linux another advantage.  I consider the added ability to write code for
any Windows, MAC or Linux customer good for my company - as it expands our
potential client base to those desktops and increasingly includes more
goverments and school systems around the globe.

In all, I'd say that I consider true safety from DLL Hell (or Patch Hell),
an increased customer base, the ability to adjust to a changing desktop
market and the ability to assist our customers in choosing the best
desktop/server environments for them an UPgrade.

Microsoft's size is one of the disadvantages of doing business with them.
No longer do Microsoft customers call the shots.  Microsoft is doing
anything it damn well pleases....just because it can.

Real Software has to listen to it's customers.  And, (as a potential
customer) I like that.

I don't know of any customers that like being told what to do by the company
they are doing business with.  What would happen if you told one of your
customers that you were going to change their technologies even though they
didn't want you to?  You could even assure them that it's in their best
interest.  But, I doubt you'd be around much longer.

However, Microsoft pulls this off.  How?

It's two-fold.  Microsoft doesn;t have to convince business.  They convince
programmers that they have a new and improved thingy that is "the new big
thing" in programming.  Developers make their living developing.  So, in
attempt to keep stay on top (thus keeping an income stream going) they rush
to adopt the latest from Microsoft.  Then, the devlopers try and convince
their bosses and clients that they jsut have to get "the new big thing" or
they will be left in the dust.

Microsoft uses fear to sell their products.

Does a business really need the very latest from Microsoft to compete?
Rarely.

You'd never be my customer.  We screen better than that.  We only take
clients that we know we can make happy.  Fortunately, in the last 2.5 years
we've only had to turn away 3 clients.

Show quoteHide quoteYou sure do.  Viruses, unstable IDEs, intentinal breakig of backwards
compatability and a forced march to deposit more money into Microsoft;s
$50,000,000,000 cash pile.

I think the cost is too high.

If we adopt REALbasic as our core tool. we wouldn;t be a good fit for those
companies.  I can live with that.

Increasingly, governments, large companies and school systems are moving to
Linux.  Maybe we're just a little ahead of the curve.

And, that's fine.  We are not a one-size-fits-all software shop.

Right.  It's your job to make sure they can get that job done.  Usually,
though, if they can't get their job done because of the software, ot would
be you gettig fired......wouldn't it?

It should be.  It's your job to get your customers the best solution for
them.  IT may be Windows.  It may be Mac,  It may be Linux.  They look to us
to know and guide them in this decision.  That's what we get paid for.

I would never suggest an operating system that would slow production or harm
productivity.  That would hurt them and our reputation.  I'd rather not have
the job at all, and recommend them to another shop that can help them.

Every business and situation is different.

Good.  You should do what makes you happy.

Interesting.  I have yet to get the customer that cares what technology I
use to write their applications.  They just want to be able to compete and
share info with other businesses as inexpensively as possible.

REALbasic is not for everybody.  I wish you well with Microsoft
technologies.  I am just looking at this from my point of view and what is
needed to satisfy the real estate companies, home builders and attorney's
offices that I support.

IMHO, it is simply an opportunity for Microsoft to pad their pockets.  I was
doing fine before .Net, and I'll do fine after it.  But,I have to make the
best call that I can for the future.

That doesn't include willful breaking of backwards comparability.

Jim Hubbard

Jim Hubbard wrote:
If you think this doesn't happen on Linux, you are wrong. I've even seen
this at home. It's also mostly why you only see binary packages
available for certain linux distros and versions... They change just
about every new version that is out.. Hence the reason you have to
recompile with just about every upgrade for software you download,
unless you are lucky enough to run the most popular distro. It's the
same thing with every OS you look at. Does a lot of the older Mac
software run on OS X? Some do.. but not all.. I also seem to remember a
lot of instability on the initial release of OS X. I also see a lot of
instability in Linux. I do a lot of C++ coding on Linux.. Trust me.. The
free IDEs available are not as stable as you think.

You must be.. We also deal with government recreational facilities and
school districts, and none of them have had Linux so far. But hey, every
state could be different, I guess...

But I thought that was your goal in switching to realbasic?????


Ever hear of Visual DataFlex? It's a programming language by DataAccess
corporation.. It's pretty good. Very easy to use. Seperates all the
business logic from the presentation logic. It works really well.
Smaller company, huge community support, they listen to their
developers. They also break backwards compatibility all the time, leave
features out that developers want, charge license fees for software you
sell to customers. The list goes on and on... You will see this with
EVERY company you deal with. Just because Microsoft makes millions a
day, doesn't make them the bad guy, it just made them the bigger target
for people that like to complain that the "man" is coming down on them.
You will see it with all of them... It just takes time.

in article gUu5e.30998$hU7.6***@newssvr33.news.prodigy.com, Aaron Smith at
thespirit***@smithcentral.net wrote on 8/4/05 1:35 pm:

Yes. I still have to see one which doesn't.

Some??????

Which ones?

Trust is earned, not given away.

Might be me but your remarks don't particularly inspire trust.

Markus

Show quote Hide quote Couldn't agree more

I develop on both Windows & Mac OS, I have to say that Mac OS X breaks
backward compatibility alot more than Windows.

Cheers

Exactly what issue are you talking about? I've read the petition and I can't
find any descriptions of anything I would consider an issue.  What I *do*
find instead are specifications for VB.COM.

For example, the very first objective of the petition is "Future versions of
VB6/VBA should: Use existing VB6/VBA projects without extensive conversion;"
All of the objectives are in this vein; don't state what the problem is, but
just jump ahead to what the authors believe is the self-evident solution.
Given these types of "objectives", by definition, the only way that
Microsoft can satisfy the "issues" in the petition (which pretty much boil
down to "This is what we want VB.COM to be") is go create VB.COM.

The reason I'm being so critical of the language of the petition is that if
the petitioners were to have stated their greivances independently of their
specifications for the solution, then it would be much more apparent that
there are far more proportional solutions to the implied problems than the
creation of VB.COM.  Nothing but adding unmanaged VB6 into the VS.NET IDE
will make the issue go away?  No matter if you define the "issue" as poor
COM interop support, a poor code conversion wizard, the ending of mainstream
support for VB6, or any of the other issues alluded to (but never explicitly
stated) in the petition, this statement is just plain outrageous.  The
"only" way?  Come on.  The whole point of my post "Please do NOT sign the
VB.COM petition" is that there are far more reasonable solutions to the
issues implied in the petition than the creation of VB.COM

- Mitchell S. Honnert






Show quoteHide quote

That's the issue that I was referring to......the ability to use our huge
codebases without extensive rewrites.

To me, this is the whole problem.  If we could use VB6 code (or import it
via an automatic upgrade as we have ALWAYS been able to do) from VB.Net
without extensive rewrites - I don't think you would have seen the petition
at all.

I'd like to move on to .Net.....I just don't want to rewrite hundreds of
thousands of lines of code to do it.

How Microsoft accomplishes this is up to them.

I agree.

How else would you support VB6 applications (like Microsoft is doing for
unmanaged C++ legacy code) and further the move to VB.Net while minimizing
the financial impact to Microsoft (i.e. not have a seperate team and ide for
VB6 and VB.Net)?

I'm open to anything that will save the thousands of man-hours invested in
classic Visual Basic 6 code.  Problem is....Microsoft isn't offering any
alternatives to our suggestions.  What do you have in mind?

Jim Hubbard

Show quote Hide quote That's the issue *you* may have been talking about, but it's not the point I
see as being made by the petitioners.  So, they didn't say "We think the
code upgrade wizard is insufficient", they said, "We want VB.COM and we want
it to do this and that."

True enough.  My issue is with how the petitioners believe Microsoft should
accomplish "this", not that something needs to be accomplished.

Show quoteHide quoteWell, first of all, I don't believe it is Microsoft's responsibility to
support VB like it "is doing for unmanaged C++ legacy code".  I think
Microsoft should support VB6 in a way appropriate to VB6 being the version
immediatly before a major update to a programming language that broke
backward compatability.  To me this means that it should give the community
more than what it is now, but less than what is being asked for in the
petition.  I mention three alternative solutions in another post: a better
code upgrade wizard, better COM interop (I haven't had any problems with
this, but it seems to be one of the implied issues), and an extended
mainstream support period.  On that last item, I believe that MS owes longer
support for VB6 (where the upgrade path was to a langauge which broke
language stability) than for VB5 (where the upgrade path was much more clear
cut).

I gave some alternatives in the post I mentioned above, but they were the
first things that came to mind rather than an official request (as was the
case with the petition's VB.COM).  Reading between the lines of the petition
and its FAQ, it seemed to be saying that the code upgrade wizard was
insufficient, there were problems with COM interop, and that the mainstream
support for VB6 was too short.  It seemed an obvious next step then to
suggest that the appropriate solution to these implied problems would be a
better code upgrade wizard, better COM interop, and a longer mainstream
support period.  I think we both agree that what Microsoft is doing now is
not sufficient given the number of VB6 developers out there; I just don't
think the petition's proposal is in proportion to the problems.

- Mitchell S. Honnert


Show quoteHide quote

Jim Hubbard wrote:
Show quoteHide quoteThat may not always be true. With sufficient numbers of
developers jumping ship, that adds a significant incentive
to make better 3rd party IDEs faster. Also, while those
who -copy- MS tend to be inferior, there are a number
of third parties who offer superior features that use
a different idea of how to do things.

Which a lot of people may decide to do.

Show quote Hide quote I wish this were the case.  But, it seems that no other company has put 2
and 2 together yet.....

Sun, Borland, Novell......all of them are missing the main 2 ingredients
that are absolutley neccessary to give Microsoft a run for their money and
the people of the world a real choice in desktop operating systems and
applications.

You have to have an affordable desktop....Linspire, Novell (SUSE), Mandrake,
even the MAC OS (only $199 for 5 licenses - and you don't have to lie and
say you're a student) are all more affordable than Microsoft.  The thing
they are missing is an easy way to develop applications (like Visual Basic
was for Microsoft).

You see, the combination of affordable desktop, plus and affordable,
easy-to-use development platform is the key to winning the war with
Microsoft.  You win the war in the trenches.....by defection - like
introducing democracy into a totalitarian society.

When you have an affordable desktop, people WILL buy it.  People will try
it.  And, if there is an easy development platform for it
(say.....REALbasic), millions of disatisfied classic Visual Basic
programmers (and many non-programmers) will write applications for the
cheaper OS, because (A) they can afford to and (B) they like to write
applications for fun and to sell.

Once this starts, more and more applications become available for your
affordable OS.  Then, more and more poeple will buy the OS because of the
vast number of applications available for it.

This model has been proven (and evidentally forgotten) by none other than
Microsoft itself.  I told my sister, just the other night, that had I a
compnay that produced an OS like Apple's MAC, Linspire or Novell Linux and
if I could acquire a product like REALbasic to bundle with my OS.....that I
would change the world.

And, I would.

Jim Hubbard

Inline:
<snip>
Windows XP Home Edition can be had for less than $100.00 (USD) almost anywhere.  And extra licenses are not that expensive.


I think the affordable desktop Windows XP & development platform , Visual Basic Express (announced to be $49) will be a good,
cheap, combination for the non- programmers you mention in the paragraph below.


RealBasic, is not a cheap alternative to VB.  Especially comparing their cheapest version , Standard, which sells for $99. ( I
know it's free for now, they are moving to a new version and it might pay them to give the Standard(current version) version
away to VB developers for free)
Where as , Visual Basic Express , will be sold for $49 and might be bundled in some other products (like books maybe) . And
having used VB Express Beta1, I can say it is and will be , a great product for the price.
To get full cross platform capability from RB requires their PRO version which sells for almost $500.00.
That is more than Visual Studio 2003 PRO currently sells for.  And you get access to more than one programming language.  Pretty
good deal if you need it.


In fact, Linux can be had for free.  Along with all kinds of development tools.  They are available for download everywhere.
Where the free part ends, is in the support department.  Although there is plenty of online support for Linux from users and
developers, the real costs appear when a business decides to use Linux and has to retrain people to use it and support it
in-house.   And for home users that are not
real computer knowledgeable, Linux is a real problem.  In this case, Windows XP (to me) is a clear winner.  If a home user
manages to get a Linux destro installed, (which has improved a lot) they had better be satisfied with the installed apps.
Because, if there is a special application they need or want, it may not be so easy to install (or available).  And a messed up
install in Linux CAN kill the entire OS.  Something, that I have not seen in a while in XP (except for Norton products.....).
   I don't think the "Classic VB Developers" will be dumping Microsoft Products in favor of Linux solutions.   Better to do what
they are doing and pressuring Microsoft for more support.  And at least
a better migration path to newer tools. ( I tried moving a couple of my apps. to VB.NET 2003 and had so many ToDo's that it
turned out to be easier to just do a rewrite)
Anyway, I just wanted to jump in here and add my .02 to all this.  I have tried RB Standard. And it is no replacement for VB6.
The only thing that RB has going for it in my opinion is being able to compile
executables for more than one OS. But, the Standard edition only does that in a very limited way. And is not good enough for
complete testing.   As you probably did, I received an email from RS offering a FREE(one of my favorite words) copy of RB PRO ,
if I managed to be one of the top 100 people to get others to download and try RB Standard, thru a specialized link.   Well, I
tried that and promptly got flamed for it. (in the "classic" VB newsgroups & one Linux newsgroup)  So, I won't be doing that
again!!
Good luck on your quest (whatever it is)........  ( I don't think you are going to convience people to drop MS products)
james

Help me get free software at: http://www.realbasic.com/vb6/index.php?id=CMZJCYDC
Good till April 15, 2005

james wrote:

bundled in some other products (like books maybe) . And
product for the price.
version which sells for almost $500.00.
you get access to more than one programming language.  Pretty
http://www.realbasic.com/vb6/index.php?id=CMZJCYDC
James,

I believe VB Express does not include the ability to create a stand
alone application so that's not a fair comparision. VB Express will not
be a good solution for anyone that wants to distribute their
applications. It's also not available at the moment so we don't know
what will happen with it ultimately. BTW, students can get REALbasic
Standard Academic Edition for $69.95.

Lastly, the comparison of our Pro product to Visual Studio Pro is not a
good one. Visual Studio only compiles for one platform: Windows. And
while REALbasic provides only one language, I wonder how many VB
programmers use the other languages that are a part of Visual Studio?

Geoff Perlman
President and CEO
REAL Software, Inc.

Show quote Hide quote You are correct that VB Express does not include the ability to create stand alone exe's.
But, I have not found that to be as big a problem with current versions of VB as some
people like to think it is.  Most end-users of an app, will (using a properly setup installer)
never notice wheather or not an application they install is a stand alone or has other files
included for it to run.
And I shouldn't have compared RB Standard to VB Express, which is not available , except
in Beta.  Instead I should have used VB 2003 Standard which is available from Amazon.com
for $89.00.   And the Academic Edition is cheaper too, $49.00 thru ccvsoftware.com.


Yes, RB PRO does compile for more than one platform, which is my main reason for being interested in it in the first place.  And
also why I jumped on the chance to try the Standard version, and then after receiving the promotional email, try to get others
to download the "currently" free Standard Edition, in hopes of
getting a chance to win a copy of the PRO version to better test the cross-platform abilities of RB.
The Standard version does compile to other OS's but, because of the 5 minute runtime limit, it is not suffecient to test an app
properly in another OS. ( in my case Linux, using KDE)  Hence, my trying to get others to download the Standard edition.  Which,
I have stated in another post I got flamed for, even though I made sure to put OT in the Subject line.
That does not mean I have completely given up on RB.  But, looking thru comp.lang.basic.realbasic, I have read a lot of posts
about the short-comings of RB compared to VB6.  Maybe, the next version will address those issues. If so, then, I will be more
interested in it.  That does not mean I will stop using VB6 or VB.NET (or other languages for that matter) as I believe in using
the correct tool for the job.  And for one prospective client, I had hopes that RB would fill that need.  I need to build an app
that will work both in Windows XP & Linux ( Redhat Fedora Core 3 & KDE) and would like to use something that is familiar to me
in both enviroments.  RB, might be it.  But, short of me winning a copy of RB PRO, I will have to at least for now, write the
demo app in two different Basic IDE's.  Gambas for Linux and VB.NET 2003 for Windows XP.  ( I cannot afford to spend a lot to
find out that the potential client has changed his mind).
And before I get too carried away, I have used some of those other languages in Visual Studio besides VB, at one time or
another.  Which made it worth the money I paid for Visual Studio at the time.
james


Download & register ,RealBasic Standard Edition and  help me win free software at:
http://www.realbasic.com/vb6/index.php?id=CMZJCYDC
Free download good till April 15, 2005

On 6 Apr 2005 15:21:07 -0700, ge***@realsoftware.com wrote:


¤ I believe VB Express does not include the ability to create a stand
¤ alone application so that's not a fair comparision. VB Express will not
¤ be a good solution for anyone that wants to distribute their
¤ applications. It's also not available at the moment so we don't know
¤ what will happen with it ultimately. BTW, students can get REALbasic
¤ Standard Academic Edition for $69.95.
¤
¤ Lastly, the comparison of our Pro product to Visual Studio Pro is not a
¤ good one. Visual Studio only compiles for one platform: Windows. And
¤ while REALbasic provides only one language, I wonder how many VB
¤ programmers use the other languages that are a part of Visual Studio?

It's all about choice. While we may not use more than one language we do have a choice. We also have
a choice with respect to other features, such as the development of components for distributed
applications and shared code libraries, the development of web applications and services - choices
notably absent from REALBasic.

While touting the advantage of a multi-platform development tool I think it's also important to note
that this feature is not particularly significant with respect to demand. The cost to support
multiple platforms is typically a deterrent.


Paul
~~~~
Microsoft MVP (Visual Basic)

Show quote Hide quote You're right.  Those things are absent right now.  But, it is something the
REALbasic team is working on.

While still far behind Windows, the demand for Linux is growing by leaps and
bounds....if I may....

http://news.zdnet.com/2100-3513_22-5145332.html

http://searchenterpriselinux.techtarget.com/originalContent/0,289142,sid39_gci1004138,00.html

http://www.linuxworld.com/story/45850.htm

http://www.cioupdate.com/trends/article.php/2237451

http://news.com.com/2100-1001-821073.html

http://www.cio.com.au/index.php/id;952191873;fp;4;fpid;21

http://www.itweb.co.za/office/FirstTechnology/0405120751.htm

http://www.theinquirer.net/?article=4570

http://www.tolkienonline.com/docs/6678.html

http://linuxtoday.com/it_management/2004111201626NWBZDP

http://itpapers.zdnet.com/abstract.aspx?dtid=3&scid=264&docid=88285

http://www.intranetjournal.com/articles/200310/ij_10_03_03a.html

http://www.novell.com/products/linuxenterpriseserver/why_novell.html

These links were chosen to show that the adoption of Linus is not new and is
not slowing.  If you'd like more let me know.

It's like the adoption of Firefox in place of IE.  Firefox is making great
strides in the browser market, with no signs of stalling.  People will adopt
the best technology for their enterprise, whether that is MAC, Windows or
Linux.

The adoption of Linux will happen sooner than you think, in more places than
you think.  There are things in the works right now that will make Linux the
premier desktop of small and mid-sized businesses worldwide.  Add them to
the governments making the switch, and you have yourself a little
revolution.

Don't worry....it'll be fun.  I promise.

Again, you are right.

In the past, developing for different platforms has been costly.  This, for
the most part, negated any potential gains from supporting Linux or MAC
operating systems.

But, REALbasic makes this as easy as recompiling the software.  Just click
and run on a different OS.  There is no additional development required.
Just select the checkboxes of the platforms you want to distribute your app
on and click "Build".

REALbasic builds your app for all of the platforms you have selected.
Developing cross-platform desktop applications can't be any easier than
that.

Jim Hubbard

adoption of Linus is not new and is
<Snipped links>

Show quoteHide quoteJim, you do know that several of those links you posted are the same article don't you?  And some are almost 2 years old.  And
if you read those articles, it clearly states that Linux is not any cheaper than Windows from a support standpoint.
As for RealBasic and cross-platform support, have you tested it?  Having downloaded the Free standard version, I can say that in
the case of a simple app, that RB will compile to Linux (haven't tested on Mac).
But, not being able to build a complicated app and fully test it in Linux (due to the 5 minute time limit in the Standard
edition) I cannot say for sure how well Linux or Mac OS is supported.  So, if you are like me and have not used the PRO version
of RB, I would think it would not be a good idea to make a broad statement on how easy to develop a cross-platform application
using RB is.   You cannot (or should I say , I cannot) fully stress test an application in 5 minutes in a different OS than it
was developed in and be certain that you/I will not have problems.
My final questions to you is why are you spending so much time on bashing Microsoft over all this? If you have decided to
migrate to Linux and leave Microsoft products behind, why are you still posting on all these different newsgroups?  Wouldn't it
be better to get up to speed on RealBasic and Linux?
Just a few thoughts and my .02 and worth exactly what you paid for them...........
james

Show quote Hide quote I grabbed the links quickly, so I did not read them all as thoroughly as I
would have liked to.  Arguing against points that have already been proven
to be false is a pet peeve of mine and one thing that I loathe to waste time
doing.

The support costs are about the same for both platforms, but the original
cost of hardware and software is MUCH less on Linux.

Only for XP Pro and SUSE 9.2 Professional.  I don't have a MAC handy....but
I will have one by this weekend for testing.

I talked to Geoff about this today.  I told him that 5 minutes was way too
short a demo time for complicated applications, and he has an idea of how to
lengthen that time for more complicated applications.  I hope he can get it
in for the version 6 release in the next 60 days.

Actually, I have been accepted into the beta program and am currently using
the latest beta to test the app out.  So far, I love the look. (Geoff really
needs to show more of the interface on the website - it puts version 5.5 to
shame.)

I agree, and so does Geoff.  He's working on changing that.

I am in the process of deciding.  Who knows?  Microsoft could make a
decision tomorrow to actually support VB6 or even offer a valid upgrade
tool....or (GASP!) not charge $10,000 per developer for the top MSDN
subscription.  If any of those things happened it would have a definite
impact on my final decision.

Hopefully these posts will help others to decide whether REALbasic is an
alternative for them.  It's not for everyone.  It's more for the "task
oriented" developer than the professional C++ or C# developer.  At any rate,
it's certainly worth checking out.

I'm working on that.  Playing with the beta......and trying a simple app or
2.  If those go well, I will try and port a 95,000 line application from
Visual Basic to REALbasic to really test out the limits of the conversion
process.

One step at a time.

I always appreciate any honest questions or even criticisms.  It's the
flaming I can do without....

Jim Hubbard

On Thu, 7 Apr 2005 18:33:21 -0500, james wrote:

Show quoteHide quoteJames,
I've ported one of our VB apps to RealBasic in the interest of making it
more portable. The idea was to not require the VB runtimes to be installed,
and this works very well. The final exe is a bit large, but still not as
large as the VB exe and it's runtimes together. Anyway, just for fun I
compiled the program to Linux, and loandbehold, the thing ran, and for the
most part worked. That's where the kicker is, it didn't work completely as
it did in Windows. The StaticText and Caption on controls would no longer
fit in the respective field sizes. I understand that there are font
differences and such between different OS's but it does require adjustment,
my point here. As well a control array in a GroupBox didn't function
properly, again some more tweaking. Now this was simply a matter of
compiling code that works in Windows and compiling to Linux, with no
further consideration, so I'm sure more work needed to be done, but again,
my point is that it is not as simple as just setting some compiler options.
I really kinda like RealBasic though, just wish it were'nt so Mac oriented,
although I do realize that's it's roots.

Show quote Hide quote Thanks for the info.  I think you could probably make those changes for the different OS's the same way
Jim did in his example for File I/O using the #TargetBoolean to have the compiler output the correct options for the targeted
OS.  I have not done much testing with the Standard Version that I downloaded as I feel the 5 minute run time for Linux & Mac OS
are too short for me to fully evaluate and test anything.  Sure, something as simple as a Form's Caption should show up right
away, but, things much deeper in an application may not show up as quickly or be as obvious.  I guess I will wait and see if I
manage to be in the top 100 people who manage to get others to follow their personalized links. If that happens, then I might be
able to do some better tests with the PRO version or even RB 2005.
Good luck and I hope that RB is all you hope it is and need.
james


Only a few days left to Download and get a FREE License for Real Basic Standard Edition!!!
Offer expires April 15, 2005 .
Go here for your copy:   http://www.realbasic.com/vb6/index.php?id=CMZJCYDC

¤ > It's all about choice. While we may not use more than one language we do
¤ > have a choice. We also have
¤ > a choice with respect to other features, such as the development of
¤ > components for distributed
¤ > applications and shared code libraries, the development of web
¤ > applications and services - choices
¤ > notably absent from REALBasic.
¤
¤ You're right.  Those things are absent right now.  But, it is something the
¤ REALbasic team is working on.
¤

The problem is that they're trying to catch up to Classic Visual Basic. They can't touch .NET.

¤ >
¤ > While touting the advantage of a multi-platform development tool I think
¤ > it's also important to note
¤ > that this feature is not particularly significant with respect to demand.
¤
¤ While still far behind Windows, the demand for Linux is growing by leaps and
¤ bounds....if I may....
¤

Well that's what some folks having been saying for the last five years. You would have thought by
now that Linux would have passed up Windows by now. ;-)

¤ It's like the adoption of Firefox in place of IE.  Firefox is making great
¤ strides in the browser market, with no signs of stalling.  People will adopt
¤ the best technology for their enterprise, whether that is MAC, Windows or
¤ Linux.
¤

Don't get me started on the Firefox issue. As market share increases it becomes a much bigger target
to hackers and those looking to exploit security holes. If probably won't help that MS is now
working on an updated version of IE.

¤ The adoption of Linux will happen sooner than you think, in more places than
¤ you think.  There are things in the works right now that will make Linux the
¤ premier desktop of small and mid-sized businesses worldwide.  Add them to
¤ the governments making the switch, and you have yourself a little
¤ revolution.
¤

They way Linux has been hyped over the last several years I would have expected a significantly
higher adoption rate. Problem is there's literally no money to be made in this market in comparison
to the Windows market so quality applications lag behind. In addition, there's simply too many user
interfaces and variations for this OS so standardization becomes virtually impossible.

¤ >The cost to support
¤ > multiple platforms is typically a deterrent.
¤
¤ Again, you are right.
¤
¤ In the past, developing for different platforms has been costly.  This, for
¤ the most part, negated any potential gains from supporting Linux or MAC
¤ operating systems.
¤
¤ But, REALbasic makes this as easy as recompiling the software.  Just click
¤ and run on a different OS.  There is no additional development required.
¤ Just select the checkboxes of the platforms you want to distribute your app
¤ on and click "Build".
¤
¤ REALbasic builds your app for all of the platforms you have selected.
¤ Developing cross-platform desktop applications can't be any easier than
¤ that.

Unfortunately not all operating systems support the same level of features so there is almost always
a trade-off - another reason why companies spend little time developing their applications for
multiple platforms.


Paul
~~~~
Microsoft MVP (Visual Basic)

Show quote Hide quote Actually, they aren't playing catch-up to Classic VB at all.  From what I
understand, REALbasic has always been object oriented (something even VB6
didn't fully acheive).  They are trying to capitalize on a vacuum left by
Microsoft abandoning the "task oriented" developers by adding features that
make classic Visual Basic programmers feel more at home in the REALbasic
environment.  They are also following up with what Microsoft has proven to
be a winning formula with classic Visual Basic.  Those are just smart
business practices.

Show quoteHide quoteMe too.  But, I believe that I know why it hasn't.  There are 2 reasons....

1) The GPL.  The GPL is great for exchanging knowledge, but it sucks as a
business model.  You can't make money as an ISV if you give away your source
code to potential clients (who can just compile it and run it for free) or
to potential competitors (who will simply take your hard won innovations and
cut and psate them into your competitor's products).  In order to have a
solid foundation for software, there has to be proprietary code and a
pay-for-use model.  Anything else (although quite charming in a socialist
sort-of way) will fail.

2) Lack of a "task oriented" programming language in all distros.  The one
single thing that had the most impact in making Windows the dominant force
it is today was classic Visual Basic.  (Don't take my word for it though....
Check out Alan Cooper's web page here -
http://www.cooper.com/alan/father_of_vb.html - especially the last
sentence.)

    It is clear to Bill Gates that Visual Basic was a dominant force in
making Windows the success it is today.  But, why is that?

    IMHO, it is because small businesses could adopt Windows as a platform
and use classic Visual Basic to write business-specific applications without
having an MIS degree.  It made programmers out of almost anyone.  It
empowered people and businesses without burdening them with the task of also
becoming a professional programmer to write applications to accomplish their
personal and business goals.

    "Task oriented" programmers do not care to know how the IDE works "under
the covers".  They don't want to be bogged down with the details.  They just
want to be able to sit down and write a simple application to make their
lives easier.

    The typical "task oriented" developer does something other than
programing for a living. S/he may be a veterinarian, attorney, mail clerk,
student, housewife, stay-at-home dad, libraian, CEO, accountant........you
just name it.  They used Windows and VB because those 2 tools allowed them
to fill in the gaps that they see in their everyday jobs.  They only write
apps to make making a living easier.  They aren't "professional programmers"
and, frankly, they don't want to be.

    When small businesses saw the vlaue that Visual Basic added (by turning
a great deal of their current workers into "programmers") small business
adopted it in droves.  And, when the employees of those businesses saw how
easy it was to use, they adopted it for personal projects too.  And, when
programming shops saw Visual Basic taking off, they understood that it was
because of ease-of-use and they added to this ease-of-use by creating the
largest 3rd party component base for any program in history.

    Visual Basic is what made Windows great.  And, Linux distributors
haven't figured this out yet.  If they would just package something like
REALbasic with every Linux distro, they too could take advantage of this
proven model for success.  THAT'S when Linux will really start to
move....and not until then.

    Sure.....they have MONO.  But, Mono is not a "task oriented" RAD
environment.  Linux has always had a problem dumbing down enough for the
masses.  Linspire has made great strides in this area....but, without their
own Visual Basic, they will never be a real contender to the throne.

    This is the most puzzling thing to me about Microsoft's VB.Net
ambitions.  They threw away the most successful tag team in the world (the
classic Visual Basic RAD/"task oriented developer" toolset + Windows).  Why?

    I really do understand moving forward, and I completely agree with it.
But, not at the expense of losing the army of "Task oriented" developers
that depended on a high level, RAD intensive, drag and drop environment like
classic Visual Basic.

    Have you ever read a VB.Net book (epsecially by Microsoft)?  I have 54
of them.  They all go into great detail about the .Net framework, classes,
garbage collection, remoting, ad nausem.  DO THEY EVEN KNOW THEIR TARGET
AUDIENCE?

    They are doing nothing more than discouraging the "task oriented"
classic Visual Basic developer from moving on and adopting VB.Net.

    "Task oriented" developers don't care about what's "under the covers".
Why in the hell would you show these developers the internally written code
in a VB.Net application?  To confuse them?  If that was the goal -
CONGRATULATIONS!  You da man!

    With VB.Net 2005, Microsoft is getting closer to the olde classic Visual
Basic "task oriented" way of doing things.  I am actually impressed with
what I have seen of VB.Net 2005 so far.  But there is still a ways to go to
get it back to a tool that "task oriented" developers can feel comfortable
(i.e. not stupid or overwhelmed) with.

    And, my greatest issue is still the conversion of old Visual Basic 6
code.  I'll bet my company that if Microsoft were to make VB.Net 2005 truly
"click and upgrade" classic Visual Basic 6 code that ALL of the petition
issues would just go away.

Show quoteHide quoteI was only pointing out that people are not as adverse to change as you
might think.  They will change when they see (either real or perceived)
benefits of doing so.

Show quoteHide quoteWith REALbasic, this isn't a problem.

Show quoteHide quoteIn REALbasic, all core components work on all OSs. (Jon....correct me here
if I'm wrong please).

Jim Hubbard

Jim Hubbard wrote:
That is correct. There are very few things included that aren't
supported on all platforms -- such as the RegistryItem class (for the
Windows registry), OLE support, ActiveX support. The only things that
aren't supported on all platforms are the platform specific
technologies.

-Jon

¤ > ¤ You're right.  Those things are absent right now.  But, it is something
¤ > the
¤ > ¤ REALbasic team is working on.
¤ > ¤
¤ >
¤ > The problem is that they're trying to catch up to Classic Visual Basic.
¤ > They can't touch .NET.
¤
¤ Actually, they aren't playing catch-up to Classic VB at all.  From what I
¤ understand, REALbasic has always been object oriented (something even VB6
¤ didn't fully acheive).  They are trying to capitalize on a vacuum left by
¤ Microsoft abandoning the "task oriented" developers by adding features that
¤ make classic Visual Basic programmers feel more at home in the REALbasic
¤ environment.  They are also following up with what Microsoft has proven to
¤ be a winning formula with classic Visual Basic.  Those are just smart
¤ business practices.
¤

Hmmm...I don't think you compared the features of Classic to REALBasic very closely. RealBasic may
have full OO support but you can't create any ActiveX components.

Talk to some of the other Classic VB MVPs to see if they believe REALBasic measures up to Classic.

<snip>

¤     With VB.Net 2005, Microsoft is getting closer to the olde classic Visual
¤ Basic "task oriented" way of doing things.  I am actually impressed with
¤ what I have seen of VB.Net 2005 so far.  But there is still a ways to go to
¤ get it back to a tool that "task oriented" developers can feel comfortable
¤ (i.e. not stupid or overwhelmed) with.
¤
¤     And, my greatest issue is still the conversion of old Visual Basic 6
¤ code.  I'll bet my company that if Microsoft were to make VB.Net 2005 truly
¤ "click and upgrade" classic Visual Basic 6 code that ALL of the petition
¤ issues would just go away.
¤

Pipe dream. Microsoft can't simply wave a magic wand in order to make all code upgrade able. Some
features are gone, some have been changed according to requirements of the .NET framework. They may
be able to bring back some features but those that have changed will not be reverted.

¤ > Don't get me started on the Firefox issue. As market share increases it
¤ > becomes a much bigger target
¤ > to hackers and those looking to exploit security holes. If probably won't
¤ > help that MS is now
¤ > working on an updated version of IE.
¤
¤ I was only pointing out that people are not as adverse to change as you
¤ might think.  They will change when they see (either real or perceived)
¤ benefits of doing so.
¤

You mean like, "the grass is always greener on the other side"?

¤ > ¤ In the past, developing for different platforms has been costly.  This,
¤ > for
¤ > ¤ the most part, negated any potential gains from supporting Linux or MAC
¤ > ¤ operating systems.
¤ > ¤
¤ > ¤ But, REALbasic makes this as easy as recompiling the software.  Just
¤ > click
¤ > ¤ and run on a different OS.  There is no additional development required.
¤ > ¤ Just select the checkboxes of the platforms you want to distribute your
¤ > app
¤ > ¤ on and click "Build".
¤ > ¤
¤ > ¤ REALbasic builds your app for all of the platforms you have selected.
¤ > ¤ Developing cross-platform desktop applications can't be any easier than
¤ > ¤ that.
¤ >
¤ > Unfortunately not all operating systems support the same level of features
¤ > so there is almost always
¤ > a trade-off - another reason why companies spend little time developing
¤ > their applications for
¤ > multiple platforms.
¤
¤ In REALbasic, all core components work on all OSs. (Jon....correct me here
¤ if I'm wrong please).

If developers only used core language components that might be true. But how many actually develop
applications that don't implement extensions of the operating system? What about database
components? What about third-party controls? What about the operating system APIs?


Paul
~~~~
Microsoft MVP (Visual Basic)

Show quote Hide quote If you'll recall.....I said, "Now, REALbasic still has some growing to do.
Don't expect it to be anything
except REALbasic."

The syntax is similar to VB, the interface is similar to VB and the IDE is a
basic drag-and-drop component-oriented IDE.  All of these things will make
REALbasic feeal very familiar to Visual Basic programmers.  But, REALbasic
is REALbasic.....not Visual Basic.

Show quoteHide quoteNo.  But they couldwave a programming team and make it so.

It's a choice.  Microsoft is choosing to abandon classic Visual Basic 6, the
mind-boggling amount of code written in classic Visual Basic and the users
that trusted Microsoft enough to use it.  It's a very bad choice....but a
choice nonetheless.

The requirements of the .Net framework have nothing to do with allowing
unmanaged classic Visual Basic applications to be supported from the Visual
Studio .Net IDE.  Never have I seen any Microsoft employee give any valid
technical reason that classic Visual Basic code could not be run as
"unmanaged code".

Remember that classic Visual Basic uses a runtime.  This runtime contains
the code that actually makes a classic Visual Basic program work.  So, why
not include the runtime code to run unmanaged classic Visual Basic code?

All I keep hearing is that there are some sort of technical reasons that
this can't be done......but nobody (not even you) can cite even one of those
phantom reasons.

I suspect that there are not real technical reasons behind the decision.
The continual insistance that there are such reasons, without producing even
one of them, leads me to believe this is nothing more than a propaganda
technique in which Microsoft says something often enough and people begin to
take it as fact.....when, in fact, there are no facts to support the
argument at all.

If you know of any hard facts as to why 1) the Visual Studio .Net IDE could
not support classic Visual Basic applications or 2) and hard facts as to why
the small code contained in the classic Visual Basic runtime could not be
integrated to run unmanaged Visual Basic code from inside an intermediate
language like VB.Net....please shaer it with us.

I agree.  Microsoft is not likely to change their stance, no matter how
wrong it may be for their customers.  This is why we need a valid
alternative to Windows, .Net and the forced marches of Microsoft.

Show quoteHide quoteSometimes the grass really is greener.  (Not that there won;t be the
occassional "cow patty"....)

Show quoteHide quoteI'm new to REALbasic.....so, I wouldn't know at this time.

A simple database is built in.

With REALbasic 2005, it is easier to write 3rd party controls using
REALbasic.  That makes them essentially core components.

Good question!  This one had me worried, until I found this......

#If TargetBoolean [Then]
     //OS specific code

[#Else]

     //Other OS-specific code

[#ElseIf TargetBoolean]

     //Other OS-specific code for this target platform

#Endif



TargetBoolean can be TargetMacOS, TargetWin32 or TargetLinux.  This way you
can take advantage of OS-specific APIs without screwing up the app on other
OSs.

Example

The following example assigns values to the (user-defined) Separator
property of the App class in its Open event handler. It will be used to
specify full pathnames that are correct on both Macintosh, Linux, and
Windows.

#If TargetMacOS Separator=":" #ElseIf TargetWin32 Separator="" #ElseIf
TargetLinux Separator="/" #Endif

Jim Hubbard

¤
¤ > wrote:

¤ > Hmmm...I don't think you compared the features of Classic to REALBasic
¤ > very closely. RealBasic may
¤ > have full OO support but you can't create any ActiveX components.
¤ >
¤ > Talk to some of the other Classic VB MVPs to see if they believe REALBasic
¤ > measures up to Classic.
¤
¤ If you'll recall.....I said, "Now, REALbasic still has some growing to do.
¤ Don't expect it to be anything
¤ except REALbasic."
¤
¤ The syntax is similar to VB, the interface is similar to VB and the IDE is a
¤ basic drag-and-drop component-oriented IDE.  All of these things will make
¤ REALbasic feeal very familiar to Visual Basic programmers.  But, REALbasic
¤ is REALbasic.....not Visual Basic.
¤

Certainly not with respect to features, which will significantly impair code migration.


¤ > ¤     With VB.Net 2005, Microsoft is getting closer to the olde classic
¤ > Visual
¤ > ¤ Basic "task oriented" way of doing things.  I am actually impressed with
¤ > ¤ what I have seen of VB.Net 2005 so far.  But there is still a ways to go
¤ > to
¤ > ¤ get it back to a tool that "task oriented" developers can feel
¤ > comfortable
¤ > ¤ (i.e. not stupid or overwhelmed) with.
¤ > ¤
¤ > ¤     And, my greatest issue is still the conversion of old Visual Basic 6
¤ > ¤ code.  I'll bet my company that if Microsoft were to make VB.Net 2005
¤ > truly
¤ > ¤ "click and upgrade" classic Visual Basic 6 code that ALL of the petition
¤ > ¤ issues would just go away.
¤ > ¤
¤ >
¤ > Pipe dream. Microsoft can't simply wave a magic wand in order to make all
¤ > code upgrade able.
¤
¤ No.  But they couldwave a programming team and make it so.
¤

Based upon my knowledge of both versions I'm going to have to disagree.

¤ It's a choice.  Microsoft is choosing to abandon classic Visual Basic 6, the
¤ mind-boggling amount of code written in classic Visual Basic and the users
¤ that trusted Microsoft enough to use it.  It's a very bad choice....but a
¤ choice nonetheless.
¤

Previous versions of software are ultimately abandoned. While we can debate the ease or difficulty
of the migration as a result of the changes, it doesn't really change the process.

While there are those who believe that Visual Basic.NET is a completely different language, and
product, in order to justify the continued development of Visual Basic 6.0, I'm not buying it one
bit.

¤ >Some
¤ > features are gone, some have been changed according to requirements of the
¤ > .NET framework.
¤
¤ The requirements of the .Net framework have nothing to do with allowing
¤ unmanaged classic Visual Basic applications to be supported from the Visual
¤ Studio .Net IDE.  Never have I seen any Microsoft employee give any valid
¤ technical reason that classic Visual Basic code could not be run as
¤ "unmanaged code".
¤

How do you co mingle managed and unmanaged code in the same environment? The .NET and Visual Basic
IDE environments are fundamentally different with respect to how code is compiled, debugged and
executed. In any event, what would be the point of bringing Classic Visual Basic into the .NET
environment if standard (not COM) based unmanaged code cannot interoperate with managed code?

¤ Remember that classic Visual Basic uses a runtime.  This runtime contains
¤ the code that actually makes a classic Visual Basic program work.  So, why
¤ not include the runtime code to run unmanaged classic Visual Basic code?
¤
¤ All I keep hearing is that there are some sort of technical reasons that
¤ this can't be done......but nobody (not even you) can cite even one of those
¤ phantom reasons.
¤

Well if I remember correctly Classic Visual Basic applications actually execute from within the
process of the IDE during development. .NET applications do not. Are you saying that you want to
modify the .NET IDE to provide for both a managed and unmanaged code environment?

¤ I suspect that there are not real technical reasons behind the decision.
¤ The continual insistance that there are such reasons, without producing even
¤ one of them, leads me to believe this is nothing more than a propaganda
¤ technique in which Microsoft says something often enough and people begin to
¤ take it as fact.....when, in fact, there are no facts to support the
¤ argument at all.
¤

I have yet to hear any cogent explanations as to how it can be accomplished within a reasonable time
frame.

¤ If you know of any hard facts as to why 1) the Visual Studio .Net IDE could
¤ not support classic Visual Basic applications or 2) and hard facts as to why
¤ the small code contained in the classic Visual Basic runtime could not be
¤ integrated to run unmanaged Visual Basic code from inside an intermediate
¤ language like VB.Net....please shaer it with us.

Yes, because it would take several years to implement and couldn't be justified from a business
perspective.


¤ >They may
¤ > be able to bring back some features but those that have changed will not
¤ > be reverted.
¤
¤ I agree.  Microsoft is not likely to change their stance, no matter how
¤ wrong it may be for their customers.  This is why we need a valid
¤ alternative to Windows, .Net and the forced marches of Microsoft.
¤

There are many customers who support Microsoft's stance and do not believe it to be wrong.

¤ >
¤ > ¤ > Don't get me started on the Firefox issue. As market share increases
¤ > it
¤ > ¤ > becomes a much bigger target
¤ > ¤ > to hackers and those looking to exploit security holes. If probably
¤ > won't
¤ > ¤ > help that MS is now
¤ > ¤ > working on an updated version of IE.
¤ > ¤
¤ > ¤ I was only pointing out that people are not as adverse to change as you
¤ > ¤ might think.  They will change when they see (either real or perceived)
¤ > ¤ benefits of doing so.
¤ > ¤
¤ >
¤ > You mean like, "the grass is always greener on the other side"?
¤
¤ Sometimes the grass really is greener.  (Not that there won;t be the
¤ occassional "cow patty"....)
¤
¤ >
¤ > ¤ > ¤ In the past, developing for different platforms has been costly.
¤ > This,
¤ > ¤ > for
¤ > ¤ > ¤ the most part, negated any potential gains from supporting Linux or
¤ > MAC
¤ > ¤ > ¤ operating systems.
¤ > ¤ > ¤
¤ > ¤ > ¤ But, REALbasic makes this as easy as recompiling the software.  Just
¤ > ¤ > click
¤ > ¤ > ¤ and run on a different OS.  There is no additional development
¤ > required.
¤ > ¤ > ¤ Just select the checkboxes of the platforms you want to distribute
¤ > your
¤ > ¤ > app
¤ > ¤ > ¤ on and click "Build".
¤ > ¤ > ¤
¤ > ¤ > ¤ REALbasic builds your app for all of the platforms you have
¤ > selected.
¤ > ¤ > ¤ Developing cross-platform desktop applications can't be any easier
¤ > than
¤ > ¤ > ¤ that.
¤ > ¤ >
¤ > ¤ > Unfortunately not all operating systems support the same level of
¤ > features
¤ > ¤ > so there is almost always
¤ > ¤ > a trade-off - another reason why companies spend little time
¤ > developing
¤ > ¤ > their applications for
¤ > ¤ > multiple platforms.
¤ > ¤
¤ > ¤ In REALbasic, all core components work on all OSs. (Jon....correct me
¤ > here
¤ > ¤ if I'm wrong please).
¤ >
¤ > If developers only used core language components that might be true. But
¤ > how many actually develop
¤ > applications that don't implement extensions of the operating system?
¤
¤ I'm new to REALbasic.....so, I wouldn't know at this time.
¤

The issue isn't specific to REALBasic. It's simply a matter of fact.

¤ > What about database
¤ > components?
¤
¤ A simple database is built in.
¤

Well lets say I have an application that uses an Access database. How do I get this to work on
multiple platforms?

¤ > What about third-party controls?
¤
¤ With REALbasic 2005, it is easier to write 3rd party controls using
¤ REALbasic.  That makes them essentially core components.
¤

I want to use the components (ActiveX controls) I've already invested in. How do I resolve this
issue? Are you saying I have to rewrite these in REALBasic?

¤ > What about the operating system APIs?
¤
¤ Good question!  This one had me worried, until I found this......
¤
¤ #If TargetBoolean [Then]
¤      //OS specific code
¤
¤ [#Else]
¤
¤      //Other OS-specific code
¤
¤ [#ElseIf TargetBoolean]
¤
¤      //Other OS-specific code for this target platform
¤
¤ #Endif

But what if there is no equivalent functionality in the other OS? Am I SOL?


Paul
~~~~
Microsoft MVP (Visual Basic)

Show quote Hide quote REALbasic still has some growing to do.  Fortunately, it has seen a great
spike in downloads and usage lately....with more 3rd party component vendors
signing on.

It seems I'm not the only one that likes to be able to write OS independent
applications.

Show quoteHide quoteAGAIN!  I PLEAD WITH YOU TO SHARE YOUR INTIMATE KNOWLEDGE OF VISUAL BASIC
THAT MAKES IT TECHNICALLY NOT FEASABLE TO SUPPORT CLASSIC VISUAL BASIC AS
UNMANAGED CODE IN THE SAME WAY THAT UNMANAGED C++ CODE IS SUPPORTED.

Show quoteHide quoteReally?  So, you can run unaltered VB6 code from large, enterprise
applications in VB.Net?  Please share......we'd all like to do that.

Show quoteHide quoteThe same way Microsoft did it for C++.

The same goes for C++.  This is a BS argument.

I think (and feel free to correct me if I'm wrong) that there's a little
thing called interop that allows just such things to take place in VB.Net -
it just wasn't taken far enough.  They wanted to spend more time on a
language adopted by MILLIONS FEWER programmers - simply because the internal
programmers were calling the shots.

This is a classic example of the lunatics running the asylum.

Show quoteHide quoteYes.  Just like Microsoft did for C++.

Show quoteHide quoteAnd, I have yet to hear any technical reason that prevents the inclusion of
unmanaged Visual Basic code.....JUST LIKE MICROSOFT DID WITH C++.

You are beginning to bore me with this unsubstantiated assumption of the
phantom roadblocks that clearly do not exist.  Put up....or move on.

Show quoteHide quoteOn what do you base these assumptions?  It didn't take that long, or cost
too much, to do it for C++.

They can still do so in REALbasic.  However, if the code is core to the
program (as opposed to a "nice feature" that can be added for a specific OS
without adversely affecting the core functionality of the project) they will
confine that application to the specific OS for which they write the hooks.

Completely understandable.  This is the same reason we want to keep classic
VB viable - to preserve our investments.

I believe that ActiveX controls CAN be used from REALbasic.  You'd have to
ask them if you need more specifics.
Show quoteHide quoteWhat do you think?  They are not replacing the operating systems.

If a car doesn't have wings it can't fly.

Jim Hubbard

¤ > ¤ >
¤ > ¤ > Pipe dream. Microsoft can't simply wave a magic wand in order to make
¤ > all
¤ > ¤ > code upgrade able.
¤ > ¤
¤ > ¤ No.  But they couldwave a programming team and make it so.
¤ > ¤
¤ >
¤ > Based upon my knowledge of both versions I'm going to have to disagree.
¤
¤ AGAIN!  I PLEAD WITH YOU TO SHARE YOUR INTIMATE KNOWLEDGE OF VISUAL BASIC
¤ THAT MAKES IT TECHNICALLY NOT FEASABLE TO SUPPORT CLASSIC VISUAL BASIC AS
¤ UNMANAGED CODE IN THE SAME WAY THAT UNMANAGED C++ CODE IS SUPPORTED.

Doesn't work that way my friend. The environments for Classic Visual Basic and C++ are quite a bit
different. Besides C++ uses managed extensions to inter operate with .NET. Do you really believe
that managed extensions for Classic Visual Basic is even the slightest bit feasible considering the
baggage it caries along with it?

In any event you're claiming this can be done feasibly but have offered little if any technical
information to back your statement.

¤ > ¤ It's a choice.  Microsoft is choosing to abandon classic Visual Basic 6,
¤ > the
¤ > ¤ mind-boggling amount of code written in classic Visual Basic and the
¤ > users
¤ > ¤ that trusted Microsoft enough to use it.  It's a very bad choice....but
¤ > a
¤ > ¤ choice nonetheless.
¤ > ¤
¤ >
¤ > Previous versions of software are ultimately abandoned. While we can
¤ > debate the ease or difficulty
¤ > of the migration as a result of the changes, it doesn't really change the
¤ > process.
¤ >
¤ > While there are those who believe that Visual Basic.NET is a completely
¤ > different language, and
¤ > product, in order to justify the continued development of Visual Basic
¤ > 6.0, I'm not buying it one
¤ > bit.
¤
¤ Really?  So, you can run unaltered VB6 code from large, enterprise
¤ applications in VB.Net?  Please share......we'd all like to do that.

Who said that? Not me. Do you believe Visual Basic.NET is a completely different language? If so,
then explain why it shares a very high percentage of the same language components and syntax with
Classic Visual Basic?


¤ > ¤ >Some
¤ > ¤ > features are gone, some have been changed according to requirements of
¤ > the
¤ > ¤ > .NET framework.
¤ > ¤
¤ > ¤ The requirements of the .Net framework have nothing to do with allowing
¤ > ¤ unmanaged classic Visual Basic applications to be supported from the
¤ > Visual
¤ > ¤ Studio .Net IDE.  Never have I seen any Microsoft employee give any
¤ > valid
¤ > ¤ technical reason that classic Visual Basic code could not be run as
¤ > ¤ "unmanaged code".
¤ > ¤
¤ >
¤ > How do you co mingle managed and unmanaged code in the same environment?
¤
¤ The same way Microsoft did it for C++.
¤

What is it about the C++ and Visual Basic 6.0 development environments that indicate to you that
they operate under the same implementation?


¤ >The .NET and Visual Basic
¤ > IDE environments are fundamentally different with respect to how code is
¤ > compiled, debugged and
¤ > executed.
¤
¤ The same goes for C++.  This is a BS argument.
¤

Oh so it's not true. Please share your wealth of technical knowledge because so far all you're
saying is, "it can be done", "they did it with C++ so they can do it with VB", etc. etc. etc.

¤ > In any event, what would be the point of bringing Classic Visual Basic
¤ > into the .NET
¤ > environment if standard (not COM) based unmanaged code cannot interoperate
¤ > with managed code?
¤
¤ I think (and feel free to correct me if I'm wrong) that there's a little
¤ thing called interop that allows just such things to take place in VB.Net -
¤ it just wasn't taken far enough.  They wanted to spend more time on a
¤ language adopted by MILLIONS FEWER programmers - simply because the internal
¤ programmers were calling the shots.
¤
¤ This is a classic example of the lunatics running the asylum.
¤

As I mentioned it's COM interop (RCW or CCW). Microsoft would have to devise some method other than
an interop assembly in order to generate the dynamic bridge between managed and unmanaged code.

¤ >
¤ > ¤ Remember that classic Visual Basic uses a runtime.  This runtime
¤ > contains
¤ > ¤ the code that actually makes a classic Visual Basic program work.  So,
¤ > why
¤ > ¤ not include the runtime code to run unmanaged classic Visual Basic code?
¤ > ¤
¤ > ¤ All I keep hearing is that there are some sort of technical reasons that
¤ > ¤ this can't be done......but nobody (not even you) can cite even one of
¤ > those
¤ > ¤ phantom reasons.
¤ > ¤
¤ >
¤ > Well if I remember correctly Classic Visual Basic applications actually
¤ > execute from within the
¤ > process of the IDE during development. .NET applications do not. Are you
¤ > saying that you want to
¤ > modify the .NET IDE to provide for both a managed and unmanaged code
¤ > environment?
¤
¤ Yes.  Just like Microsoft did for C++.
¤

How? They're not the same.

¤ > ¤ I suspect that there are not real technical reasons behind the decision.
¤ > ¤ The continual insistance that there are such reasons, without producing
¤ > even
¤ > ¤ one of them, leads me to believe this is nothing more than a propaganda
¤ > ¤ technique in which Microsoft says something often enough and people
¤ > begin to
¤ > ¤ take it as fact.....when, in fact, there are no facts to support the
¤ > ¤ argument at all.
¤ > ¤
¤ >
¤ > I have yet to hear any cogent explanations as to how it can be
¤ > accomplished within a reasonable time
¤ > frame.
¤
¤ And, I have yet to hear any technical reason that prevents the inclusion of
¤ unmanaged Visual Basic code.....JUST LIKE MICROSOFT DID WITH C++.
¤
¤ You are beginning to bore me with this unsubstantiated assumption of the
¤ phantom roadblocks that clearly do not exist.  Put up....or move on.
¤

That's my line and your repeated assertions are an exercise in futility. If you have no technical
evidence as to how it can be done within a reasonable time frame then your claim that it can is
baseless. It's not incumbent upon me to disprove something that has yet to be proven or
demonstrated. That's nonsense. You're not the first one to assume facts not in evidence and then
demand that I disprove them - but it was a nice try. ;-)

I have no reason to accept your claims at their face value.

¤ >
¤ > ¤ If you know of any hard facts as to why 1) the Visual Studio .Net IDE
¤ > could
¤ > ¤ not support classic Visual Basic applications or 2) and hard facts as to
¤ > why
¤ > ¤ the small code contained in the classic Visual Basic runtime could not
¤ > be
¤ > ¤ integrated to run unmanaged Visual Basic code from inside an
¤ > intermediate
¤ > ¤ language like VB.Net....please shaer it with us.
¤ >
¤ > Yes, because it would take several years to implement and couldn't be
¤ > justified from a business
¤ > perspective.
¤
¤ On what do you base these assumptions?  It didn't take that long, or cost
¤ too much, to do it for C++.
¤

Well I guess if C++ and Visual Basic 6.0 were the same you would have a winner. For the last time,
they're not and I don't know why you believe that they would require the same implementation under
..NET.

¤ > ¤ > If developers only used core language components that might be true.
¤ > But
¤ > ¤ > how many actually develop
¤ > ¤ > applications that don't implement extensions of the operating system?
¤ > ¤
¤ > ¤ I'm new to REALbasic.....so, I wouldn't know at this time.
¤ > ¤
¤ >
¤ > The issue isn't specific to REALBasic. It's simply a matter of fact.
¤
¤ They can still do so in REALbasic.  However, if the code is core to the
¤ program (as opposed to a "nice feature" that can be added for a specific OS
¤ without adversely affecting the core functionality of the project) they will
¤ confine that application to the specific OS for which they write the hooks.
¤

Core functionality often involves operating system specific functionality. That's why cross-platform
development is often problematic. It has nothing to do with the language or development environment
you use - it's an issue with the concept with respect to operating system implementations.

¤ > I want to use the components (ActiveX controls) I've already invested in.
¤ > How do I resolve this
¤ > issue? Are you saying I have to rewrite these in REALBasic?
¤
¤ Completely understandable.  This is the same reason we want to keep classic
¤ VB viable - to preserve our investments.
¤
¤ I believe that ActiveX controls CAN be used from REALbasic.  You'd have to
¤ ask them if you need more specifics.
¤ >
¤ > ¤ > What about the operating system APIs?
¤ > ¤
¤ > ¤ Good question!  This one had me worried, until I found this......
¤ > ¤
¤ > ¤ #If TargetBoolean [Then]
¤ > ¤      //OS specific code
¤ > ¤
¤ > ¤ [#Else]
¤ > ¤
¤ > ¤      //Other OS-specific code
¤ > ¤
¤ > ¤ [#ElseIf TargetBoolean]
¤ > ¤
¤ > ¤      //Other OS-specific code for this target platform
¤ > ¤
¤ > ¤ #Endif
¤ >
¤ > But what if there is no equivalent functionality in the other OS? Am I
¤ > SOL?
¤
¤ What do you think?  They are not replacing the operating systems.
¤
¤ If a car doesn't have wings it can't fly.

Hmm...OK so much for the cross-platform implementation feature. ;-)


Paul
~~~~
Microsoft MVP (Visual Basic)

Found their own comparisons to Visual Basic, C++ and Java at
http://www.realsoftware.com/realbasic/compare/.

In article <h6ad511htafvuuf77qfjsgvfeuo90bo***@4ax.com>, Paul Clement wrote:
<snip>

Do you read the news much?  Linux is being adopted... Not so much on the
desktop (though that is happening) - but on the server side it is
growing pretty darn fast.

I agree that Firefox is not as big a target at the moment...  But, you
need to look at the fix rate as well:

    http://www.tigertools.net/board/?topic=topic8&msg=7567
    According to Brussels-based ScanIT, users of Microsoft's Internet
    Explorer (IE) were "unsafe" 98 percent of the time during 2004, while
    Mozilla users -- which would include those using Mozilla and Firefox
    -- were "unsafe" only 15 percent of last year.

The fact is that Firefox IS more secure, not to mention it is just a
better browser.  I have high hopes for IE7, but right now Firefox just
plain kicks IE's butt.

Tell that to Novell and IBM.  Both major Linux players.

Some do, some don't.

To be honest, I actually like having the choices.  But, this makes no
sense really.  It is quite simple for a distro maker to standardize on a
particluar interface, if they so choose.

On Wed, 13 Apr 2005 13:00:37 -0700, Tom Shelton <t**@YOUKNOWTHEDRILLmtogden.com>
wrote:


¤ <snip>
¤
¤ > ¤ While still far behind Windows, the demand for Linux is growing by leaps and
¤ > ¤ bounds....if I may....
¤ > ¤
¤ >
¤ > Well that's what some folks having been saying for the last five years. You would have thought by
¤ > now that Linux would have passed up Windows by now. ;-)
¤ > 
¤
¤ Do you read the news much?  Linux is being adopted... Not so much on the
¤ desktop (though that is happening) - but on the server side it is
¤ growing pretty darn fast.
¤

Yes, it's being adopted by Unix users. Windows has typically lagged behind in
the server market but that is changing as well since it's continued to gain
market share in that venue.

I'm afraid the slaughter rule still applies on the desktop.

¤ > ¤ It's like the adoption of Firefox in place of IE.  Firefox is making great
¤ > ¤ strides in the browser market, with no signs of stalling.  People will adopt
¤ > ¤ the best technology for their enterprise, whether that is MAC, Windows or
¤ > ¤ Linux.
¤ > ¤
¤ >
¤ > Don't get me started on the Firefox issue. As market share increases it becomes a much bigger target
¤ > to hackers and those looking to exploit security holes. If probably won't help that MS is now
¤ > working on an updated version of IE.
¤ > 
¤
¤ I agree that Firefox is not as big a target at the moment...  But, you
¤ need to look at the fix rate as well:
¤
¤     http://www.tigertools.net/board/?topic=topic8&msg=7567
¤     According to Brussels-based ScanIT, users of Microsoft's Internet
¤     Explorer (IE) were "unsafe" 98 percent of the time during 2004, while
¤     Mozilla users -- which would include those using Mozilla and Firefox
¤     -- were "unsafe" only 15 percent of last year.
¤
¤ The fact is that Firefox IS more secure, not to mention it is just a
¤ better browser.  I have high hopes for IE7, but right now Firefox just
¤ plain kicks IE's butt.
¤

We won't know how secure FireFox is until it becomes a much bigger target. I'm
sure we all thought IE was secure at one point, probably when it was overtaking
Netscape. But the fact the FireFox does not support some features targeted as
security risks you could say it's inherently more secure in that sense.

Personally I've found some compatibility issues with FireFox that annoy me. In
addition, it doesn't have the rendering smarts that IE does. If try FireFox
periodically but I always end up going back to IE when I hit a usability road
block.

¤ > ¤ The adoption of Linux will happen sooner than you think, in more places than
¤ > ¤ you think.  There are things in the works right now that will make Linux the
¤ > ¤ premier desktop of small and mid-sized businesses worldwide.  Add them to
¤ > ¤ the governments making the switch, and you have yourself a little
¤ > ¤ revolution.
¤ > ¤
¤ >
¤ > They way Linux has been hyped over the last several years I would have expected a significantly
¤ > higher adoption rate. Problem is there's literally no money to be made in this market in comparison
¤
¤ Tell that to Novell and IBM.  Both major Linux players.
¤

Novell has been on life support for quite a while now. IBM is getting out of the
PC hardware business. They also both have a grudge against Microsoft.

¤ > to the Windows market so quality applications lag behind.
¤
¤ Some do, some don't.
¤

Well they either do or don't. ;-)  It's typically true, although you can find
some good Linux apps that are competitive with Windows apps.

¤ > In addition, there's simply too many user
¤ > interfaces and variations for this OS so standardization becomes virtually impossible.
¤ > 
¤
¤ To be honest, I actually like having the choices.  But, this makes no
¤ sense really.  It is quite simple for a distro maker to standardize on a
¤ particluar interface, if they so choose.

Nothing wrong with having choices, but the Linux market is over saturated so
there never is a settlement in the Linux community on a distro, which makes it
difficult to establish a standard UI.

Plus the vendors seem to come and go. That doesn't speak highly of the support
and stability of the product.


Paul
~~~~
Microsoft MVP (Visual Basic)

In article <u02t511fcbapr17rd05igsdvb3j81ad***@4ax.com>,
Paul Clement  <UseAdddressAtEndofMess***@swspectrum.com> wrote:
    ...
    ...

Umm, no.  I can't think of anyone I know knowledgable about security
that thought that IE was secure when it started.  Even quick and dirty
analyses showed a lot of holes.

It just took a few years for the attackers to find them.

Craig

On Thu, 14 Apr 2005 15:53:39 -0000, Craig A. Finseth <n***@finseth.com> wrote:

¤ In article <u02t511fcbapr17rd05igsdvb3j81ad***@4ax.com>,
¤ Paul Clement  <UseAdddressAtEndofMess***@swspectrum.com> wrote:
¤     ...
¤ >We won't know how secure FireFox is until it becomes a much bigger target. I'm
¤ >sure we all thought IE was secure at one point, probably when it was overtaking
¤ >Netscape. But the fact the FireFox does not support some features targeted as
¤ >security risks you could say it's inherently more secure in that sense.
¤     ...
¤
¤ Umm, no.  I can't think of anyone I know knowledgable about security
¤ that thought that IE was secure when it started.  Even quick and dirty
¤ analyses showed a lot of holes.
¤
¤ It just took a few years for the attackers to find them.

Well *we* (in the general sense) are not all security experts. ;-)

In any event, apparently it wasn't a barrier to widespread adoption. That assumes that either people
didn't really know or didn't really care (or some of both).

As I said, we really won't know for a while whether FireFox has similar security holes. That is,
until it's usage is comparable to IE.


Paul
~~~~
Microsoft MVP (Visual Basic)

In article <q9ev515lrbdsujdmh4k0sugjionoc3n***@4ax.com>,
Paul Clement  <UseAdddressAtEndofMess***@swspectrum.com> wrote:
    ...
Not a problem.  But at least listen when the people who _are_ experts
are saying something.

Agreed.  At the initial launch, people were more interested in fancy
features than security.  This is changing, and peoples' choices are
changing as a result.

Of course, marketing also comes into play (:-).

No, we know right now that it doesn't.  (See my previous comment about
listening.)

I'm overgeneralizing a little here, but...

The problems with IE are due to the feature set and business
requirements.  In a word, they're features.

Firefox has a different feature set that is not built around requiring
security holes in order to run.

Both products have bugs.  These bugs will range from minor to severe
and will be found and fixed.  (As an aside, you can't just compare
bug/patch counts: you need to look closely at the exposure resulting
from each bug/not installing the patch, and take into account what it
exposes and the difficulty of exercising it.)  However with Firefox,
you're putting tape over pinprick holes in a sheet of plywood.  With
IE, you're putting tape over holes in a window screen.  There is a
difference.

Consider the comparison between a normal car[*] and a convertible.
Sure, convertibles are fun to drive (at least in nice weather), but
I'd think a lot longer before keeping anything important in one.
After all, no matter how good I make the locks, someone can get in by
ripping the top open.  With a normal car, you have to at least break a
window: a considerably more difficult and attention-getting entry method.

[*] Around here, convertibles are not normal.  Maybe if I lived in LA...

Craig

Craigh,


Should you not  mention that it is for somebody who want to create a virus
or whatever  more interesting to do that for IE.

Why

In the first place because you can hit a much wider public.

In the second place you can hit Microsoft.

When Microsoft started it were the so called professionals who told that
Microsoft was only a window dresser (Literally) while the large public was
fond of their products.

Now partially the last is changed. Most professionals are now are very fond
with Microsoft products and the large public stays with that.

However a part of those seems to see Microsoft as an enormous danger that
has to be frighten.

I cannot deny that I am as well sometimes afraid about the power Microsoft
has. However, I can as well not tell that I have ever seen that they have
used it in a wrong way.

To say it in other words, it is more the weakness from the competitors from
Microsoft that makes Microsoft big. You can Microsoft not blame for that and
use all kinds of viruses to fight them, that is the same as terrorism in my
opinion.

A better way would be in my opinion to make a better product. And a good
product needs no debate. It will be used.

Just my thought

Cor

In article <uH8q6DeQFHA.4***@tk2msftngp13.phx.gbl>, Cor Ligthert wrote:
Show quoteHide quote<snip>

And that is why Firefox is taking market share from IE.  It is a better
product.  At least for now.  I will re-evaluate when I can get my hands
on IE7.

Tom,

Did I disagree that, confirm my reply will the future show that, even when
it means that Microsoft changes their product.

One of the things you can in my opinion not say from Microsoft. That is that
they have a misplaced feeling of superiority as in the way we see it often
in this business. When the customer wants something else they change it.

Cor

In article <q9ev515lrbdsujdmh4k0sugjionoc3n***@4ax.com>,
Paul Clement  <UseAdddressAtEndofMess***@swspectrum.com> wrote:
    ...
Not a problem.  But at least listen when the people who _are_ experts
are saying something.

Agreed.  At the initial launch, people were more interested in fancy
features than security.  This is changing, and peoples' choices are
changing as a result.

Of course, marketing also comes into play (:-).

No, we know right now that it doesn't.  (See my previous comment about
listening.)

I'm overgeneralizing a little here, but...

The problems with IE are due to the feature set and business
requirements.  In a word, they're features.

Firefox has a different feature set that is not built around requiring
security holes in order to run.

Both products have bugs.  These bugs will range from minor to severe
and will be found and fixed.  (As an aside, you can't just compare
bug/patch counts: you need to look closely at the exposure resulting
from each bug/not installing the patch, and take into account what it
exposes and the difficulty of exercising it.)  However with Firefox,
you're putting tape over pinprick holes in a sheet of plywood.  With
IE, you're putting tape over holes in a window screen.  There is a
difference.

Consider the comparison between a normal car[*] and a convertible.
Sure, convertibles are fun to drive (at least in nice weather), but
I'd think a lot longer before keeping anything important in one.
After all, no matter how good I make the locks, someone can get in by
ripping the top open.  With a normal car, you have to at least break a
window: a considerably more difficult and attention-getting entry method.

[*] Around here, convertibles are not normal.  Maybe if I lived in LA...

Craig

Jim Hubbard wrote:
Whoa, Jim... you apparently don't use REALbasic a lot!

After a year porting a large application, I can tell you that it isn't
that simple for platforms -- and I disagree with a lot of what you imply
about RB. I use the tool a lot and just spent a few hours today dealing
with some "issues" relating to RB and how well it does/doesn't play with
other devices and software.

If you care at all about GUI guidelines, you have to create windows that
reflect the platforms. Users come to expect certain behaviors on each.
Even "OK" and "Cancel" are in a different order on the Mac than the
Windows platform. Users do notice, so you have to spend time creating
custom classes or code that changes things.

RB supports different controls on different platforms. Want a toolbar?
Better be using a Mac.

The EditField renders improperly on Windows -- Real has yet to deal with
the fact Windows assumes 96px vs 72px on the Mac. As a result, 12-point
text is actually 10-point on the PC. Slick, guys, really slick.  It
means you have to do your own gymnastics to get this right. (Read the RB
NUG mailing list archives.)

You'll need to use a fair number of plug-ins, in my experience, to come
even close to basic VB features. Open your checkbook, or do without. So
far, I'm not anywhere near the feature set I am used to from my
VB/Delphi days.

MySQL 4.1/5.x uses a new password scheme, for better security... except
you cannot use it with RB. You are forced to use the older, shorter
passwords until this is fixed. So, a client upgrades a server for
security (ours did), and you come crashing down until you read the RB
NUG archives. Blech.

Data grids... read the current threads on the NUG -- the grids are not
ready for prime time. They are "listbox" controls with no where near the
features found in VB or Delphi. (See previous posts on this.)

I could go on for quite a bit. You have HID hardware? You're out of luck
on the Mac, but there are Active X controls for the PC. So much for
crossplatform. What's HID? Try some USB barcode printers, cash drawers,
medical devices, joysticks (feedback style), tablets (for artists), and
more. Oh, well... didn't really want to use my Mac for any of those
things. (Yeah, right! I'm still looking for solutions.)

Don't even imagine RB as a solution that doesn't break. They updated
from 5.2 to 5.5 and along the way broke a number of third-party tools I
use -- including a slightly better data grid and a good calendar control
I like a lot.

On the Mac side, when Apple does an update, things do break. I've had
FireWire drives stop working, a PowerBook trackpad started taking
vacations, and a G3 developed random boot issues that required a
firmware update. None of these were major issues at all -- easy to fix,
easy to handle -- but they illustrate that computers are complex beasts.

Think you are escaping DLL hell with RB? No way. For joystick support,
you have to locate Apple's HID.bundle folder and place it in your
application's folder. I've already had one app replace HID.bundle with
an older copy. That was nice.

If you use Active X, you'll still have DLL problems on Windows, too. If
you use anything with a DLL, you have to worry about it no matter your
language of choice.

No one is taking my Mac from me, that's for sure. I just put another PC
out to pasture today. But don't think RB is anywhere near what VB or
Delphi is. You will hit brick walls and learn to work around them. The
people on the RB NUG list are great at offering solutions, when they
can. Problem for me is that the solutions are to problems that shouldn't
exist.

I use RB and plan to learn Cocoa over the summer... or at least start
learning it. I am not going to sacrifice program quality for the sake of
being cross platfrom or for some unreasonable desire to stay with BASIC.
Porting means rewriting code no matter what, anyway.

- Scott

Scott Wyatt wrote:
I wouldn't go as drastic as creating a new window for each platform.
REALbasic has a good constants system that allows you to specify a
constant that will let you associate a value with a particular
platform. I generally just use those to move the OK/Cancel buttons
around.

But I agree, making your app feel right on all platforms takes some
consideration.

Or, use one of the many freely available third party controls that work
cross-platform.

Well, the problem is actually that we are accounting for it, not that
we ignore it. This was a "feature" from back in REALbasic 2.x  when
Windows support was first introduced. It basically ensured that
relative to control size and window size, the application would look
the same on Windows and Mac. This was actually rather good back in the
day for people who were writing on the Mac and wanted to deploy on
Windows, they're apps basically looked the same.

However, we realize that we need to solve this in a different, better
way. All I can say is that we have it scheduled for a future release.

Unfortunately, MySQL also changed the licensing scheme which is making
it more difficult to release a plugin legally. We are working on this,
however, and when the plugin is updated, since it is separate from the
product, you will be free to use it in older versions.

(Snip)

REALbasic provides "GameInput" classes which work cross platform to
provide access to HID devices. It appears you have used those on the
Mac, because that's what the HID.bundle is for.

As for the bundle -- on the Mac, you can use a free utility like Thomas
Reed's AppBundler (<http://www.bitjuggler.com/products/appbundler/>) to
package your application as a bundle, and place the HID.bundle inside
of it. This is a unique case for REALbasic, because Apple provided the
extra HID support as a separate distributable as opposed to being built
into the system.

If you need help getting down and dirty with the IOKit on OS X for
two-way interaction with HID devices, feel free to email me off list
and I'll point you in the right direction.

We work with plugin authors to help ensure that things don't break. We
have plugin authors already announcing support for REALbasic 2005.
Sometimes plugins do break and fixes aren't available immediately, but
as with any major upgrade, I suggest trying the new version first to
make sure it works with you. We try extremely hard to maintain
backwards compatibility with older projects. In our examples download,
there are examples that haven't been touched in nearly 6 years.

Correct. Our message is that we don't rely on packaging applications
with DLLs, which means that unless you're using declares or external
resources (like ActiveX), you won't need to worry about DLL hell. (The
above example of the HID.bundle is the only case that I can think of in
which the application cannot be built into one file, due to Apple's
decision to package that functionality the way it is)

-Jon

Correct.  I am new to REALbasic.

I hev read your issues with REALbasic and will certainly keep them in mind
as I play with the beta.

I agree.  But, they didn't try and be cross-platform.  Writing a coding
platform that is platform specific is a world easier than trying to develop
a true cross-platform development environment.....so, I'm apt to be a little
more patient.

We shouldn't have problems porting larger VB6 apps to VB.Net that results in
rewrites most of the time, and there's no work-around for that - from
anyone - at this time.

I also agree.  While the BASIC-like syntax is convenient, it is no basis
from which to choose a platform.  You must choose a platform based on the
ability to deliver the functionality required by your clients and the
stability of the platform (i.e. how well does the environment treat its
older code base?).

Thanks for your views on REALbasic.  Have you tested these issues in the
newest beta?

REALbasic does support building service applications in the
professional version, and you can also build web applications (although
a feature code-named Swordfish that has been announced for a future
version will make it much easier). If you want to know how to create an
HTTP server in REALbasic in less than 100 lines of code, I have an
article published by O'Reilly available here:
<http://www.macdevcenter.com/pub/a/mac/2004/11/19/realbasic.html>. You
can also write Apache CGIs in REALbasic. Unfortunately, I can't seem to
locate the example online right now, but if you're interested in an
example CGI, feel free to email me off-list and I'll send you the
sample code.

Hope this helps,
Jon

¤ REALbasic does support building service applications in the
¤ professional version, and you can also build web applications (although
¤ a feature code-named Swordfish that has been announced for a future
¤ version will make it much easier). If you want to know how to create an
¤ HTTP server in REALbasic in less than 100 lines of code, I have an
¤ article published by O'Reilly available here:
¤ <http://www.macdevcenter.com/pub/a/mac/2004/11/19/realbasic.html>. You
¤ can also write Apache CGIs in REALbasic. Unfortunately, I can't seem to
¤ locate the example online right now, but if you're interested in an
¤ example CGI, feel free to email me off-list and I'll send you the
¤ sample code.

I was referring to web services and web applications. I didn't see support for either in REALBasic.
If I missed it you may want to point it out on your web site.

Actually it might help if you could provide a bit more detail with respect to features on your web
site. I realize that this stuff can be downloaded, but some folks may not want to do this. A FAQ
would help as well in answering questions such as "Does REALBasic support 3rd Party ActiveX
controls?"


Paul
~~~~
Microsoft MVP (Visual Basic)

Paul Clement wrote:
support for either in REALBasic.
REALbasic doesn't limit you to what you can develop. It has a TCPSocket
class, and using the TCPSocket you can build basically any internet
application. While there are not built in templates (yet) to do that,
people have accomplished it.

(<http://www.realsoftware.com/realbasic/indepth/>), it does show that
we support calling SOAP natively, and if you search a little on some
third party websites like <http://www.rbgarage.com/>, you can find some
RPC classes.

I didn't realize you were interested in web service applications, sorry
about that. I also have an example that if you're interested I can
email anyone offlist. It is based on the HTTP Server in my article I
mentioned previously, but provides a small framework for responding to
incomding SOAP queries.

respect to features on your web
not want to do this. A FAQ
support 3rd Party ActiveX
While I understand your point, that one is actually on our website :)
It's listed under Windows-Specific Technologies on the in-depth page
mentioned above.

With that said, we are in the middle of designing a new website and are
looking at ways to help answer questions. Since my intent of replying
on this list isn't to do marketing, I don't want to go in-depth about
REALbasic's feature set on-list. However, if you, or anyone else, are
interested about the presence of a particular feature in REALbasic,
feel free to reply to me off-list, and I will answer any questions you
may have. If you feel there is something that needs to be changed or
improved upon, we are also interested in hearing that. We value
everyone's feedback.

Thanks,
Jon

Hi Jim,

I agree.

Not only that, but I've always hated dealing with all the big
non-Microsoft vendors. Up until 2001, Microsoft were a dream company to
deal with. It was XP, and now Longhorn that put me off.

However, regarding desktops and servers; the route I'm looking into now,
is very powerful servers (e.g. Quad 64bit Sun SPARC with a big-iron
fibre SAN) This could run Solaris, or if no using Sun hardware, maybe
something like OpenBSD? There's plenty options for all the web stuff,
databases, full-text indexing and XML, and it will run a lot faster and
more stable than Windows 2003, and it would also be easier to migrate to
other servers and platforms at a later date.

This would cover all the mission critical stuff I need to do and all
apps would be available world-wide and would run x-platform and x-browser.

The desktop could be something completely unrelated, e.g. one of the
free Linux builds, but all our apps are web-enabled anyway so I'm not
sure it would matter much. The problem would arise for when we need to
use graphics - e.g. a flowchart, but I'm sure we'll find something.

The big piece of the jigsaw that's missing for our corporates internally
is how to replace Active Directory, all the user accounts and NTFS ACLs
and also an "Exchange" style mail server. These are areas I have no
solution for as yet.

On Thu, 07 Apr 2005 00:05:18 +0100, Gerry Hickman
<gerry66***@yahoo.co.uk> wrote:

Show quoteHide quoteOne approach to graphics is to convert them into gif or jpg files and
include them in the stream being sent to the clients, but I'm sure you
have considered that solution

Doug Taylor

In article <ON6dnceX-OqXz8nfRVn***@giganews.com>, Jim Hubbard wrote:
Show quoteHide quoteYou really have no idea what your talking about...  The fact is, I can
be pretty productive using Mono+C#+Glade# on my Gentoo linux box.  And
once they get mbas fully up to speed, then I can use Mono+VB.NET+Glade#.

<snip>

Show quoteHide quoteTom,

    I'm certain that you can be very productive in those languages.  But the
point that I was trying to make is that most developers are "task oriented"
developers and not professional developers such as yourself.

    In most cases, these task oriented developers have a main job that is
not programming, but they needed a quick way (without spending a large
amount of time learning a more complex programming language and without
learning about the internal workings of the IDE or framework) to create
applications to make their jobs easier.

    Classic Visual Basic was the king of RAD, and fit this bill more than
any language in the world.. It made programmers of CEOs, mail clerks,
secretaries, attorneys......and so on.  Because of the extreme ease of use,
the component architecture and the English-like syntax, classic Visual Basic
made developers out of more people than any other language in the world and
made Windows the champion of small businesses and task oriented developers
the world over.

    Classic Visual Basic saved money in that small businesses did not have
to hire professional programmers to get applications that helped them
streamline their operations.  And, as more businesses used classic Visual
Basic, 3rd party developers cropped up to deliver components to make it even
easier to use.  This resulted in more adoption of the classic Visual Basic
and Windows platform.

    In VB.Net, Microsoft has lost the RAD edge that task oriented developers
loved (and actually needed).  The VB.Net books that I have read (all 54 of
them) are even more of an affront to the task oriented developer.  The vast
majority of task oriented developers simply don't want to be professional
programmers.  If they did, they'd stop being attorney's or mail clerks or
whatever and devote themselves to it full time.  For the most part, they
just want a simple IDE to make applications to make making a living easier.

    For the majority of them, C#, Mono and related languages are not nearly
as easy to use and learn as languages like Visual Basic and REALbasic.  This
is the reason I suggest that classic Visual Basic developers that feel
slighted by Microsoft take a look at REALbasic.

    REALbasic offers the ability to use a much less expensive desktop (like
Linspire, SUSE or even Red Hat) with applications that interact with
Microsoft Office and offers the developer the chance to develop on MAC,
Linux or Windows and distribute their apps to all 3 platforms.

    The REALbasic/Linux platform will not be for everyone.  But, for task
oriented developers, developers that would like to target all 3 platforms
from a single set of source code and developers and small businesses looking
for a more cost effective solution than Microsoft's ridiculous pricing of
its products.....REALbasic is worth a look.

    A look is even free.  They can get a free copy at
http://www.realbasic.com/vb6/index.php?id=GVVDPQFY .

Jim Hubbard

In article <ELednQe-bYJcPsDfRVn***@giganews.com>, Jim Hubbard wrote:
Show quoteHide quoteAh, so were not talking about proffesional hackers...   I guess I missed
that.  For that, I agree you are right.  I know of nothing in linux that
is as easy to use as VB.CLASSIC.

I apologize for my misunderstanding.

Show quote Hide quote No problem.  I may have not been clear enough in my postings, and maybe this
will help clear things up.

Thanks for the questions.

Jim Hubbard

Tom, there is a Linux-only, VB Like language, with a pretty nice IDE called Gambas.
Here's the link: http://gambas.sourceforge.net/  (free)
I have messed with it and it seems to be prettty nice and easy to use.  I have built a couple of test apps in Linux using Gambas
and it ran just fine in both KDE & Gnome.
(Just thought you might be interested in another alternitive)
james

On 2005-04-14, james <jjames***@earthlink.net> wrote:
Show quoteHide quoteJames - thanks.  I'll have to check that out...

In article <O671WYMQFHA.2***@TK2MSFTNGP10.phx.gbl>, Tom Shelton wrote:
Show quoteHide quoteJust a follow up...  I installed gambas immediately after posting this.
First impression - definately worth a closer look.

Have fun with it!
james

Jim Hubbard wrote:
Show quoteHide quoteNot to get all philisophical here... But, isn't this one of the biggest
problems that a lot of professional developers face? I'm not talking
about losing money to people who become simple programmers... I'm
talking about professional programmers having to always go back and fix
broken or misused code because a mail room clerk wrote a program that a
business now has to rely on, and that clerk did something wrong. I have
only run into this a few times in my career, but I have read countless
articles that pointed out the fact that classic VB created a ton of bad
code. It was these people that don't have the fundamental knowledge of
programming, or even computers, that created a ton of programs that ran,
but had problems and when they leave a company, now they are forced to
hire someone to rewrite it. It would have just been easier to have it
done professionally once instead of paying to have it written once
unprofessionally then pay someone twice as much to fix it.

Show quoteHide quoteIf real basic is so great for these "task oriented" developers, than why
are you even asking for VB.Com? If the programs they wrote were so
simple and a mail clerk could do it, then the switch to real basic would
be simple and they could do it with no problem. If there are other tools
out there that these people can use, then let them go use them.

Show quote Hide quote While it is true that a lot of code written by task oriented developers does
not conform to proper use of the language (from the point of view of
professional programmers) and may require rewriting, the very fact that the
task oriented developer could write the program in the first place helped
the small business along and showed the usefulness of the task oriented
developers idea.

I have been called upon to enhance and "fix" these applications for most of
my career.  But, I have also seen many ingenious methods of solving problems
that have streamlined businesses and departments that were not only adequate
for their purpose, but whose usage saved companies thousands of dollars each
year.

In my experience, the companies that needed rewrites were the companies that
rushed the employees instead of giving them the time to learn and use Visual
Basic correctly.  These same companies frequently assign ridiculous
deadlines to professional developers while changing specs constantly and
will have the same problems as before (not every time, but most of the time
I see this as being the case).

Show quoteHide quoteI signed the petition before I was introduced to REALbasic.

I agree.  REALbasic is not the only alternative.  However, it is the
alternative that allows for upgrading of VB6 apps and uses a similar syntax
to VB6 and runs its apps on Mac, Linux or Windows.

In all, I find that REALbasic offers more "bang for your buck" than the
other alternatives that I have looked at so far.  If you have any suggested
alternatives, please post them here.  I'd love to look at them.

Remember that REALbasic is only FREE for 2 more days, so download your copy
from http://www.realbasic.com/vb6/index.php?id=GVVDPQFY  ASAP.

Jim Hubbard

Jim Hubbard wrote:
Show quoteHide quoteSo, if a company has to give the employee ample time to learn and
correctly use VB6, why not just hire it out? I realize not all software
shops are reasonably priced, and we may be an exception, but we can
crank out solutions for people faster than what it would take them to
let an employee learn the language and then write the app. Most
employees won't do this stuff on their own time, they want to get paid
to do it. So you have to pay the employee to sit there and read a book,
read a website, post messages, and "play" with the software while they
learn the process or write the app. Seems way cheaper to me if you just
call a software shop that specializes in writing custom software.

VB.Net, C#

Show quote Hide quote In our area, homesourcing costs $90-$120 an hour.  Most businesses can
afford to put an internal employee on a project and spend less money even if
the employee takes considerably longer to finish the application.  And, the
company then has an in-house developer that can be used for other small
projects or RAD designs that get passed on to professional developers.

Lots of small companies like the idea of having an in-house person that can
trouble-shoot apps on-the-spot rather than having to call in someone
whenever there is a problem.  Training internal resources allows
this.....and using Visual Basic allows a developer to get up-to-speed  a
great deal faster than using a language like C++.

Intentionally breaking backwards compatibility and hiding the fact that .Net
patches are the DLL Hell of .Net are just 2 reasons I am seeking other
solutions to .Net.

Jim Hubbard

In article <h7ednWqTOdCACsPfRVn***@giganews.com>, Jim Hubbard wrote:
<snip>

I'm not quit sure I get this one...

Microsoft loudly and frequently touted the .Net framework as the end to DLL
Hell.  But, this is not necessarily true.

If you subscribe to the free newsletter at www.KBAlertz.com (and I HIGHLY
recommend that you do) you can look up weird behavior in the .Net IDE and
framework.  Last time I looked, there were 1,561 issues acknowledged with
the .Net 1.1 framework.  (NOTE:  I am NOT deriding Microsoft for not having
a perfect product.  Nobody has a perfect product.  Not Real Software.  Not
Hubbard Software.  Nobody. )

But, the .Net Patch Hell problem comes in like this.....

You find some buggy behavior in the .Net framework mentioned in the
Knowledge Base (most likely through a KBAlertz email).  You can (as most do)
choose to work around it in code, or you can call Microsoft and request a
patch.  (I will resist the temptation to rant about not being able to just
download the damned patches from the KB Articles.......for now.)

If you install the patch, it patches the .Net framework on your development
PC.  Now, your development PC is out of sync with everyone that does not
have the patch.  Not a problem really....just distribute the patch with your
program.  Well, not a problem for you anyway.

If you decide to ship the patch with your program, there is a high
probability that other developers' programs on the target machines that used
the code work-around will no longer function correctly.  Your patched code
and patch will break their code.

If you choose the common path of coding around the bugs where possible and
some else ships a patch, there goes your code!

So, it seems that we all either don't fix the problems and code around them,
or we  all apply the patches.  You and I both know that "all of us" will
never do anything.  So, here we are.....in Patch Hell.  And, how is this any
different than DLL Hell?

It's not.

There is a solution (albeit a pricey one for small ISVs) called Thinstall.
It wraps your entire .Net application (including all .Net framework
dependencies and any applied patches) into a single executable that will run
on any Windows PC from Win98 up.  It's actually an incredible solution, but
it's out of the price range of most small companies and not suited for every
application (if you use hooks into the kernel for example).

If you can't afford Thinstall for all of your .Net apps, you'll be risking
Patch Hell with most of the rest of the world.

Jim Hubbard

I'm not sure I agree. I have a VMWare installed with .NET 1.0 SP0, when I
compile an application with it it runs on .NET 1.0 SP3, .NET 1.1 SP1, and
..NET 2.0 Beta 1. The evidence is pretty good that MS is doing a pretty good
job of avoiding Patch Hell. Since IL uses tokens rather than specific
addresses it's actually quite difficult to break a version.

No, your code should be fine unless you write code that *depends* on the
bug, which let's face it is a pretty silly thing to do if you can avoid it.
You could find third-party libraries that do what you want or you could
write your own Interop library to perform the work for you.

Show quoteHide quoteBreaking up the .NET Framework DLL's and linking them into your application
wipes out the entirety of the .NET CAS system. Since Thinstall cannot
re-sign the Framework DLLs, they cannot be checked for tampering. Not a
problem many people worry about, I know, but it is one of my main objections
to .NET linking programs.

Since Patch Hell has not yet materialized after 5 years, you'll forgive me
for not getting too worried yet ;D

Show quoteHide quote

Show quote Hide quote You are comparing different versions (which, BTW, are not always backwards
compatible) NOT the patches to which I refer.

Have you called Microsoft for a patch?  Have you installed one?  Have you
used the affected portions of the .Net framework and distributed this code
to non-patched systems?

If you are writing a "work-around" it will naturally depend on the bug.

Heck, you could write your own IDE.  But this still does not address the
Patch Hell problem.

Show quoteHide quoteFor all of the ballyhoo surrounding the security built into the .Net
framework, I have yet to install an application or work on an enterprise
project that uses it.  IMHO, lots of hype about nothing.

I think it really comes down to only installing applications from reputable
vendors.  Anything else will not save you.

You are forgiven.

In fact, I never saw DLL Hell.  But, there has always been a simple way to
avoid DLL Hell, and responsible shops used it for widely distributed
applications.  Simply put your executable's DLLs in the exe directory.
Windows will use those DLLs before using shared DLLs.

The point I am making, is that the potential for "X Hell" has not dissapated
with the advent of .Net.  .

Net brings many good things to the table.  Protection from "X Hell" is not
one of them.

Jim Hubbard

Nope, never needed to... Yet.

Not neccesarily. If you find a bug in the .NET TcpListener class for
example, you can just write the Socket accepting code yourself. If the bug
is now fixed or unfixed it will have no impact on you whatsoever.

Actually it does. Unless the bug is in the .NET CLR/JIT it'll be in one of
the libraries, and my point was that you could then just circumvent the bug.
[Snip]
I agree wholeheartedly. The potential for a Patch Hell. or even a Framework
Hell where you try to figure out which of many frameworks is installed,
indeed still exists. However it does appear that .NET goes some way towards
ameliorating DLL Hell, and so far hasn't had a Framework Hell. Your Patch
Hell may indeed be a problem, but I haven't encountered it yet. So as far as
I'm concerned .NET is a step in the right direction.

Nothings a complete protection from difficult problems. .NET does cut down
on the amount of Hell though.

Show quoteHide quote

    I was told the Office is $495 because that's the maximum amount most
first line managers can expense without approval from higher up.

Jim Hubbard wrote:
yay, another REALbasic advocacy thread! whoopdiedoo

In article <orWdnWOWPvwpTc7fRVn***@giganews.com>, Jim Hubbard wrote:
Show quoteHide quoteYou need to do your reasearch....  Mono runs on way more platfroms than
REALbasic.  And even supports VB.NET - though, that is still not fully
operational, though should be by the end of this year.

Here are the current supported OS's for Mono:
Linux, Windows (2K and up), OSX, BSD, Solaris

Show quote Hide quote Are you saying that Mono puts out exe's for all supported platforms with a
single set of source code and a single compile like REALbasic does?

I haven't really been attracted to Mono because of the syntax.  I just don't
like it.  And, I don;t like the idea of always playing catch=up with
Microsoft.  Mono should make a clean break with Microsoft and
innovate.....but, then it may lose it's ability to play well with .Net.

Fortunately, REALbasic isn't caught in that trap andcan move in any
direction that their developers need without really worrying too much about
how Microsoft does things.

I'd love to take a look at it.  Hopefully it gets more back to the RAD IDE
that wa classic Visual Basic.

The only real concern I have is that it is basically unsupported.  As a
business owner and having to deal with ISO9000 issues, most executives that
I deal with demand accountablity in the products that they adopt and feel
that this is missing with Mono.  It's the same reason that companies adopt
RedHat instead of their own version of Linux.  They need a support team
ready when they need help.

Who on the Mono team can we call if we need help today with a project?

REALbasic has a great support team.

Jim Hubbard

In article <9PGdnfByK_WZO8DfRVn***@giganews.com>, Jim Hubbard wrote:
Show quoteHide quoteYes...  In fact, for the most part an exe compiled in VS will run on
linux under mono and a exe compiled with mono will run on windows under
..net.  There are exceptions - some classes and namespaces that haven't
been fully implemented yet (most notably, system.windows.forms - which
is also comming at the end of this year).

Well, it's just C# and to be honest, I like C# better anyway :)  But, if
that's not to your liking - the full VB.NET syntax will be available.
There is already a Java implementation (IKVM), and IronPython runs on
..NET and Mono.  There are several language choices on Mono as well as
..NET.

Actually, Mono does innovate.  They have tones of libraries of their
own.

Same with Mono - since their primary goal is not actually compatability
with .NET.  That is just a side affect of implementing the ECMA/ISO
standard.  The primary goal of Mono is to make Linux development easier.
Compatability, is a secondary goal - primarily to make Linux a more
attractive platform for ISV's.  If you look at the way Mono is deployed,
it is done in 3 stacks...  The mono core that contains all of the
ECMA/ISO stuff (this is pretty much complete), the mono specific stuff
(libaries that are distributed with mono and not with .NET), and the ms
compatability stack.  The ms stack contains stuff like,
System.Windows.Forms, ASP.NET, ADO.NET, etc.


Mono, like .NET is not tied to an IDE...  Yes, there is a Mono specific
IDE in the works (MonoDevelop) but it is pretty rough around the edges
at this point....

Not really true.  Mono is supported by Novell.  You can purchase support
and technical consulting if you so desire/need it.

SuSE is begining to ship with Mono as part of the default package as of
9.3 I believe.  SuSE is a paid for distribution from Novell.  So, you
can use Mono and have support.  In fact, many of the new Novell Linux
products are based on Mono.

You call Novell.  Or you do like you do with VB - you get on the mailing
list, and ask away :)

<snip>

Show quoteHide quoteThat's good to know.  Thanks for pointing that out.

I've been waiting on the VB.Net version.  But, seeing as it has been so
long, and that the release will be far from the RAD environment that I loved
with classic Visual Basic, I think it will be quite some time before the
Mono's VB.Net version is a viable option for me.

Also a good thing.  Developers should be in control of where apps go.....not
Microsoft - or any single company.

Again...something I did not know....cool.

I'm all for this!

Show quoteHide quoteI guess this is a major sticking point for me.  I want (and even need) the
RAD IDE of a classic Visual Basic-like language to keep my productivity at
its current levels.

VB.Net 2005 is heading back in that direction some, and I am glad.  But,
I'll reserve final judgement on that implementation until I see the final
product.

I knew that they were a major backer, but I did not know that they sold
support for Mono.

Show quoteHide quoteI just bought 9.2 Pro a couple of weeks ago and have enjoyed playing with it
(although I wish it would run under VMWare - they only support version 9.1
at this time).

You know....I'm actually working on a little product to make that
easier......

Thanks for enlightening me on some Mono facts that I was ignorant
concerning.

Jim Hubbard

On 2005-04-14, Jim Hubbard <reply@groups.please> wrote:
Show quoteHide quoteNo problem.

Show quoteHide quoteHere's the things...  If you stick to .NET stuff, then you can actually
deploy VB.NET programs to mono right now.  At that point, it's just IL.
It's really just the mbas compiler that is in need of some work :)

I agree.

Show quoteHide quoteMe to.  Don't get me wrong.  I like and use MS products - but, I also
like and use Linux.  It's nice to have something that will work on both.

Show quoteHide quoteFor your enjoyment...

    http://mono-project.com/FAQ:_General#The_Novell_Role_in_the_Mono_Project
    Will Novell offer Mono commercially?

    Novell will offer a commercial support and services for Mono. Mono
    components are also available to be licensed commercially. For
    licensing details, contact mono-licens***@novell.com

Show quoteHide quoteTo be totally up front...  I haven't been all that impressed with SuSE.
It's not that it's bad - I just don't like RPM based packaging.  I have
really fallen in love with my Gentoo system and it's portage package
manager.

No Prob.  I'm a big mono fan.

I have been a long time fan of Microsoft and their products (although these
posts may make that less than clear at times).  But, with the direction they
have taken VB.Net (which is anti-RAD, IMHO) and the continued rising costs
Microsoft products that, let's be honest, really don't add that much value
for the average office user (like MS Office 2002 to 2003) and with the trend
towards intentionally breaking backwards compatibility - we need another
option.

<snipped>

Show quoteHide quoteThanks again!

<snipped>

I'll have to try Gentoo......but, they'll have a hurdle to make it easier
than Linspire - which I installed 4 times in the last 3 days.  Linspire is
the easiest Linux system I have ever seen.  The 5.0 version desktop is very
user friendly and the CNR (Click N Run) way that you can instll new
applications from their library by just clicking on them is just great.

The only problem I see is  a lack of polished software when compared to
Windows.  That's why I think that a RAD IDE like REALbasic would help Linux
a great deal.  The more poeple we have coding for Linux, the more polished
apps we will have to choose from, the more viable the Linux desktop becomes.

I support any IDE that makes Linux easier to write polished, professional
applications on.  I do so because I believe that competition is good for
consumers.

Pepsi is good for Coke (or we'd probably be still stuck with that "New Coke"
crap).  Canon is good for Xerox - it keeps them on their toes.  Many choices
in cars makes the manufacturers build better (and less expensive) cars.  We
need that competition for the desktop too.  And, if I can do anything to
helop bring it about - I will.

Like recommending that anyone reading this thread that has not downloaded a
FREE copy of REALbasic do so BEFORE THE APRIL 15, 2005 DEADLINE by clicking
http://www.realbasic.com/vb6/index.php?id=GVVDPQFY .

Thanks, Tom, for the Mono information.

Jim Hubbard

In article <C86dnQ1v3fSmG8PfRVn***@giganews.com>, Jim Hubbard wrote:
Show quoteHide quoteActually...  Gentoo doesn't even try to make it easier :)  Gentoo is a
source based distro.  It has no graphical installer, like most distro's.
In fact, it doesn't really have what you would call an installer at all.
You basically, boot from a cd, manually partition your disks, download a
source tarball based on the level of install you want, and the run some
scripts to compile stuff.  The documentation is pretty good - but you
HAVE to follow it.  You can't just skip ahead because you think you know
something.

The thing I like about Gentoo is the fact that it is pretty minimal in
it's base form (it doesn't even install X by default).  I can add stuff
as I need it with a simple command from the command line, and it works
out and installs all the dependencies...  If you ever worked with a
FreeBSD system and there ports collection, portage is pertty similar.


Does it still have you run as root by default?  That was one of it's bad
points in the past...

That I agree on.  It's one of the main reasons I support Linux.  It's
not that I dislike MS or that I want to see them go away...  I just want
to see them have to compete a little :)

Show quote Hide quote This level of control seems great for businesses and professional software
people, but the Linspire thing looks more like something that could make a
real difference on end user desktops.  And, I think that's the market they
are shooting for.  They have just done a huge deal with WalMart and are
selling new Linspire Laptops for $598 and Desktops for $318 to $348.

It is an affordable alternative for the masses to Microsoft.......we just
need more polished apps for the desktop.

Yes it does.  Why is that a bad point?  Don't you need to be root to install
and tweak stuff?  I think they may opt for this to make the OS as easy as
possible for the end user.  The end user may have trouble learning the
difference between root and other levels of desktop users.  Look at
Windows.....most users run as system administrator.  Although this makes the
system less secure, it seems that end users would rather have a less secure
desktop with more power in their hands than a safe, limited use desktop.

Show quoteHide quoteAmen to that!

Jim Hubbard

In article <tZedndAry7WiEsPfRVn***@giganews.com>, Jim Hubbard wrote:
Show quoteHide quoteGentoo is really more targeted for power users...

Security.  Linspire is the only distro that does this.

It's a bad idea to run as admin on windows as well (though, I'm as
guilty as anyone...).  The only reason I can see for people to run on
windows as admin is because there is so much software (games in
particluar) that just won't work as a regular user.  This isn't the case
with linux.  Sure, it is a slightly different mindset - but not
difficult.  I think Linspire is doing a diservice to it's customers by
encouragin this practice.  Do they even explain the difference between a
normal user and root?

You might want to check out Xandros.  I here it's pretty windows user
friendly.

Show quote Hide quote Not really.....at least not that I noticed during install.  They do answer
questions about root on their site at
http://help.linspire.com/cgi-bin/linspire.cfg/php/enduser/std_alp.php?p_search_text=root&p_li=&p_prod_lvl1=&p_prod_lvl2=&p_cat_lvl1=&p_cat_lvl2=&p_new_search=1&p_page=1 .

I'll try it tonight.

Jim Hubbard

Jim Hubbard wrote:
Careful with that. They are a business too. Just because they say they
listen to the developer doesn't always make that the case. I've seen,
and heard that before.

Just like every other linux project that crops up, there is always
community support, just like what you get with Microsoft. And I'm sure a
ton of support companies will crop up once it starts to get adopted more.

So, if it's so great, why are we all still arguing? Why don't the people
that have a big problem with Microsoft dumping classic VB just switch to
real basic?

This is where competition is helpful to consumers.  We need more than one
option.  Then, consumers can go where they are listened to.

I have spoken with the President of Real Software (Geoff Perlman) and he
seems to understand the need to keep the customers in charge of the
direction of the product.  From the conversations and emails that we have
traded, I have to say that I have faith in him that this is true if him, his
company and team.

That's a good thing.

Who says they're not?

Perhaps people are rushing to download their FREE copy of REALbasic BEFORE
THE APRIL 15, 2005 DEADLINE by clicking on
http://www.realbasic.com/vb6/index.php?id=GVVDPQFY .  We'll see.

Jim Hubbard

Curious, I wonder where MS main customer base resides, the US or Offshore?
MS is fully aware that Windows became a hit on the PC's because the
Developers supported it. Can there really be that much money in the selling
of Development software that it can risk upsetting its OS Developers. I
think MS and us all are facing a changing world.


Show quoteHide quote

Hello,

To all VB6 developers, the things in the world are changing. Visual
Basic is evolving and if you are good developers you will evolve too.
Visual Basic 6 and previous versions are pale resemblances of the real
computer languages, Visual Basic.NET is a other story, real OOP
language, real framework. I like it.

Visual Basic 6, Delphi for Win32 and other Win32 languages are
obsolete. Now you have to think .NET style. Longhorn API will be .NET
based, Win32 is obsolete.

I know why you do not want to move to .NET...but I do not want to
offend some people here, the above stuff was for the serious
developers...

Best,

Philip.

This would make Visual C/C++ (without Managed Extensions) and VFP at least
as obsolete as Classic VB.  Sorry, but that's simply plain nonsense.

Hmm. And please tell me how you will develop the new applications for
Longhorn if VB 6 is not osbolete? How you will use the WinFX API? Do
you understand that .NET is the new standard of building applications?
As I see you are DotNet developer...so I do not see the point to
advocate to VB6? Also, I Visual C++ will not be obsolete when it comes
to building drivers and low level stuff - video games too. But it will
be obsolete when you are building desktop applications. So of what I
said is nonsense? Maybe that in NT 6 all Win32 code will be considered
as legacy and will be run in legacy mode.

Regards,

Philip.

At least parts of this API will be made available to COM and/or Win32, as
far as I know.  This has mainly practical and economical reasons:  A rewrite
of existing applications in managed code is not accomplishable within a few
years.  Take a look at the technologies supported by Windows XP today:  Even
DDE is still supported, because applications rely on it, and DOS/Win16
applications can still be executed.

It's utopistic to think that Microsoft will pull the switch for Win32/COM
applications within the next ~10 years.  By doing that Windows would loose
millions of customers who wrote software for Windows.  It's compatibility
and interoperability which tie customers to a certain platform.  If
compatibility is not one of the main goals any more and customers' assets
are rendered disposable, customers will consider turning to a more
compatible platform which preserves their assets.  "Everything in .NET" is a
nice pipe dream.

I don't see the whole issue from a technical standpoint only.  In fact I see
the economical perspective too which is the driving force for choosing a
platform over another.  I don't advocate VB6 because I think it's better
than .NET.  Sure, there are some things which were better in VB6, but there
are lots of things I like more in .NET.  The reason why I don't think that
VB6 should be disposed are the billions of lines of code written in this
language which won't be converted within short time (some years).  COBOL,
which is some decades old now, is still used for banking and financial
transactions.  Programming languages are not coupled to a platform or
technology and in general their lifetime is much longer than the lifetime of
a technology.  There are no technical reasons for not adding .NET support to
the Classic VB programming language like it was done with other programming
languages, for example, C++, EIFFEL, COBOL, FORTRAN, ...

Do you really think that Office, for example, will be fully managed when
Longhorn is released?  Complete rewrites are hardly ever done because a new
technology is appearing.  The costs of a rewrite are much higher than the
benefit gained by it.

I doubt that customers will accept that, because it will dispose assets
similar to how assets are/were disposed by discontinuing VB6.  Microsoft has
lost customers and is about to loose customers by disposing VB6.  Microsoft
may loose the Linux vs. Windows war by breaking compatibility.  I like
Microsoft products and I use them, but I don't agree with all decisions made
by Microsoft in the last decade.  I am afraid that Microsoft will go the
same way IBM and other companies did if it doesn't give their customers'
voice more importance.

Herfried,

You are right if we look with the eyes of a bussinessman. But I am a
software developer and I am keen on new technologies and etc. I love to
learn and use new technologies. So I will be the first who will accept
WinFX and start building applications using it...I am not a
bussinessman who drives BMW to care how money I will lost. See, I am
right for myself! You are right for yourself. I just did not like that
you said I am writing nonsenses.

And one more thing...Win32 code will be run in legacy mode. It is true,
I saw one diagram where the Win32 will be considered as legacy.

"Herfried K. Wagner [MVP]"

Some guys like me know that you are not, however I think that you give for a
lot others the idea that you do.

I am afraid that it puts you in a wrong light. I understand your opinion.
However in my opinion have you made that clear enough to everybody active in
the dotNet newsgroups.

Just my thought,

Cor

Cor,

I don't see how advocating VB6 puts someone in a wrong light.  It's a myth
that all people advocating for VB6 do that for ideological reasons.

Herfried,

For me are you showing yourself in the dotNet newsgroups as the big defender
of the VBCom idea.

Although this is a very much crossposted thread, do I not see any not in the
dotNet newsgroups known MVP in this thread?  While in my opinion Tom and
Paul do definitly not (at least not most of it) share your opinion in this.

However, it was a free advice do with it what you want, it does not bother
me.

Cor

A very simple question... if anyone knows the answer:

How can Office on the Mac look and act similar to Office for Windows? I
assume MS uses Metrowerks C++ or a similar tool -- meaning they don't
even use their own compiler to port a near-clone of their Windows
applications. (I know Mac users want to recall that Word and Excel were
Mac apps, but the code base is clearly from Windows, now.)

There is no way you could write "Office" or a clone of a little Office
application in REALbasic -- it's a toy in comparison to other compilers.
You can crank a decent editor, spreadsheet, or database tool in Delphi,
VB, or C#, but don't imagine creating something similar in RB.

RB doesn't handle tab panels properly, grids stink, and database
controls have problems -- like the inability to connect to "properly" to
MySQL 4.1/5.0 or to even return the record count properly.

You can do a lot with RB, sure, but nothing like you can with another
tool. You can do magic with RB, but you can also do magic with the
current releases of FoxPro or dBase. Some genius out there can make a
killer Windows app in Visual COBOL, for all I know.

RB is an infant or pre-teen not yet mature enough for some applications.
The lack of a serious RTF/HTML edit control, the database model (I like
n-tier systems) stinks, and it is NOT a pure OOP system -- the controls
do not map to a single "TObject" and you cannot place controls within
controls (checkbox within grid/listbox?) without resorting to tricks.

If someone spends a year or more with RB, they recognize it is an "OK"
solution, but you end up wishing for a complete widget set at the very
least. If you want to write code for each platform using compiler
switches, so the proper controls to the platform are used, then enjoy
the extra work.

RB is not "cross platform" as in "click-n-go" unless you care nothing
about UI standards on each platform. If you want to use controls like
their lousy grid, which places an "editfield" control where you type to
handle user input, or their "combobox" which is another strange hybrid
control, then that's fine. (Yes, all complex controls in other tools are
variations of tricks -- but they sure seem better-implemented!)

I use RB, like RB, but also can't imagine using RB on Windows or Linux
since there are much much much much better tools on those platforms. I'm
waiting for Tiger to play with gcc 4.0 on my Mac, which is probably my
final destination -- after fighting to make RB applications work with
any speed and proper appearance (page panels on a tab or vice-versa will
crash) on the Mac.

RB is cool for simple things and little prototypes. You can make a
"commercial" program, but only to a certain level before you still need
to know C/C++ or the blood-n-guts of the API for DECLARE statements. And
the moment you use an Active-X or .bundle control... back to "DLL HELL"
on the specific platform. (A .bundle on the Mac is no better than a
DLL... as I've said before.)

Just use RB and be content, but don't try to pitch it as a serious
option to VB without telling people a lot of re-work will be needed in
most cases. The VB-to-RB converter is proof that you can't just port a
VB application and have it work.

I'll probably keep using RB for years, but not for anything serious
after this last major project. It was painful and I don't like pain. In
the end, we had to pay another developer to create a plug-in on the Mac,
in C++, to get some basic functionality -- because we used RB up to the
point of realizing what it couldn't do and were stuck. Even knowing C++
doesn't mean you can easily create an RB plug-in; I have better things
to do.

The lesson was: if I need (take your pick) C++/C#/Objective-C anyway,
why not start there?

- Scott

Scott Wyatt wrote:
If I'd have to write a cross-platform GUI application targeting Windows,
*nix and Mac OS X I'd give Mono and one of its OS independent widget
tools (e.g. wxWidgets) a try. Another option would be a Java based
application. I'm not sure which one is the better solution.

Gerald

PS: f'up to comp.lang.basic.realbasic

Where to find good icons?
In-place Updating in Datagrid not working
Why doesn't timer tick
Accessing Through Newsreader
modify HTML in code behind
How to expose a structure to VB6 from VB.NET?
Datagrid problem
How to convert a Byte array to a String
Multiselect List Box
Catching exceptions during DirectoryInfo.GetFiles?