Re: Back to VB6 and .NET

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Feb 5, 2:38 pm, dpb <n...@xxxxxxx> wrote:
Robert Conley wrote:
On Feb 5, 1:51 pm, dpb <n...@xxxxxxx> wrote:

But, now we're talking about here and now, not 20 or 30 years ago, and
whether to move from a NT- or similar era boxen to the latest flavor of
the month. I don't see them as equivalent questions as then. If, as
another respondent has noted, it becomes a question of hardware/os
incompatibility of drivers for an old MS OS, there's always the
expedient of the competing OS and compatibility layers.

You make a good point with competing OSs. The big deal of backwards
compatibility is that once a vendor breaks it; its customers are now
free to examine other solutions.

I think that the big sea change will come if virtualization becomes a
big deal for OSs. If OSs can virtualize older OSs then it may make the
job of supporting a setup over decades a LOT easier. Especially if
standardized connectors and protocols continue to get stronger (like
USB, Firewire, etc). I think MS is definitely paying attention to
Apple's abilities to run OS9 and windows programs along with VMWare. I
know having Virtual PC through our MSDN subscription made technical
support of our older version a magnitude easier.

The solution for us has been the standard language w/ the Tcl/Tk UI and
other mostly open-source solutions for the other pieces such as the
communications, etc. -- this provides solutions that, w/ a modicum of
care, are source-compatible on the two major OS flavors of the day and
nearly software vendor independent.(1)

(1)At the expense, of course, of some features of vendor-specific
environments that _can_, in certain circumstances, aid in initial
programmer productivity. It has, however, become apparent to us that
the long-term cost of the specific solution is far greater than the
initial cost; hence the emphasis on Standard-compliant language(s) or
the open source route so that one can freeze a build if it should become
necessary.

--

Open Source is nice but not a panacea. You can't control the rate of
development nor always have the time to make needed changes to the
library. Also a given vendor, despite being proprietary, may just have
the best solution. The trick is to design for change not for
stability. Assume nothing is going to remain for the long term.

My own solution is to design everything so it lies behind an
interface. That way even if technology radically changes in an area I
isolate the problem to one area of the code. The changes are
implemented behind the interface and the rest of the software doesn't
have to be changed.

Similar to the idea that you don't have rewrite your application
graphics code every time you change video card. Everything is hidden
behind a driver. Well I insulated our software from the underlying
API. Which is why I spent my time making compatibility objects
for .NET. This way the code I copy over is still the same code calling
the same interface but now there is .NET code behind it.

Using interfaces isn't taken to extreme. For example our main input
screen for making shapes lies behind an interface. It used in a lot of
different areas and by a lot of different shapes. Any change to the
form I don't want to cascade throughout the program so I keep it
behind an interface.

But I also have a setup dialog that a user can use for a few options
in the setup screen. I just call it directly. It is so simple and
limited it not worth the overhead of an interface. However the deal is
that the all my "commands" use a command interface. So the setup
screen executes the SetupOptionCmd object which then setups up the
form, displays it, and then retrives the values stuffing it back into
the object containing the options. But the form itself it not behind
an interface like the shape screen.

This is coupled with Unit Testing to pinpoint where behavior is
changed. See http://en.wikipedia.org/wiki/Unit_testing if you don't
know what it is. One change I had to make was to always write tests
while I am coding.

The combination of using interfaces and Unit Testing allows me to
manage change even when moving to a platform as complex as .NET.


.

Relevant Pages

  • Re: Problem about ppp -nat
    ... ipfw firewall, ... Just setup your fw of choice as if the tun0 device is the external device and leave all the nat stuff completely out of it. ... My Internet interface is rl0, ... # /etc/rc.d/routing restart ...
    (freebsd-questions)
  • Re: Converting crypto map to unnumbered VTI
    ... Cisco IOS Software, 2800 Software, Version ... DRAM configuration is 64 bits wide with parity enabled. ... capture debug isakmp sa with this setup ... The VTI tunnel interface will not come up until the SA are built (i.e ...
    (comp.dcom.sys.cisco)
  • Re: arch/xen is a bad idea
    ... >> work it is long term to keep an Linux architecture uptodate. ... > We're actually very well setup to handle this, ... > interface that gives good performance. ... > virtualization. ...
    (Linux-Kernel)
  • Multiple NIC OS/2 PEERLAN help please
    ... For the first time I'm contemplating a workstation on a substantial size OS2 PEERLAN local network which I wish to connect to the Internet individually but not to introduce IP interface to the whole LAN. ... It works beautifully now by swapping the TCP/IP LOCAL setup between LAN0 as either a DHCP connection when connected physically to the supplied ADSL modem, ...
    (comp.os.os2.networking.misc)
  • Setup a wireless network experiment environment
    ... through binded ath0 interfaces via adhoc network NET2: ... ok to setup such an network, and which keys, ARP tables, proxy ARP, ... subnet on local interface is no longer possible, ...
    (comp.os.linux.networking)