Re: VB6, VB2005, or Something Else?

Michael B. Johnson wrote:
On Wed, 12 Apr 2006 07:50:16 +0200, Andre Kaufmann
<andre.kaufmann.bei@xxxxxxxxxxx> wrote:

Michael B. Johnson wrote:
On Tue, 11 Apr 2006 13:12:31 -0500, Paul Clement
<UseAdddressAtEndofMessage@xxxxxxxxxxxxxx> wrote:
[...]
object oriented. You mean to say they *couldn't* have implemented polymorphism
in the existing language? Why not?

Procedure Overloading? Why not?
They could have done this. But this would have IMHO broken compatibility with older VB code too. COM doesn't support all that features.

You don't think name mangling could have been implemented in the back end
runtime linker/interpreter/CLR, similar to C++? I'm not so sure you understand
how compilers work. You don't think that name mangled procedures could have been
exposed via COM?

Sure. But this would be IHMO a somewhat weird solution. The compiler generates the name mangling under the hood, or if you export these functions in a DLL. However you cannot use them safely from another language or other compiler vendors. There's unfortunately no name mangling standard, since this would allow the typesafe exporting of functions. :-(((

So for this COM name mangling Microsoft would have to define a standard.
Older compilers would see the mangled names only. If you would implement these mangled interface methods you would have to use the mangled names.
As soon as you update to the new compiler it would either break compatibility or would have 2 name mangling hierarchies - internal and COM name mangling - which surely would lead to let's say interface mangling hell - in analogy to the DLL hell.

A better idea IMHO would have been to add more type information as in ..NET and add another object model, not based on COM but compatible to it. Let's say a native .NET ;-)


Or if necessary, you don't think that backwards compatibility could have been
maintained and .NET made accessible to old code?

100% backwards compatibility, meaning compile all native code to IL code IMHO wouldn't have been possible. No (important) language I know of can do this. Many of them reach a very high level of code compatibility. E.g. the C++ compiler will emit native code, where it's not possible to generate IL code. E.g. assembly instructions. So I would call this mixed mode 100% compatible, which surely would have been possible for VB too.
The only downside I would see is that the GUI part would be hardly portable. A .NET layer would have been needed to be introduced, which IMHO doesn't make that much sense. Delphi for example has introduced such a layer called VCL.NET. It's good to port quickly to .NET. But it's another layer not available for all platforms (64 Bit, PDA, Mono). If I'm bound to a platform (Win32) then I would prefer mixing native and ..NET code.

I respectfully disagree.

If you mean 100% .NET portability then I disagree too ;-)
I you mean reaching a very high level of portability e.g. 99% - then I will agree (to disagree ;-9 )

I don't understand the object model in VB6 very well. Obviously a single class module represents a class (?). But I know the internal

That much is clear: you don't know VB6 very well, or else you wouldn't have
answered as you have. No matter, at least you appear to listen, to be
reasonable.

Adding polymorphism to COM might be possible, but would result in a very ugly implementation - performance and usability wise.

You needn't add polymorphism to COM, you need only add it to the compiler. COM
is essentially an interface, not a compiler.

I rather meant language interoperability. Surely the model could have been enhanced internally. But this would be usable only from inside VB7.
If you want to derive in C# / C++ / Delphi directly from a VB7 object you would have to introduce polymorphism to COM, or whatever that would have been called. By the way - IIRC .NET should have been called something like COM+ ( I know COM+ ).

.NET is all about language interoperability, enhancing the COM model would break compatibility with all languages currently using the COM object model.

You don't think it could adapt to name mangling?

It could have been with the downsides I already posted above.


.NET objects? Why not?
Certainly possible. Though COM objects are reference counted and .NET objects are managed. Which is not quite the same.

What *is* the COM interop, isn't it .NET interfacing to COM? You don't think
that the reverse of the COM interop is technically possible?

Well you can expose .NET objects with interfaces as COM objects and use them from VB6. No problem. But you must know what you are dealing with.

E.g. I have implemented a COM interface passing media data as another COM interface pointer. I used this callback in a .NET application and forwarded the COM pointer to the GUI thread display some statistics.
Although I have discarded the COM interface, which has been wrapped in a ..NET object/interface, memory usage grew and grew.
The reference pointer must have been held by another internal object, which I couldn't release. The references have been release some time later on a garbage collection, but way slower than I passed them to the ..NET application. This is what I meant with > not quite the same <

And VB Classic already
*has* object classes...Why couldn't better backwards compatibility have been
retained? Why couldn't the extensions have been true extensions to the language
instead of a different language?
As I've already posted IMHO true backwards compatibility could have been done by introducing some kind of mixed mode for VB as it's the case for C++.

Ok. Thank you.

Most VB applications are GUI centric. All these applications could only be compiled to native code or only to managed code if you are using .NET controls. By mixing them you would loose the ability to compile to both native and managed.

I'll stipulate for now (without blanket acceptance) that mixed native/managed
code sections in the same application might be difficult to automate for VB, but
maybe provision could have been made for us to choose for each application,
without dropping support for old apps?

Since the C++ compiler does it even on assembly level and you can select for each function to be compiled to IL or native code I think it would have been possible for VB too. The only downside with mixed applications (in C++) is that you must bridge both worlds you cannot use each native code in a .NET application directly and vice versa. (E.g. mixing different objects / embedding / deriving).
But all the parts which compile to IL code directly and don't use pointers and assembly code should interact without any problems. Which should be the case for most of the VB code around.


That shouldn't be an excuse for all the unnecessary changes, but all applications using GUI centric code would IMHO have been broken anyways, even if the language would have been 100% compatible.

Maybe, but dropping support for VB Classic completely sure wasn't a good move.

Agreed.

.NET is a different platform. Compiling the "old" code to .NET is a nice feature but IMHO doesn't help that much. If you are using .NET you are

I think it would have helped gain acceptance for .NET. But the other matters of
EULA, DRM and "*we* own ~your~ data" might need to be reversed.

tied to it -> no way back to native code. There's no single language which is able to do that. Only native .NET compilers would make that possible - IMHO.

I see no obvious technical reason that a hybrid compiler wouldn't be possible. I
see lots of marketing and selfish strategic reasons this was not done. IMHO.

Would be possible. But as I already wrote. You can use and share a library based on the same code with such a hybrid compiler. But I you use the .NET library as you are using Win32 functions in a VB application, you are bound to .NET and you won't be able to compile this application to native code anymore, since the compiler would have to compile the .NET framework to native code. Which is not yet possible.

Regards,
_______________________
Michael B. Johnson

Regards,
Andre
.

Relevant Pages

  • Re: Using Python for programming algorithms
    ... implementation of a language. ... all known Python implementations compile to byte-code. ... Wikipedia says about C that "its design goals were for it to be compiled using a relatively straightforward compiler, provide low-level access to memory, provide language constructs that map efficiently to machine instructions, and require minimal run-time support". ... that very strongly suggests that it was meant to be compiled to native code. ...
    (comp.lang.python)
  • Re: Further evidence MS hasnt abandoned Win32 development
    ... > So what is the advantage of using native code? ... the unmanaged compiler. ... MC++ is your language of choice if you want full control of the .NET ... Gives seamless access to all unmanaged libraries, such as DLLs, ...
    (borland.public.delphi.non-technical)
  • Re: compile+link Fujitsu Linux
    ... ALGOL is a 50 year old language. ... Several implementations on Linux, ... uninstall your production PL/I compiler, ... There are some Java native code compilers, ...
    (comp.lang.cobol)
  • Re: CodeGear wish list
    ... language and this for mac. ... development environment of Apple self, which is cocoa and realbasic, 2 ... compiler that generates native code but uses c# as language. ...
    (borland.public.delphi.non-technical)
  • Re: "STL from the Ground Up"
    ... high-level intermediate language than can interoperate with many other ... If your language lacks expressive features then you cannot write code ... memory management in comparison. ... Mostly because type errors mean that the programmer and compiler disagree ...
    (comp.programming)