Date: Thu, 1 Feb 2001 22:39:25 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jcm@FreeBSD-uk.eu.org (j mckitrick) Cc: freebsd-chat@FreeBSD.ORG Subject: Re: software development tools - microsoft and unix Message-ID: <200102012239.PAA17765@usr08.primenet.com> In-Reply-To: <20010201183650.C76922@dogma.freebsd-uk.eu.org> from "j mckitrick" at Feb 01, 2001 06:36:50 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> It seems if there is one thing Microsoft does well, it is providing powerful > development tools. If you ignore the fact that they use proprietary > language extensions, what is the problem with these tools? They have taken > the industry by storm, and even Kdevelop has tried to clone the Visual > studio look and feel. > > What have I missed? Is there any real flaw in the tools that explains why > similar tools have not appeared as open source in the unix world, or am I > just unaware of them? There are flaws in the system to which the tools are targetted, which /partially/ explains why similar tools have not appeared. The number one problem with Windows is that you can not post-mortem a failure. Without a core image at the time of the failure, you can't get a stack traceback at the failure point. In general, the Windows tools handle this by having the programmer remember where the failure was (step N), and repeat the process up to just before the failure (step N-1), and then examine things. This failing, by itself, drove simple debugger restart, region breakpoints, and similar debugger innovations. A secondary problem with Windows, which is _not_ common to all versions (which is why many shops choose to develope on NT), is that it is really not a true protected mode OS. Because of this, there are regions where it is possible for an application to corrupt the system itself, and cause a failure. At that point, knowing the start of the region where the failure was (which the Windows debugger normally tracks as a one-behind, through call traps) really does you no good: you are back to remembering the step of the failure, and going back to step N-1. A similar problem is a lack of failure on NULL pointer dereference, which is generally one of the most common coding errors -- most particularly, by the people who learned to program in environments where it is not uniformly fatal. Another Windows problem is the same as a VMS problem, which is that compilaton with debugging results in a serious preterbation of failure cases. In VMS, it was quite common to link something with debugging, and have the problem disappear. In general, this means that array overflows of stack variables, which would normally trash the stack to fatality on a UNIX system, and similarly, any dereferences which were out of data range, but which now return debugging data, now that the data space has increased, will shield another common programming mistake. This mistake is quite common for new programmers, who are not used to the concept of an option base of zero, or of NUL termination of strings requiring array space in the array (string) declaration. Finally, there is also the historical (and now defunct) competition in the tools space, which has driven them to be better than each other, where users would not have demanded it (and here we see a nice example of why the ability to wield monopolistic power in a market is bad for consumers). If I had to characterize the existance of such tools in one sentence, I would say that they were compensation for the failings of the target OS. > Are there any unix tools that are evolving as quickly, that allow easy > creation of COM objects, GUIs, etc.? There are some. Several good examples have actually been forced out of business (ask Warner about Object Interface Builder) through petty in-fighting among UNIX vendors. The big reason these thing don't show up often in Open Source is their relative cost, and compared to other tools in Windows, which the naieve will call "good tools", good tools in UNIX are very, very expensive, even relative to the cost of an OS license (BattleMap and Interactive Developement Environment's products are examples; for a single workstation license for BattleMap in 1990 or so, you were looking at $50,000 US). HP has a number of moderately good, if primitive, tools; so does DEC, though they are rather limited anywhere but VMS (guess that's Compaq, now). Web Methods has a number of tools; Rational software does as well. There are a couple of IDE offerings coming up in the UNIX space that are much cheaper, and appear as first-generation tries at a real IDE (look in the ports tree under developer tools for two of them). There is also a third generation/first generation hybrid, which is the Borland port of their environment to Linux, which I have not seen catching on. For the moral equivalent of COM object creation, etc., there are IDL compilers available for UNIX systems; they generally require, if your COM object equivalent is really an ActiveX control equivalent, use of MOTIF as the target for the code generation. Probably you should go to a search engine and look for the permutations of the terms "code generator", "code generation", "IDL", "IDE", "CASE", "UML", etc.. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102012239.PAA17765>