Re: VB.NET 2008 not backward compatable?

"Alex Clark" <quanta@xxxxxxxxxxxxxxx> schrieb:
Which type of DLL hell? Sure, you have to keep binary compatibility in mind, but I don't see any reason for a DLL here.

Multiple applications sharing the same DLL can quickly turn hellish if you make alterations, even if they don't break binary compatibility.

There are still some ways to overcome the problem: ".local" files or using the SxS cache:

How To Build and Service Isolated Applications and Side-by-Side Assemblies for Windows XP
<URL:http://msdn.microsoft.com/en-us/library/ms997620.aspx>


How exactly does side-by-side compatibility work in VB6? With .NET, all I have to do is register an assembly with the GAC if I want it to remain even after new releases.

There's also something like an unmanaged GAC, which is localted at "%WINDIR%\winsxs".

See Microsoft Singularity for details. It won't be Windows 8, but it may just make it for Windows 9 or 10. The benefits of a managed operating environment are already proving to be huge.

Which advantages are you thinking of? Windows Vista is pretty perfect, IMO. All i'd look for is a real new approach to UI, which all vendors are currently lacking. Most Linux distributions are still busy with copying the Windows 95 UI and adding transparency to it.

Singularity has nothing to do with UI, and comparing it to Vista is like comparing a carrot to a toaster oven. Singularity isolates every single process, including device drivers, into their own sealed managed environment. MS have already shown that there's a performance benefit, but far more than that is the massive step up in stability. Dodgy drivers or misbehaving devices don't blue-screen the system, they simply get shut off, restarted, or diagnosed.

Well, I saw my last bluescreen in ~ 2001, prior to Windows XP coming out. And yes, I use Windows XP or Windows Vista on several machines. I do not doubt that Singularity or other approaches may have advantages over existing solutions, but I doubt that the benefit for the end user is substantial.

I partly agree. However, the intrinsic WPF controls are still a rather bad remake of the old Win32 controls. Unfortunately Microsoft doesn't use WPF for their applications at the moment and thus there are still some huge problems like faulty ClearType support, etc. However, things will get better when Microsoft is using WPF for their own applications, such as VS and the graphical PowerShell UI.

ClearType is probably the biggest fault with WPF, and they've publicly admitted it - as well as saying they've fixed it for the 4.0 release of the framework. VS2010 will be fully WPF based which is probably what prompted them to address it.

ACK. I consider the current version of WPF still a preview to enable developers to get used to it. However, the huge advantages of WPF will be visible to the user in a few years when huge software vendors adopt WPF.

As for the intrinsic WPF controls being bad remakes of the Win32 controls, this is not really accurate. MS are always going to include the standard Windows controls in the toolbox, because every developer wants (and needs) the ability to make a uniform app that a user can get to grips with easily enough. If I created an app where every button was actually a ladybug, I suspect a lot of computer-illiterate users would have a hard time using it. Why should they have to relearn how to use a GUI just for the sake of my app?

I didn't criticize that they rebuilt the existing Win32 controls, I criticized that the remake had annoying limitations (such as in-place editing in treeview controls, ...) compared to the Win32 controls.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

.