Fog Creek Software
Discussion Board




Best Dev tool for writting Win32 Shareware


I've read the following thread (Delphi for ShrinkWrap Desktop Applications ) with great interest :

http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=108401&ixReplies=40

Interesting Article too : http://www.lemanix.com/lemanix/lemanixisapi.dll/Entry?ID=1167

According to many opinions Delphi seems to be best tool in terms of productivity an ease of deployment.

I may want to try Delphi for the shareware I'm going to develop, does a program developed with Delphi 7 will work on the next MS OS (LongHorn ?)
Or will it required to be ported to Delphi 8 (with .NET support)

Is it still worth investing 6 months (spare time only)
dev time for a shareware using Delphi 7 ?

Linus Ericsson
Thursday, April 08, 2004

If 6 months of spare time is worth it is hardly a question this forum can answer. Ask yourself thtat. Are you prepared to devote that time?

As for using Delphi, what programming language are you currently using? ... Delphi is a very good language to develop shrink-wrap software in, but ultimately you pick the language that makes you most effective.

If you have to learn a new language, you will not finish a good quality shareware application in 6 months or less anyway.

Patrik
Thursday, April 08, 2004

If you're capable of finishing an app of sufficient quality that many people will be willing to pay for it in 6 months, choice of language should be no barrier. Anyone that talented should be able to pick up something like Delphi in a week. It's just not that difficult to learn if you've done any amount of programming before. Most languages aren't.

Sum Dum Gai
Thursday, April 08, 2004

> does a program developed with Delphi 7 will
> work on the next MS OS (LongHorn ?)
> Or will it required to be ported to Delphi 8
> (with .NET support)

The official Microsoft line I heard at conferences is that:

- Longhorn will have .NET as it's main API

- Win32 will be available, but from a Win32 program you won't be able to access all the new features of Longhorn


Now, here is what I think:

Microsoft can not afford to abandon Win32 API.

The abundance of applications on the Windows platform is one of the strongst selling points of Windows.

This is why OS/2 failed - Windows had many apps, OS/2 had very few. This is why most people don't use Linux.

Now, if MS decides that from Longhorn on, many Win32 applications won't run - many of their customers may switch to Linux, or Lindows.

So, I develop for Win32 today, and don't worry about the future, because I think that for MS, kicking Win32 applications is like commiting suicide.


Yes, the new .NET in Longhorn will have some more features.

However, the many third Delphi components that are available today are a hell of a lot more than Longhorn will be, and are deployable today on Windows 95, 98, 2000, XP and 2003.

MX
Thursday, April 08, 2004

"So, I develop for Win32 today, and don't worry about the future, because I think that for MS, kicking Win32 applications is like commiting suicide."


Very very true.

Mr. Analogy
Thursday, April 08, 2004

"- Longhorn will have .NET as it's main API
- Win32 will be available, but from a Win32 program you won't be able to access all the new features of Longhorn"

Flashback:

- Windows NT and Windows 95 will have Win32 as its main API
- Win16 will be available, but from a Win16 program you won't be able to access all the new features of 32-bit Windows.

Ooh, an even better one:

- Windows will have Win16 as its main API
- DOS will be available, but from a DOS program you won't be able to access all the new features of Windows.

Even better: Unlike in the DOS to Windows and Win16 to Win32 transition days, the .NET development tools are available for free for anybody who wishes to download them. I recall staring longingly at the Windows SDK at SoftWarehouse (now CompUSA) when it was $385, and entirely out the reach of my adolescent allowance.

So, sell me again on why you think Microsoft can't make this transition successfully?

Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, April 08, 2004

Microsoft CAN and WILL make this transition successfuly.

But it will take more than 5 years or so.

MX
Thursday, April 08, 2004

Python is often neglected as a choice, but it is extremely viable. BitTorrent, which is among the most popular programs lately, is written in Python.

Deploying a Python app is probably comparable to Delphi - both py2exe and McMillan's Installer will pack a Python program into one directory (or even one .exe) independent of anything else. It'll cost you some 1meg or so in runtime size, depending on what components you're actually using (200k minimum, but I guess 1 meg is typical).

Definitely simpler to deploy than Java client apps, and (still at this time) .NET; Plus, you get the benefits of an IMHO much better language, and what is probably the most portable environment available (The original 'CPython' itself is widely available, but there's also Jython, which targets the JVM, and IronPython, which targets the .NET CLR and though it isn't yet complete, it shows great promise)

Ori Berger
Thursday, April 08, 2004

In my opinion, Java is not a much better language than Python or Delphi.

Yes, it has some small improvements over Python and Delphi, but also has disadvantages.

MX
Thursday, April 08, 2004

Other than curly braces, what *language* features give Java an advantage over Delphi?

Checked exceptions?

Java-the-platform has a few advantages over Delphi, almost none of which apply to writing Win32 Shareware.

Richard P
Thursday, April 08, 2004

I don't think anyone advocates Java for win32 client side, either the language or the platform in the last 5 years or so. SWT may change that eventually, but it hasn't done so yet.

My list: Python. Delphi. C/C++; In that order. (And/or K, APL, Lisp, but that's a different discussion).

Ori Berger
Thursday, April 08, 2004

Richard, you are right.

Java is a "bondage and discipline" language.

This is a big advantage in some contexts - for example, when you are working in a large enterprise, with many teams writing different programs which access the same database, etc.

However, for shrinkwrap software development I belive Java has more disadvantages than advantages.

MX
Friday, April 09, 2004

*  Recent Topics

*  Fog Creek Home