cunningly enough it pretty simple for a trusted application (like, say outlook.net) to create a 'safe' execution environment withing its own process (a separate ApplicationDomain) in which it can run untrusted code.
The current episode of the.NET show is about exactly this. Well worth checking out if you want to be informed about such things.
The CLR won't even load an assembly that contains unsafe methods unless the ApplicationDomain that requests it has the required privilege. Privilege levels cannot be raised, only lowered. The CLR checks both the metadata of the class and the individual opcodes (some of which are specifically marked as unsafe) during JIT compilation and verification (much like a JVM). The assembly will also be rejected if the metadata is innacurate.
From a technical viewpoint, the term unsafe refers to whether the program is known to be safe. Before a program is converted from intermediate language (IL) to native code, there's a part of the runtime security system known as the verifier that looks at the IL to determine whether it's safe to execute. In this context, safe means that the verifier can prove that the IL doesn't do anything unsavory.
well I was paid by Microsoft. I worked in the Visual C++ & Visual J++ teams for some time. I know 1st hand the length that the libraries and SDK teams went to to balance updates to the API and compatibility with existing code.
Very few DOS apps ran correctly? Bullshit. Before win95 shipped, the win95 QA team went to Egghead and bought a copy of every title on the shelves and either made sure that they ran or informed the authors of the bad assumptions they had made in their code and how to patch them. Sometimes the application was directly patched at runtime by the OS. For example some applications would make use of undocumented behavior (like the burgermaster table in win13) that wasn't available on the new system.
you're confusing.NET and Passport..NET is an execution runtime environment and a set of class libraries. Passport is an authentication service..NET supports integrating Passport authentication, but apart from that they're not linked. The idea that all.NET applications require some central information broker is FUD, sorry. RTFM
Microsoft has proven itself openly hostile to the open source world
Yes and no. Microsoft has used the 'Open Source' term in its 'propaganda' (mainly because that's the most commonly used and appropriate term for press releases intended for the layman) but if you read the essence of what they say, their real beef is with the GPL - which makes sense for a company that attaches monetary value to intellectual property.
not that you have the faintest clue fo which you speak, but answer this: can you point out one single significant backwards-compatible issue in any one of the technologies that you mentioned?
Of course they will extend it. I'm sure they're not presumptuous enough to thing that it's 'finished' after the first release.
On the other hand it would be short-sighted of them to make v2 incompatible with v1 for no other reason than it would piss off their loyal developer following immensely. They'll add new features, but I'm pretty sure that old.NET assemblies will still run on the new system. Microsoft has been very careful to continue their binary compatibility up the operating system line (DOS apps ran on win31/win9x, most dos/win31 apps run on NT/2K/XP, etc...) They would lose far more than they could possibly gain by changing this.
How is this situation any different from free software projects using Sun's Java technologies? Isn't this just two sides of the same coin?
On one side you have Gnome intending to use Mono, a cross-platform language and runtime environment based on open standards,
and on the other you have projects such as Apache'sJakarta using Java, a cross-platform language and runtime envionment based on almost open standards.
I don't recall seeing RMS bitching too heavily about Sun's absolute control of the Java language and runtime.what it was that RMS didn't like about it. I wouldn't be surprised if he's just being reactionary for the sake of it.
The LWN Distibution list has a "CD-Based" section. I suggest starting with one of those, configuring it to use swap on a file in/tmp on/dev/hd??, and go from there.
i see, so there's no capability for X itself to render the fonts to the screen, it has to pass the bitmaps back to the client and then the client has to pass the bitmaps back to the server? that seems a bit inefficient especially given that X was designed as a network protocol from the start. excuse my ignorance, i'm just used to windows' TextOut() which renders the font directly into the device context. the communication between the application and GDI consists of just the text, a DC and a font handle. the only way to get the bitmap data for a font is to render it into a DC on your own bitmap.
i don't understand why applciations need to be rewritten in order to take advantage of anti-alaised fonts.
Since I installed Windows XP on my laptop suddenly every character on my screen has been rendered in fully anti-aliased ClearType. I didn't have to reinstall new versions of any applications, or even new fonts, the operating system (or the GUI parts of it) just support it (optionally, of course).
Why can't the xfree86 guys just add anti-alising to the existing font rendering code?
Slashdot Mirror
However, for C++ check out The Lambda Library, it's an extension to STL that, among other things, blows my mind.
all the .NET SDK docs are on-line at msdn.microsoft.com
it verifies the code instruction by instruction. Java VMs do this too. it's pretty simple.
The current episode of the .NET show is about exactly this. Well worth checking out if you want to be informed about such things.
From 'Unsafe at the Limit' by Eric Gunnerson:
I little bit of R-ing the FM goes a long way.i was going to come us with some informed rely, but seeing as I'm a moron, I'm just going to offer this.
a reliable source-management system requires some kind of locking infrastructure, and i don't think that ftp provides such a thing.
i thought you needed some sort of atomic test/exchange method to ensure consistency in such situations?
Very few DOS apps ran correctly? Bullshit. Before win95 shipped, the win95 QA team went to Egghead and bought a copy of every title on the shelves and either made sure that they ran or informed the authors of the bad assumptions they had made in their code and how to patch them. Sometimes the application was directly patched at runtime by the OS. For example some applications would make use of undocumented behavior (like the burgermaster table in win13) that wasn't available on the new system.
you're confusing .NET and Passport. .NET is an execution runtime environment and a set of class libraries. Passport is an authentication service. .NET supports integrating Passport authentication, but apart from that they're not linked. The idea that all .NET applications require some central information broker is FUD, sorry. RTFM
I believe that Sun retains the right to sue kaffe for breach of license. not exactly open.
not that you have the faintest clue fo which you speak, but answer this: can you point out one single significant backwards-compatible issue in any one of the technologies that you mentioned?
ECMA-334 and ECMA-335 were approved by the ECMA General Assembly on 13th December 2001.
Microsoft's .NET Framework SDK documentation answers this question very well.
and why would you switch?
On the other hand it would be short-sighted of them to make v2 incompatible with v1 for no other reason than it would piss off their loyal developer following immensely. They'll add new features, but I'm pretty sure that old .NET assemblies will still run on the new system. Microsoft has been very careful to continue their binary compatibility up the operating system line (DOS apps ran on win31/win9x, most dos/win31 apps run on NT/2K/XP, etc...) They would lose far more than they could possibly gain by changing this.
Anyone know why he "wouldn't like that"?
How is this situation any different from free software projects using Sun's Java technologies? Isn't this just two sides of the same coin?
On one side you have Gnome intending to use Mono, a cross-platform language and runtime environment based on open standards,
and on the other you have projects such as Apache's Jakarta using Java, a cross-platform language and runtime envionment based on almost open standards.
I don't recall seeing RMS bitching too heavily about Sun's absolute control of the Java language and runtime.what it was that RMS didn't like about it. I wouldn't be surprised if he's just being reactionary for the sake of it.
The LWN Distibution list has a "CD-Based" section. I suggest starting with one of those, configuring it to use swap on a file in /tmp on /dev/hd??, and go from there.
companies always grow at the expense of their customers. that's the definition of a customer.
what a great story. the geek fights back - and gets a conviction out of it to boot.
56767 looks more like someone typing a series of five digits with three fingers.
i see, so there's no capability for X itself to render the fonts to the screen, it has to pass the bitmaps back to the client and then the client has to pass the bitmaps back to the server? that seems a bit inefficient especially given that X was designed as a network protocol from the start. excuse my ignorance, i'm just used to windows' TextOut() which renders the font directly into the device context. the communication between the application and GDI consists of just the text, a DC and a font handle. the only way to get the bitmap data for a font is to render it into a DC on your own bitmap.
Since I installed Windows XP on my laptop suddenly every character on my screen has been rendered in fully anti-aliased ClearType. I didn't have to reinstall new versions of any applications, or even new fonts, the operating system (or the GUI parts of it) just support it (optionally, of course).
Why can't the xfree86 guys just add anti-alising to the existing font rendering code?