Microsoft Admits Passport Security Flaw

[Urban Ranger]

Originally posted by MichaeltheGreat
"Web services" are just a small aspect of .NET - there's really no reason not to use it for standard desktop applications, n-tier, or web apps. J2EE also addresses web services, which really are (IMO) still at the stage of being a solution looking for a problem. .NET is much more about being a cross-platform capable operating environment, without being dependent on "The mother of all languages" nonsense.

I thought that was Ada?

Originally posted by MichaeltheGreat
Java is hardly a panacea - it's lots of fun to want to make use of features in 1.3 or 1.4, while knowing some of the devices you want to support only have 1.1 or 1.2 compatible JVMs. Java still has it's place - I wouldn't try writing game apps for my Nextel phone in .NET for another year or two.

Not to mention that Java does it's "one size (almost, usually, well, more often than not) fits (almost, some of the time) all" by compromising both on speed and on implementation. GUI elements in Java on Windows suck compared to native Windows elements, regardless of whether you use the M$ or Sun JVMs. Java interoperability with languages like C++ is problematic, and sometimes just painful.

That's a price to pay for running bytecode instead of native code, it's also a price for crossplatform interoperability. Java is a lot more secure however, it is a lot harder to breach Java security than, say, ActiveX.

Originally posted by MichaeltheGreat
It frees you from DLL-hell by providing excellent versioning tools. Each app can specify versioning behavior of its components by default global behavior, at the app level, or at the level of each component. Automatic updating via remote server is easy, and won't break anything else, even if the components being updates reside in the global assembly cache.

Versioning is nice, but Unix has excellent versioning tools for quite some time. There are also some great third party tools available for Wintel boxes.

Originally posted by MichaeltheGreat
Inheritance and other OOP features and memory management is fully supported in all .NET compliant languages, including stuff like COBOL.

COBOL? You mean they got COBOL under .NET?

Originally posted by MichaeltheGreat
Objects written in one .NET compliant language are seamlessly compatible in all respects with objects written in any other .NET compliant language, so you can program in your preferred language or use the language tool best adapted to what you're doing. You also no longer have to care what language 3rd-party components or assemblies are written in, there are no compatibility issues.

That is the gist of COM IIRC, though ORB does it better.

Originally posted by MichaeltheGreat
Dependence on the Windows registry and Win32 API calls is completely eliminated, so all .NET apps are fully compatible with all Win versions, if they're running the .NET framework.

Isn't that just another layer on top, acting like a translator for native Windows calls?

Originally posted by MichaeltheGreat
Memory leaks are eliminated by garbage collection, which can be invoked manually.

Is it efficient? Garbage collection is great in theory, but if the implementation is broken, you might as well not have one.

[Promethus]

I want a (free) T-Shirt that say's:

I Was Threadjacked by MtG!

[faded glory]

Thinking of getting VB.net..over 6. Im not worried about my current programs tho. Although, i know theres comp. layers built into .net for 6 all they way down. With all code.

I dont like programming. Too time consuming. Too logic driven and mundane. Im not into either. But its fun to try

[MichaeltheGreat]

Originally posted by Promethus
I want a (free) T-Shirt that say's:

I Was Threadjacked by MtG!

Sure. Actually, Asher started it, I'm just taking up his slack. And unless the FTC decides to do something about it, there's not much of an issue. I wouldn't rely on passport from either end of the transaction, but that's just me.

[MichaeltheGreat]

Originally posted by faded glory
Thinking of getting VB.net..over 6. Im not worried about my current programs tho. Although, i know theres comp. layers built into .net for 6 all they way down. With all code.

There's a tool that suggests changes, but VB 6 code is not compatible in several respects with .NET code. VB 6 compiled objects - ActiveX servers, etc. are compatible since .NET puts a wrapper on all COM objects, but many of your standard coding practices from VB6 and earlier get you in trouble with .NET. Basically, VB had to grow up a bit as a language, particularly with respect to OOP.

[Asher]

Originally posted by Urban Ranger
That's a price to pay for running bytecode instead of native code, it's also a price for crossplatform interoperability.

.NET gives you more options instead of just "running bytecode". You can have it run natively, run through the .NET CLR, or have it do a JIT compile.

Java is a lot more secure however, it is a lot harder to breach Java security than, say, ActiveX.

What, specifically, makes Java more secure than .NET? I just find it odd you can make a blanket statement like that when you admit to not using .NET yourself, and even thinking it was "all about" web services...it seems like you're digging for excuses to dismiss it.

Versioning is nice, but Unix has excellent versioning tools for quite some time. There are also some great third party tools available for Wintel boxes.

That's not exactly what MtG meant. It's easy to have a versioning app to keep track of all your versions, but with .NET, things like DLLs can be kept locally for each program seamlessly so if it depends on a specific version of a DLL, it can do that without interfering with everything else.

Isn't that just another layer on top, acting like a translator for native Windows calls?

Not all instructions need to be translated, but that's the jist of it if you run it entirely through the .NET CLR. Again, there's different ways you can build the app too.

Is it efficient? Garbage collection is great in theory, but if the implementation is broken, you might as well not have one.

It's on par with Java's from what I've seen with .NET 1.0, but 1.1 (which I haven't worked with yet) has both "performance" increases, including garbage collection, and security changes.

[MichaeltheGreat]

Originally posted by Urban Ranger
I thought that was Ada?

Javaphiles tend to pedestalize Java to an equally ridiculous degree. It's probably not coincidence that Java (but not written in true OOP form) is DoD's replacement of choice for ADA.

That's a price to pay for running bytecode instead of native code, it's also a price for crossplatform interoperability. Java is a lot more secure however, it is a lot harder to breach Java security than, say, ActiveX.

ActiveX is also 10 years old, and pretty much irrelevant except to the extent of legacy code. IOW, for me it's irrelevant, it's not for the sysadmins who have legacy codebases. M$ has issued numerous fixes of ActiveX security issues over the years.

Versioning is nice, but Unix has excellent versioning tools for quite some time. There are also some great third party tools available for Wintel boxes.

Unless I'm in control of all boxes in all tiers running Unix, those tools don't do me much good. Same with the third party tools - if they're dependent on end user implementation, I'm screwed, and if I have to buy the tools and design my app to include them and force their implementation, I'm more screwed. .NET solves the problem, and all I have to worry about is designing whatever versioning policy I want. And I can change it later. 3rd party tools also don't let the same file names to exist in the same folder and have the app reliably find the right one. With .NET, I can have ten versions of the same file in the Global Assembly Cache, and if the user screws around and deletes one, the app will look for the correct version in the app's private cache, or download the correct one again. It's virtually unbreakable, no hassle, and free.

COBOL? You mean they got COBOL under .NET?

Not M$, but there's a 3rd party implementation. It makes sense if you're gradually migrating an existing COBOL code base that is too large to fully migrate in one step. The IRS, for instance.

That is the gist of COM IIRC, though ORB does it better.

COM never attempted to address the compatibility issues of various languages, such as string handling. It did allow components to be developed in different languages, but the developer had to account for the possibility of interacting with components written in different languages.

Isn't that just another layer on top, acting like a translator for native Windows calls?

It goes beyond that in a couple of ways, but in essence it's an abstractor and mediator (for backwards compatibility) Going forward, it's the effective replacement for the registry and Win32API. However, if your apps compile once and install the compiled CLR, instead of JITtering, then the performance hit is nowhere near what you'd expect.

Is it efficient? Garbage collection is great in theory, but if the implementation is broken, you might as well not have one.

In .NET 1.0, garbage collection is efficient enough for most people most of the time. The real gripe is that you have to do some customization if you need to prioritize recovery of resources. You can call garbage collection globally at any time (say after writing a file to disk or posting changed database records back to your ADO object), which is nice when needed, but you have to do a little tweaking if you want to mirror the effects of object destruction. It's not broken by any means, just not the instant cure-all, no thought required.

I haven't seen how .NET 1.1 improves it yet.

[Angelo Scotto]

Originally posted by Michael the Great
Although M$ originally was going to call it COM+, it made sense to rename it, as the similarity to COM is minimal.

Are you sure of this? COM+ exists and is simply an enhancement of COM, i believe that the original name of .NET was COR (Component Object Runtime) to underline the difference with COM

Originally posted by Michael the Great
Java still has it's place - I wouldn't try writing game apps for my Nextel phone in .NET for another year or two.

Why not? the Compact Framework has reached the RTM version and i'm using it a lot (ok, it lacks a lot of features
respect the full framework but this is true for the Java Micro Edition also IIRC)
One of the thing i think is great in Java (i know i'm probably the only one to think so since even Sun lost interest in it... ) is the applet support (you don't have to install programs nor update them when there's a new version , just point your browser and go), it's a pity it was so underrated.

Originally posted by Michael the Great
The independence from Win32API and the registry, plus the specs of the MS Intermediate Language will allow development of non-Windows .NET frameworks, giving platform independence a la the JVM, but with a lot more optimization.

True, Mono for example, is great: even if it's still not complete it runs my .NET programs (developed and compiled with Visual Studio under WinXP) smoothly (obviously as long as they don't use WinForms but i can use Gtk# if i'm interested in the GUI)
And probably Rotor is even better, i just don't have a FreeBSD or a MacOS to make the test...
it's strange to launch an .exe executable or to link a .dll under Debian, anyway it works...

Originally posted by Urban Ranger
You can't really compare .NET and Java though, because .NET is about "Web services" (whatever that means) and Java is about portable, write-once run-many, code.

Not really, C#/.NET is about Web Services exactly as Java/CORBA is about Web Services (as MtG said J2EE has a huge section about WS).

Originally posted by Urban Ranger
That's a price to pay for running bytecode instead of native code, it's also a price for crossplatform interoperability.

I disagree, Java bytecode has been poorly designed from start: it is too much "Java-centric" as it is showed by the fact that Java is the only language (excluding VB) which can be totally decompiled and by the small number of languages which targets the JVM aside from Java (a lot of languages which claims to compile to bytecode just translate the language in java source and then compile it...)
The IL instead is more "neutral" and allows to build compilers for new languages. But there's more, differently from Java the whole framework is designed to support the development of new languages which compiles to IL. (i'm talking about the Emit namespace)

Originally posted by Urban Ranger
Versioning is nice, but Unix has excellent versioning tools for quite some time. There are also some great third party tools available for Wintel boxes.

I'm not sure we're talking of the same thing:
I don't know Unix, but Linux also has problems with external libraries, they don't call it "DLL Hell" but "Dependency Heck" but the problem is the same.

Originally posted by Urban Ranger
COBOL? You mean they got COBOL under .NET?

Someone even ported Visual Basic!!!

Originally posted by Urban Ranger
That is the gist of COM IIRC, though ORB does it better.

No really, .NET is definitely more than COM:
COM is a component model that is almost completely based on shared conventions rather than on a shared execution engine.
Microsoft started planning a companion runtime for COM providing common runtime services for COM programmers, it was originally called COR (Component Object Runtime), then MS took COR further than the original companion runtime thingy and proposed a general-purpose virtual execution environment which is todays .NET (Ok, technically it is the CLI, .NET is simply the commercial implementation of the CLI done by Microsoft... )

Originally posted by Urban Ranger
Isn't that just another layer on top, acting like a translator for native Windows calls?

Well, Java for Windows isn't a translator for native Windows calls? and Java for Linux isn't a translator for native Linux calls?
The standardization effort of MS (which is not just the submission to ECMA/ISO but also the release of Rotor as shared-source) gave results:
Now i can run Mono on Linux (and also dotGNU's Portable.NET if i care) and Rotor under FreeBSD or MacOS X.

Aside from the things MtG said C#/.NET has also a lot of other interesting things respect to Java:

Delegates, Attributes, Application Domains, Emit, Preprocessor Directives, Events, Asynch methods, but since this thread is now officially hijacked i don't want to move ulteriorly away the discussion...

[Asher]

Angelo Scotto: Please don't feel discouraged, the threadjack certainly salvaged the thread and is quite informative.

[MichaeltheGreat]

Poor UR - now it's three on one.

[MichaeltheGreat]

Originally posted by Angelo Scotto
Are you sure of this? COM+ exists and is simply an enhancement of COM, i believe that the original name of .NET was COR (Component Object Runtime) to underline the difference with COM

The .NET group within M$ got the name first, so the first hints about it were as COM+. Since it wasn't going to be ready, and COM needed to have various functional extensions to go along with the release of Win2k, that stuff became COM+ 1.0, and the original idea was that what we know as .NET would be COM+ 2.0. Then that idea was scrapped.

It would seem weird if M$ considered COR as a name, because it's too similar to CORBA and would sound to some like an imitation.

Someone even ported Visual Basic!!!

With the .Net version's additions to the language, it's actually a very nice development language. I find I can prototype stuff in it 2-3 times faster than C# and really not lose any functionality, since my SSL socket handlers are 3rd party tools anyway.

[Angelo Scotto]

Originally posted by MichaeltheGreat
The .NET group within M$ got the name first, so the first hints about it were as COM+.

Oh well, it's not so important, i learned about the COR thing browsing the Rotor source code (there are still a lot of fuctions referring to CLI as COR or Component Object Runtime), digging a bit on the net i found the following link which explains that we both are right :
http://www.awprofessional.com/catalo...-2FCF584740B5}
It seems that .NET changed a lot of names: first it was COR, then Lightning, then COM+2.0, then NGWS and finally .NET (It must have been hard to find a name for it... )

Originally posted by MichaeltheGreat
Poor UR - now it's three on one.

It's just because UR still have to try it...
Come on, join our side...

Originally posted by Asher
Please don't feel discouraged, the threadjack certainly salvaged the thread and is quite informative.

Nah, i think we already made our point