Windows will, however, warn you that the.lnk file can be potentially dangerous when you try to run it, just like with executables downloaded from the net.
Whether anyone bothers to click Cancel on the warning is a different matter though.
They're just different operating systems. Windows has always used ACL heavily, while Linux sticks to just basic file permissions.
Once you've learned the basics, ACL is not hard to use and is easily handled even from the command line. Any more advanced Windows user would be expected to learn this, just like a Linux user would be expected to learn how the various parts of a Linux distribution work.
The reason is that the Local Settings folder doesn't exist anymore. It was only present in XP and earlier and has been replaced by User\AppData\Local. Similarily, the old Application Data is now User\AppData\Roaming.
If you set Explorer to show all hidden operating system files on Vista/7 (which this guy clearly has), these old folders will appear to show up, but you cannot manipulate them as they aren't actually folders anymore. They're protected junctions (a type of hard link) that are used by the compatibility layer to redirect requests for these folders to the new locations.
Now granted, this is a bit more technical than your regular user can be expected to understand, so it's understandable that you'd get claims like this. For a large site like Slashdot to blindly repeat them is shameful though.
I'm not sure if I see the relevance. We are discussing current operating systems here (or what will be on the market when the EU makes its decision, in other words Windows 7 and beyond), not Windows XP and earlier. Those operating systems are dead and there isn't going to be a big patch to remove IE from them.
What Opera and other companies really want is IE off the start menu and the components left in the OS.
Which I agree is a totally reasonable request.
Everything that is needed to do this is already present in Windows. All that is needed is for OEMs to be able to pre-install something else without facing any pressure from Microsoft.
(Provided that the OEM wanted to take responsibility for supporting and updating the replacement browser, of course.)
What are you really getting rid of? All the underlying engines (which, presumably, are shared components available to everyone on OS X as well), or just the GUI frontend? If it's the latter, then you haven't really removed it, you've just done the equivalent of deleting iexplore.exe.
It doesn't matter. Most of the APIs and structures are pretty much documented already (you can read the documentation from an implementor's perspective), but we aren't talking about some small utility here, we are talking about something so large and complex that there is no realistic chance of anyone else bothering to implement it.
The underlying IE framework that so many third party applications use (and it's not just for displaying HTML) is going to have to remain in Windows (or be offered as an optional download through Windows Update), there is no way around it.
It's easy to say that today. It wasn't that easy in the late 90s when this was all happening. Microsoft most certainly did have a monopoly, and did abuse it. Things have gotten better since then (and Microsoft is even partly responsible for Apple getting back on its feet), but we're still paying for it today. It's not a problem that is easily solvable.
The API is open. You're free to go to MSDN and implement them from the documentation yourself (lots of programs do this for various other APIs). The problem is that it's still a fucking huge job and not something that is realistically ever going to happen.
It would not be painful. It was already done years ago. Slashdot readers need to get some experience with more recent versions of Windows.
These days it's mostly third party stuff that will break without the IE framework installed, which is kind of funny in a twisted "Mission Accomplished" way.
That is because IE is not just the browser frontend, it is an entire framework that a lot of third party applications depend on.
This was done intentionally by Microsoft, even going so far as making important components like Explorer depend on it. This isn't really the case any more for most of Windows, but the third party programs still need it, so removing it would break a lot of programs people use.
Firefox is not a replacement either, because it does not implement any of the interfaces that the IE framework does (even though they could go to MSDN and implement them, but we're talking about a lot of work here.)
Now... you could remove the actual IE program itself, as few other programs depend on it, but what would be the point? To save a few megabytes?
I mean, there is already the option to remove access to it and use another browser as default. That's really all OEMs would need to ship a third-party browser (it would be problematic for Microsoft to do so.)
You are correct in saying that the Explorer can open FTP sites, however this functionality is supplied by Internet Explorer through a shell extension. Remove IE and you also remove the FTP support, leaving you with only the command line FTP command (or whatever you hack together in PowerShell).
This guy -- an employee of ZDNet -- is running a pirate copy of Windows 7 (only 32-bit, the 64-bit version is not on the pirate sites). Why would a "EULA" matter.
It doesn't work that way. In many applications there are real portability problems that prevent them from just being recompiled as 64-bit.
It isn't as big an issue on Linux because someone took time to make sure the application worked on 64-bit. Companies like Adobe likely have a lot of code that is poorly structured and very tied to a specific architecture.
Nothing in the Windows SDK is "in the kernel." Applications do not call kernel functions, they call various subsystems that run on top of it. Windows already has a pure 64-bit kernel. When you run a 64-bit application, the 64-bit versions of the system DLLs (and it's those that eventually call kernel functions) is loaded into the process. No problems there.
When you run a 32-bit program,Windows knows this and runs it in the 32-bit emulator. This is completely transparent to the application which only sees a 32-bit world. The emulator includes 32-bit versions of all the DLLs, and the application only deals with these. When these 32-bit DLLs attempt to call kernel functions, the emulator transparently passes it through a userspace thunking layer that converts everything to 64-bit before passing it to the kernel, and then does the same in reverse when it returns. This is pretty much the same as happens in Linux, except that Linux has a seperate set of system calls for 32-bit and does the thunking to 64-bit inside the kernel.
The APIs are the same in 32-bit and 64-bit, and problems associated with porting to 64-bit lie elsewhere. One common thing is the use of assembly. Another the use of incorrect types for pointers (which causes problems when you pass something to an API call that is identical to the 32-bit version except that it expects a 64-bit pointer.) A third, like you point out, the use of third-party DLLs that are only available as 32-bit and can't be loaded into a 64-bit process.
That's exactly how it works. If you turn on text labels it becomes more apparent as the icon morphs into a full taskbar button.
If you want to launch a new instance you can either middle click on the button or bring up the context menu by right clicking or left clicking and dragging up (this also lets you open frequent/recent files or whatever the author has decided to put in the menu with a single click. You simply keep the left mouse button depressed until you're over the item and then let go.) You can also rearrange the buttons.
It is certainly inspired by OS X and unrelated to the old quick launch bar, although you can still choose to make a seperate toolbar for launching programs. Pinning them to the taskbar itself is optional and you don't have to do it if you don't like it.
Apple has never given much thought to multi-monitor support. It's just bolted on as an afterthough. Why is it that I still can't have a menu bar on each monitor? Because Jobs doesn't feel like it. Same reason I can't cut and paste files in Finder: "just because."
And Microsoft, why can't I have a taskbar on each monitor? One that shows just the windows open on that monitor? Maybe I'll patent the idea and sell it to them.
It took that long because a lot of the groundwork for Vista was actually done with XP SP2. People seem to have forgotten just how many fundamental changes were introduced in SP2 and how much software (and drivers) that broke as a result. All that work helped delay Vista.
Maybe it would have been best to leave XP as it was pre-SP2 and introduced the changes with Vista. When also combined with all the stuff that was backported and made available on XP, Vista didn't seem to offer that much new.
So do most operating systems. Usually a 32-bit process can't load a 64-bit library, and the easiest way around this is by simplying including both versions of all the libraries with some minor tweaks here and there.
This is how it works on Linux as well, the only real difference being how calls to the actual kernel (ie system calls) are thunked (translating the contents of the stack from 32-bit to 64-bit and back). Linux does this internally, Windows does it through a userspace layer known as Windows on Windows. It basically amounts to the same thing.
On Linux it's also optional, whereas on Windows and OS X it is not. This does make the OS bigger, but most people have to run 32-bit programs at some point anyway.
You're running Windows Server 2003.
In the consumer versions of XP (it was removed by a service pack) and Vista nothing can be pushed over the 4GB barrier because it breaks old and shitty drivers that are not PAE-aware. The result is that a modern machine can really only use 3GB or less. Many other OSes had to deal with the same problem, but it was less of an issue with drivers that had the source code available and thus could be fixed.
Slashdot Mirror
Yeah, Microsoft is encouraging you to do something that isn't even technically possible.
Windows will, however, warn you that the .lnk file can be potentially dangerous when you try to run it, just like with executables downloaded from the net.
Whether anyone bothers to click Cancel on the warning is a different matter though.
They're just different operating systems. Windows has always used ACL heavily, while Linux sticks to just basic file permissions.
Once you've learned the basics, ACL is not hard to use and is easily handled even from the command line. Any more advanced Windows user would be expected to learn this, just like a Linux user would be expected to learn how the various parts of a Linux distribution work.
The reason is that the Local Settings folder doesn't exist anymore. It was only present in XP and earlier and has been replaced by User\AppData\Local. Similarily, the old Application Data is now User\AppData\Roaming.
If you set Explorer to show all hidden operating system files on Vista/7 (which this guy clearly has), these old folders will appear to show up, but you cannot manipulate them as they aren't actually folders anymore. They're protected junctions (a type of hard link) that are used by the compatibility layer to redirect requests for these folders to the new locations.
Now granted, this is a bit more technical than your regular user can be expected to understand, so it's understandable that you'd get claims like this. For a large site like Slashdot to blindly repeat them is shameful though.
I'm not sure if I see the relevance. We are discussing current operating systems here (or what will be on the market when the EU makes its decision, in other words Windows 7 and beyond), not Windows XP and earlier. Those operating systems are dead and there isn't going to be a big patch to remove IE from them.
What Opera and other companies really want is IE off the start menu and the components left in the OS.
Which I agree is a totally reasonable request.
Everything that is needed to do this is already present in Windows. All that is needed is for OEMs to be able to pre-install something else without facing any pressure from Microsoft.
(Provided that the OEM wanted to take responsibility for supporting and updating the replacement browser, of course.)
What are you really getting rid of? All the underlying engines (which, presumably, are shared components available to everyone on OS X as well), or just the GUI frontend? If it's the latter, then you haven't really removed it, you've just done the equivalent of deleting iexplore.exe.
You can't, because, oops, that feature is actually supplied by IE (yes, this is true for Vista and Windows 7 as well).
It doesn't matter. Most of the APIs and structures are pretty much documented already (you can read the documentation from an implementor's perspective), but we aren't talking about some small utility here, we are talking about something so large and complex that there is no realistic chance of anyone else bothering to implement it.
The underlying IE framework that so many third party applications use (and it's not just for displaying HTML) is going to have to remain in Windows (or be offered as an optional download through Windows Update), there is no way around it.
It's easy to say that today. It wasn't that easy in the late 90s when this was all happening. Microsoft most certainly did have a monopoly, and did abuse it. Things have gotten better since then (and Microsoft is even partly responsible for Apple getting back on its feet), but we're still paying for it today. It's not a problem that is easily solvable.
The API is open. You're free to go to MSDN and implement them from the documentation yourself (lots of programs do this for various other APIs). The problem is that it's still a fucking huge job and not something that is realistically ever going to happen.
It would not be painful. It was already done years ago. Slashdot readers need to get some experience with more recent versions of Windows.
These days it's mostly third party stuff that will break without the IE framework installed, which is kind of funny in a twisted "Mission Accomplished" way.
That is because IE is not just the browser frontend, it is an entire framework that a lot of third party applications depend on.
This was done intentionally by Microsoft, even going so far as making important components like Explorer depend on it. This isn't really the case any more for most of Windows, but the third party programs still need it, so removing it would break a lot of programs people use.
Firefox is not a replacement either, because it does not implement any of the interfaces that the IE framework does (even though they could go to MSDN and implement them, but we're talking about a lot of work here.)
Now... you could remove the actual IE program itself, as few other programs depend on it, but what would be the point? To save a few megabytes?
I mean, there is already the option to remove access to it and use another browser as default. That's really all OEMs would need to ship a third-party browser (it would be problematic for Microsoft to do so.)
You are correct in saying that the Explorer can open FTP sites, however this functionality is supplied by Internet Explorer through a shell extension. Remove IE and you also remove the FTP support, leaving you with only the command line FTP command (or whatever you hack together in PowerShell).
This guy -- an employee of ZDNet -- is running a pirate copy of Windows 7 (only 32-bit, the 64-bit version is not on the pirate sites). Why would a "EULA" matter.
It's disgusting that ZDNet condones this.
It doesn't work that way. In many applications there are real portability problems that prevent them from just being recompiled as 64-bit. It isn't as big an issue on Linux because someone took time to make sure the application worked on 64-bit. Companies like Adobe likely have a lot of code that is poorly structured and very tied to a specific architecture.
Nothing in the Windows SDK is "in the kernel." Applications do not call kernel functions, they call various subsystems that run on top of it. Windows already has a pure 64-bit kernel. When you run a 64-bit application, the 64-bit versions of the system DLLs (and it's those that eventually call kernel functions) is loaded into the process. No problems there.
When you run a 32-bit program,Windows knows this and runs it in the 32-bit emulator. This is completely transparent to the application which only sees a 32-bit world. The emulator includes 32-bit versions of all the DLLs, and the application only deals with these. When these 32-bit DLLs attempt to call kernel functions, the emulator transparently passes it through a userspace thunking layer that converts everything to 64-bit before passing it to the kernel, and then does the same in reverse when it returns. This is pretty much the same as happens in Linux, except that Linux has a seperate set of system calls for 32-bit and does the thunking to 64-bit inside the kernel.
The APIs are the same in 32-bit and 64-bit, and problems associated with porting to 64-bit lie elsewhere. One common thing is the use of assembly. Another the use of incorrect types for pointers (which causes problems when you pass something to an API call that is identical to the 32-bit version except that it expects a 64-bit pointer.) A third, like you point out, the use of third-party DLLs that are only available as 32-bit and can't be loaded into a 64-bit process.
That's exactly how it works. If you turn on text labels it becomes more apparent as the icon morphs into a full taskbar button.
If you want to launch a new instance you can either middle click on the button or bring up the context menu by right clicking or left clicking and dragging up (this also lets you open frequent/recent files or whatever the author has decided to put in the menu with a single click. You simply keep the left mouse button depressed until you're over the item and then let go.) You can also rearrange the buttons.
It is certainly inspired by OS X and unrelated to the old quick launch bar, although you can still choose to make a seperate toolbar for launching programs. Pinning them to the taskbar itself is optional and you don't have to do it if you don't like it.
It was, but Slashdot isn't the place for facts or rational discussion, so whatever.
Apple has never given much thought to multi-monitor support. It's just bolted on as an afterthough. Why is it that I still can't have a menu bar on each monitor? Because Jobs doesn't feel like it. Same reason I can't cut and paste files in Finder: "just because."
And Microsoft, why can't I have a taskbar on each monitor? One that shows just the windows open on that monitor? Maybe I'll patent the idea and sell it to them.
It took that long because a lot of the groundwork for Vista was actually done with XP SP2. People seem to have forgotten just how many fundamental changes were introduced in SP2 and how much software (and drivers) that broke as a result. All that work helped delay Vista.
Maybe it would have been best to leave XP as it was pre-SP2 and introduced the changes with Vista. When also combined with all the stuff that was backported and made available on XP, Vista didn't seem to offer that much new.
So do most operating systems. Usually a 32-bit process can't load a 64-bit library, and the easiest way around this is by simplying including both versions of all the libraries with some minor tweaks here and there. This is how it works on Linux as well, the only real difference being how calls to the actual kernel (ie system calls) are thunked (translating the contents of the stack from 32-bit to 64-bit and back). Linux does this internally, Windows does it through a userspace layer known as Windows on Windows. It basically amounts to the same thing. On Linux it's also optional, whereas on Windows and OS X it is not. This does make the OS bigger, but most people have to run 32-bit programs at some point anyway.
You're running Windows Server 2003. In the consumer versions of XP (it was removed by a service pack) and Vista nothing can be pushed over the 4GB barrier because it breaks old and shitty drivers that are not PAE-aware. The result is that a modern machine can really only use 3GB or less. Many other OSes had to deal with the same problem, but it was less of an issue with drivers that had the source code available and thus could be fixed.
Yep! They took XP SP3, then backported everything new in Vista to it, added some new stuff, and called it Windows 7!
evidence coming out that tends to show it's not very healthy to carry one over you for long stretches of time.
No doubt. Wouldn't your arms get tired?