Printable View
Of course someone is going to break it. Let's face it even software like 3D Studio has been broken.Quote:
I'm not saying that it's going to be unbreakable : no security measure is unbreakable.
It's going to deter the general hacker though who knows how to decompile C# code.
It provides some protection - not 100% because no solution is 100% - but it'll offer the same kind of protection that you'd get with assembler if not better.
Darwen.
In the world of Hacking, .Net is a cheap date.
ahoodin
All I can say is that I'll believe it when I see it. One line of code added to the source doesn't sound like encryption to me. Your dll might not be easy to decypher, but the source gets compiled to a seporate file, so I don't see any protection there. Seems to me that if the runtime ("framework") can read and manage the file, then nothing is encrypted.Quote:
Originally Posted by darwen
The above arguments will be what you'll have to deal with when selling your solution. You might have to make a sample app that people can download and try, and that they can run through the various decompilers out there to see how it holds up.
I'm sure we'd all like to see what you've accomplished. When do you estimate your dll will be ready for use?
Getting back to the original point: will the relatively low-level Win32 API survive in future editions of Windows? Are all programmers destined to move to managed environments?
Historical evidence suggests no.
Managed environments is not a new concept. It has been around for as long as compilers. Any interpreter is essentially a managed environment, and interpreters and compilers evolved at around the same time.
Take Lisp. In the 80s, Lisp advocates claimed their environments to be superior. Although they didn't use the M-word at the time, their argument was essentially that Lisp was a managed environment. Yet, Lisp, powerful as it was, did not become the ubiquitous standard that its fans predicted.
The modern arguments rely on Moore's law and ever-faster hardware to excuse the extra overhead for a managed environment, but the hardware improvements have been on-going for decades. What is it about right now that makes it reach the threshold where users are ready to sink the cost?
The move from 2nd generation languages (like ASM) to 3rd generation (like C), or from procedural to OO languages, is not analogous. These moves were precipitated by improvements in compiler technologies, not faster hardware.
There is a class of software where managed environments are particularly well suited: Enterprise Solutions and server/thin-client based applications. For these types of apps, it turns out that the cost-savings from a well-managed environment, in support, maintenance, reduced outages, etc, outweighs the cost of improved hardware to get comparable performance. This advantage increases as the performance hit from the environment is reduced.
This is the space where Java, with J2EE, has done well, and where .Net is primarily aimed -- not coincidentally, since there is a lot of money in this space. (As an aside, .Net is going to blow J2EE out of the water, unless Sun gets its act together, but that is a different discussion).
For thick-client development, users will continue to prefer software that makes the most of the available hardware -- including, perhaps especially, peripherals. This is true for games, media-players, browsers, screen-savers, multmedia apps, and even to some extent productivity applications like spreadsheets and word-processors. This implies that there will always be a market for software that is written at a low level and unmanaged.
As another historical exhibit, consider Java. It has been argued here that Java is used to run thousands of commercial solutions. Correct, but that was not Javas original promise. The original promise was, "write once, run everywhere," implying that it was aimed at writing client applications that could run on any desktop. This promise has only delivered to a small extent, not because it wasn't possible, but because such apps were not competitive.
The users have spoken. When they buy a $1,000 computer, they don't want a $900 computer.
All that does not mean that Microsoft will not enforce managed environments. Avalon sure sounds managed, from what descriptions have been published. It is unclear whether client developers will have direct access to a lower level API.
If this is their approach, it will be a mistake. They will lose a competetive edge over other platforms. Business software may be where the money is, but as a software company that took over via the desktop, it seems odd they would give it up willingly.
Firstly, I wish I'd never mentioned my little solution. You'll have to wait around for it... it depends on various things like me writing the manual and setting up a company. I think you'll be pleasantly surprised...
Anyway back to the big posting by hankdane
I disagree. I could run Z80 machine language fine on my ZX Spectrum going back to 20 years ago and even though C compilers were available, no-one used them BECAUSE THE CODE THEY PRODUCED WAS TOO SLOW.Quote:
The move from 2nd generation languages (like ASM) to 3rd generation (like C), or from procedural to OO languages, is not analogous. These moves were precipitated by improvements in compiler technologies, not faster hardware.
First off, LISP is a functional language (no loops).Quote:
Take Lisp. In the 80s, Lisp advocates claimed their environments to be superior.
Secondly the language was deficient. How many millions of close brackets do you want at the end of your application ?
No-one (except NASA from what I hear) would consider writing anything but small applications in LISP.
LISP had the advantage of being mathematically provably correct. Which is why NASA used it for control systems. I think, don't quote me on that.
Microsoft will for the forseeable future dominate the desktop OS market. Why ? Because there is no other graphical operating system which is as easy to install and configure.Quote:
If this is their approach, it will be a mistake. They will lose a competetive edge over other platforms.
Linux isn't graphical or easy to set up so let's discount that first.
To my knowledge there has only ever been one contender for a graphical operating system in direct competition with Windows : IBM's OS/2 in the early 90's. It was so bad, so buggy and generally so awful that IBM eventually gave up on it.
Bear in mind Microsoft haven't made a single penny out of .NET. And never will. It's a free technology which has been developed by Microsoft at I would bet a cost which runs into at least the tens of millions of dollars.
What is the purpose of Microsoft moving developers to using .NET ? They still have a commanding position in the desktop operating system market, they still produce the best selling development tool (DevStudio).
They could keep on using C++ ad infinitum. All of the new features of Longhorn could have been written using C++. People would still upgrade and buy it.
Maybe - just maybe - they want to make life easier for themselves development-wise. And if they're making their lives easier by using it, why shouldn't we ?
In actual fact can you imagine the ability to decompile the OS using things like Loetz Roeder's reflector to see exactly what is going on ? I already use this tool to find out how things are done in .NET (just like I use the MFC source in DevStudio to find out what's going on in MFC). This to me as a developer would be very, very useful.
Now you're going to say that that's going to allow someone to change operating system dlls. That's entirely up to them - if they want to be idiotic.
I really can't see how the development of .NET is going to make Microsoft any money.
Sales of DevStudio would certainly have continued just fine if it just supported VB and C++.
Maybe it is all about enterprise development - but as all the compilers etc are free and you have really good development environments like SharpDevelop if you want to develop .NET for free you definately can do.
Maybe we're all too cynical and it's just Microsoft saying "hey, we have more money than God, but rather than trying to make money out of .NET we really think you should have a look at it because we think it's really great".
Darwen.
I've just thought of something : maybe it really is Microsoft's answer to Java and they want to control the world.
At least this is good for us as developers - we have more languages to choose from when we're developing.
In my mind the difference between a software engineer and a software developer is that a software engineer considers the options available and picks the most appropriate.
A software developer sticks to one language and just uses that. They don't want to know about new technologies unless they are forced to.
If we have more tools to do the same job surely this is an advantage, not a disadvantage. Yes we have to learn more, and we'll have a greater seperation of the really good people from the ordinary but is this bad ?
I would say that the present situation is fantastic. Providing you're prepared to learn all the technologies in the field of development that you're working in (I'm primarily in desktop development) then you can pick the best tool for the job.
Yes we can always say that C++ is better at certain things than .NET. Yes we can say that Java is better than .NET at some things and .NET better at other things than Java. We can also say that Assembler is better at certain things than C++.
These are all tools which we now have at our disposal. It's really just up to us how we use them.
Darwen.
And if I were doing website development ? I'd use Apache with PHP and Java because it's free. OK ?
Darwen.
Maybe I don't understand what you are saying, but this seems to confirm my point.Quote:
Originally Posted by darwen
Stipulation: Developers will not move to a higher-level language until the compilers are good enough - regardless of processor speed.
Case in point: Developers preferred assembly to C-code for the Z80, because the C compilers were not good enough.
Picking on Lisp is not relevant. The point is they had a managed environment. They had garbage collection and advanced debuggers. Lisp programmers never had to worry about stack overflow, memory leaks or buffer end-runs. The environment took care of that stuff for them.Quote:
Originally Posted by darwen
The result is that Lisp programmers spent more time thinking about their design, much like your experience is with .Net. The difference is that they did this several decades ago.
I don't think Lisp failed to become popular because programmers worried about too many parentheses. (Not brackets). I think it failed because of the overhead of the environment.
So Darwen, what you're saying is .NET beats C++ as a language, because you don't like some of the libraries that have been written for C++?
This is a bit like saying French is better than English, because you're read some books in English that you didn't like.
It's clear from your comments that you aren't differentiating between the language and the tools written in the language.
C++ as a language knows not one bit about databases or XML. The .NET language has no knowledge of these things either.
What both languages do is allow you as a programmer to use libraries written in these languages to leverage concepts beyond level of the compiler.
And yes, you're correct, 15 years ago people were engaging in language wars without knowing the difference between a language and a library. I was reading such stupid arguments almost 30 years ago also.
OS2 was nothing but Windows For WorkGroups, tweaked a bit and broken. It wasn't so much a contender as a gimp cousin.
As to Microsoft not making any money on .NET, how might I legally obtain a programming environment for it, for free? Doesn't Microsoft want money for the OS and the compiler environment?
What .NET does do is take us into OS incompatability. By pushing a non-standard language onto the market, they're insuring that code written in it, must run only on the Microsoft platform. This helps lock in a market for Microsoft and Microsoft compatible hardware. It's their attempt to stifle Open Source and block an easy migration to Linux or Unix.
The whole point is to minimize the free market in this respect and limit choices.
To deal with Jack's points first :
.NET isn't a language. It's a technology. And as a technology it does know about database access. The Common Library Reference is a standard - and must be supported by all .NET compatible languages. This is a common misconception. C# is a language. VB is a language. C++ is a language. .NET is a standard technology which C#, VB.NET, C++.NET, Delphi.NET conform to.Quote:
C++ as a language knows not one bit about databases or XML. The .NET language has no knowledge of these things either.
What about Mono then ? It's an open-sourced .NET implementation for Linux/Unix systems.Quote:
What .NET does do is take us into OS incompatability. By pushing a non-standard language onto the market, they're insuring that code written in it, must run only on the Microsoft platform. This helps lock in a market for Microsoft and Microsoft compatible hardware. It's their attempt to stifle Open Source and block an easy migration to Linux or Unix.
Also Microsoft are rumoured to be making the source code for .NET available soon. At any rate it's decompilable. So that's pretty open sourced if you ask me.
No I'm not saying that at all. I'm saying that .NET is better at object orientation and other things than C++. C++ is better than .NET at other things : most importantly interfacing with existing technologies such as DirectShow, Win32 which will eventually be moved to .NET. C++ is faster than .NET, but not by as much a gap as you would expect.Quote:
So Darwen, what you're saying is .NET beats C++ as a language, because you don't like some of the libraries that have been written for C++?
.NET also supplies functionality which just plain doesn't exist in C++ : reflection is a typical example of this. I can look at a class type and get information about all of its members. This is a pretty simplistic view of reflection but it's a good start. Also .NET has the facility for attaching attributes to classes, methods, properties, events : something you can't do in C++ without writing a similar framework (because no reflection).
Now to hankdane's original point :
My point was these moves were made possible by faster hardware e.g. going from the ZX Spectrum to a 286.Quote:
The move from 2nd generation languages (like ASM) to 3rd generation (like C), or from procedural to OO languages, is not analogous. These moves were precipitated by improvements in compiler technologies, not faster hardware.
Finally I said this :
I will continue to use C++ for certain things. I will also continue to use Assembler for speed. But I love .NET for the vast majority of my programming and will continue to use it.Quote:
Yes we can always say that C++ is better at certain things than .NET. Yes we can say that Java is better than .NET at some things and .NET better at other things than Java. We can also say that Assembler is better at certain things than C++.
These are all tools which we now have at our disposal. It's really just up to us how we use them.
Darwen.
Then I don't see the point in comparing it to C++.Quote:
Originally Posted by darwen
Why compare a non-language to a language? You lost me there.
I agree with you that some of Microsoft's technologies written in C++ are horrible, but I don't see that as a reasonable indictment of the language they were written in.
C++ interfaces with Win32. The .NET languages are built upon the .NET technology which presently calls Win32.
In Longhorn .NET will directly call the operating system. Win32 will still exist, but in parallel with .NET and not underneath .NET.
So therefore in discussing the future of Win32 you have to relate using C++ calls to Win32 to write applications with using .NET to write applications.
Darwen.
What's going on under the hood then? Has Microsoft simply refined the underlying C++ objects and exposed them directly to .NET, as opposed to converting them to C style Win32 calls?Quote:
Originally Posted by darwen
Something like that. Win32 is built as an interface to the raw OS calls. In Longhorn .NET will make raw OS calls instead of calling through Win32. If anything the OS will be changed to make it easier for .NET to do so : I.e. rather than the OS favouring Win32 it'll favour the .NET framework.
As far as I can understand.
Darwen.