My gut feeling, which I didn't say, since I didn't have much to back myself up at the time, was that Microsoft has tried doing things like this in the past, then backed down. I thought about Smart tags in IE, where IE would 'suggest' where you should go, based on a given link, or how their cluttered HTML that Frontpage produces has backfired on them. Then I also think about the pressures from the EU, where they have to open up their standards.
What do people think? Has anyone heard anything similar? Anybody think they'll back down and allow something like perl to be interoperable, as the EU wants?
-- Burvil
Microsoft won't support Perl? Not going to worry about it. Far too many systems were written and people aren't going to go "ok we will just rewrite everything for vbscript"
Microsoft will notice it when people aren't buying upgrades because their databases, websites, QA systems, CVS managment, etc require rewrite.
One of them says he went to a Microsoft Tech Ed Conference, where they say they're standardizing on C#, VBscript and something else I can't remember right now (probably Monad), and they specifically wanted to take away the hooks that were available for Perl in the past.
Your colleague is full of beans; don't let him near any machine you care about. I can only imagine how Microsoft will allow everyone from commercial companies and ISVs to shareware and freeware developers write applications of all kinds but not programming languages.
There are some difficulties pending WRT Perl on later MS OS and compilers. But as and when we get the chance we will take care of them. I wouldnt worry about it too much. Also, sounds like your colleague is just looking for a reason not to learn a new skill. Which is all too common in our industry.
$world=~s/war/peace/g
... since they say Perl won't be supported in Longhorn.
Ask them what they mean by that?
To my knowledge, MS don't 'support' Perl now. I know they did put some investment into AS at one time and even contributed some code to the Win32 codebase I think, but I don't think they ever added anything to XP to enable it to "support Perl".
So what will they not be doing that would prevent Perl being ported to Longhorn?
Sound like they don't like/want to learn Perl, which is their perogative, but attributing their reluctance to MS not supporting it doesn't make much sense (to me anyway).
PS. By the way, won't Longhorn be Win64?. And, from the little I've read, won't (most) Win32 apps (including Perl) run perfectly well in a w32onw64 WOW box?
I wonder if it could have something to do with code signing/DRM as a way of fighting trojans/spam/copyright infringment.
If any code signing mechanism that MS implement either
- Only allows code signed off by MS to run.
- Doesn't allow retro-active signing of existing code by existing code authors/owners/licence holders.
- Doesn't permit machine owners to decide what code they can allow to run on their machines.
the software containing that mechanism will be deservedly still born.
As somebody else pointed out, whatever you think of MS, they aren't totally stupid.
I'm not convinced of that; all it takes is marketing to create consumer acceptance, and Microsoft is a world leader in marketing.
Consider the average game console: they manufactuerer has certainly tried very hard to prevent anyone from running "unauthorized" software on those systems, and to a large degree, they've been successful.
The only reasons why the same sort of approach wouldn't work for a computer branded as a "workstation" rather than a "game console" are social rather than technical. If people can accept that game consoles only take software written by the manufactuer, they can probably be made to accept a similar idea for PCs as well.
Remember, Microsoft didn't make a fortune by being great at technology. They made a fortune, in part, by being great at marketing (and lots of other shady business practices, including antitrust violations). They've always been very good at manipulating social perceptions; their marketing for Windows 95 was so good that people who didn't even have computers were calling up the helplines asking how to use this great new product they'ld just purchased.
I'm not saying that Microsoft could pull it off; but if anyone can, it's them. Those guys could sell MS-Sand in the middle of a desert, and people would be lining up for miles around to buy it.
--
Ytrew
What convinces me that it wouldn't fly is that the main source of revenue for OSs are corporate customers. Corporates are mostly very conservative. If MS tell them that in order to upgrade their 1000s of workstations, they will also have to re-write every application they use; or apply in writing to MS (or any 3rd party body), to have their existing in-house and 3rd party applications 'signed off', the impact of the upgrade would just be too costly and too risky to contemplate.
Can you imagine every bank, government dept. etc., having to supply the source code of their proprietary and commercially sensitive applications to MS or some 3rd party clearing house organisation before they can run them? I'm very convinced that any such requirement would be death to the OS.
IMO, there would *have* to be some 'self-sign certification' option. Indeed, I would welcome a process that prevented an executable from running on my system until I had explicitly, manually, (with-no-possibility-for-programmable-override), authorised it. A minor inconvenience during the development cycle, but it would prevent the vast majority of viruses, trojans and spyware.
I essentially do this now for applications that attempt socket communications via my firewall. If it extended to all executables, that would be a good thing in my opinion--but only if *I* control what is allowed to run. And what not.
I agree that there are some worrying precedents for people accepting the diminution of there rights in consumer products--iPod is the latest, greatest, most worrying example--but I think that corporates are unlikely to surrender their rights quite so easily.
My take on DRM and similar technologies, and anything that purports to sell me something but then curtails my rights to use it as I see fit, is that I simply do not buy them. If everybody followed suit, they simply wouldn't get off the ground, but that is a forlorn hope in many areas of consumer products--game consoles, mp3 players, DVD players, mobile phones, ISP connections etc.
What convinces me that it wouldn't fly is that the main source of revenue for OSs are corporate customers.Yes. But don't forget that there are going to be 5 versions of Vista. I'd expect the restrictions (if any) would start at the low end (home entertainment, etc.), and if successful, start encroaching on the business and enterprise versions in later releases (2011?).
How many banks run propritary and commerical sensitive applications under windows? How many government agencies do? In my experience with government, they run Excell, Word, a few major non-microsoft programs (which would quickly be certified by the manufacturers), and little else. For banking, everything I've heard indicates that the heavy lifting is *still* done by COBOL on mainframes. The majority of third party developers would quickly get their old apps certified; and the fringe developers simply don't matter that much.
MS gets to tax all the other developers a small amount to certify their apps; and to the rest of the world, it then looks like a typical upgrade risk ; just one that's more profitable for Microsoft.
anything that purports to sell me something but then curtails my rights to use it as I see fit, is that I simply do not buy them.
That battle was lost years ago, dating at least back to when the Berne Convention was signed. Patents, trademarks, and copyrights have existed for centuries. DRM law is just an extention of existing legal principles, which purport to increase innovation by making sure only right-holders can do it (and thereby, have a profit motive as an "incentive").
People have been boycotting over these issues for as long as there have been monopoly rights; and sadly, it doesn't really work. There are too many monied interests and too much public apathy for the freedom to innovate to ever really prosper. Twenty years ago, as a young and naive boy, I really thought the laws would get reformed, and change for the better. Twenty years later, all I see is change for the worse; and the public at large doesn't even seem to notice, let alone care. Maybe they just all want different rights than you and I do.
--
Ytrew
How many banks run propritary and commerical sensitive applications under windows?
Plenty, in this country anyway. They used to run OS/2 on (some) of their ATMs, but I'm pretty sure that they will have moved over to NT for those. I once gave a training course in Smalltalk V/PM to the developers at one of the big 4 banks. And I know from my sister who worked in one of them, that many of the front-of-house and machine room applications ran on NT/2000-based workstations.
At one time, (almost) every application that ran on any small system--workstation, server or mini-class--was developed in-house. The banks were large scale, in-house, IT developers. The logic isn't complicated. If the only software your system runs (besides the OS), is developed in-house, it makes it much harder to penetrate and crack as the bad guys have nothing to practice on. Whether this is still true I am not sure. My (scant) inside information dried up when my sister took a lucrative golden handshake and moved on several years ago, but I seriously doubt much has changed. If anyone on the inside today know better, I'm open to correction on this.
Of course, the large scale applications at the DP centres still run on big iron, but at the branch level, there are many functions that require local processing before consolidated data is uploaded to the DP centers.
I'll say it again. With appropriate configuration, most of which is not even particularly hard to do, or find references telling you how, all the NT-based versions of Windows are perfectly capable of being secured. The astonishing thing (to me), is that, despite all the bad press it has garnered MS, successive OEM distributions have been shipped in a default-open rather than a default-closed mode of operation. Some will attribute this to MS simply not caring, others to a lack of programming competance, but neither of these hold true for me.
My pet conspiracy theory is that there is circumstantial evidence for "external influences" involved here. The thing you have to ask yourself is who benefited most from open doors onto the harddisks of 90% of the worlds (private, commercial and governmental) PCs? And who has the expertise, knowledge, money and infrastructural capacity to exploit them for commercial and military advantage?
If you buy that, the next question to ask yourself is, if the forthcoming release of Windows is going to be secure, what would remove the external influence to allow that to be the case?
Google are rapidly becoming the central clearing house for the world's surfing habits, email, porn collections and even the contents of people's hard disks. They are also powerless to resist external pressure to supply information to certain government departments. Is the timing coincidental?
I do not believe in coincidences.
If MS tell them that in order to upgrade their 1000s of workstations, they will also have to re-write every application they use; or apply in writing to MS (or any 3rd party body), to have their existing in-house and 3rd party applications 'signed off', the impact of the upgrade would just be too costly and too risky to contemplate.
You've got to think like a salesman. Present it as an opportunity. Now the IS department can finally enforce all of its regulations on which software is officially approved for use. No more worries about viruses/trojans. No more employees goofing off playing computer games. And it won't be any more of a burden to implement this, than it currently is to negotiate their site license. Banks and governments are the first customers who would sign up for this feature. Rogue bank employees won't be able to sell internal/sensitive documents, because they'll only be decryptable on authorized bank computers. Government beauracrats will be less able to leak stuff to the press. And MS won't go to the bother of trying to certify that the custom programs you want signed are reliable. They'll just have a rubber stamp approval for any binary you submit. Of course, you'll get to pay for the priveledge. And they'll be running as second class citizens, without full access to every part of the system, otherwise you could possibly compromise the whole scheme. But it'll mostly work.Can you imagine every bank, government dept. etc., having to supply the source code of their proprietary and commercially sensitive applications to MS or some 3rd party clearing house organisation before they can run them?
Consider the average game console: they manufactuerer has certainly tried very hard to prevent anyone from running "unauthorized" software on those systems, and to a large degree, they've been successful.
I've never worked in a company that only ran "authorized" software on every machine. That is, every company I've ever worked for as an employee or a consultant has had at least one necessary application written by a third-party.
I don't know if any of that is true, either. But I'll say that Microsoft works for Microsoft, period. It does what's good for Microsoft, not what's good for its users, developers, or anyone else (as do most other big corporations - I'm not singling MS out for special treatment). So MS will do whatever it perceives to be in its best interests. If it thought it could keep the OS on the Internet, and force everyone to connect before being able to do anything (which, in fact, appears to be where it's trying to go), it will do it.
The upside of this is that, if enough people speak up, Microsoft can be influenced in its decisions as to what's best for it. If people let them know that they'll either not upgrade, or migrate to another platform, MS will do what it can to make those people just happy enough to stick with them.
My sense is that this is more or less rubbish. As it stands, Microsoft hasn't really offered much reason for people to "upgrade" from XP to their next product, whatever it's called. If they make a product that Perl can't run on, then they've removed yet one more incentive for people to upgrade.
They'd be saying, "Switch to Vista (or Longhorn, or whatever), and we'll charge you more money, break your programs, and your scripts won't work, either." Who could pass up a deal like that?
Microsoft might not know a whole lot about software production, but they do know a lot about business. They aren't likely to risk losing customers by breaking things for them. At least, not by doing it on purpose.
Humm... Is possible Microsoft don't like Perl because it have their Perl?
Today, Microsoft has released RC1 version of PowerShell the .NET-based shell with perl-like syntax... More...
Example:
$compsys = get-wmiObject win32_computersystem
$biosinf = get-wmiObject win32_bios
$netinfo = get-wmiObject win32_networkadapter |
where-object { $_.adaptertype -like "802.3" }
$cdrom = get-wmiObject win32_cdromdrive
"Make = " + $compsys.manufacturer
"Model = " + $compsys.model
"Bios = " + $biosinf.name + " " + $biosinf.smbiosbiosversion
foreach ( $nic in $netinfo ) { "NIC = " + $nic.name }
foreach ( $cd in $cdrom ) { "CDROM = " + $cd.name }
Extract from PowerShell User Guide:
| $_ | The current pipeline object; used in script blocks, filters, the process clause of functions, where-object, foreach-object and switch. |
Ugly notation! :-)
Asociative Array: $= @{ ; ;...}
I am reading the User Guide. Page 38:
We investigated a number of different options; whether to extend the current CMD.EXE syntax or to modify the current Visual Basic to better enable an interactive use. After looking at many different possibilities, we decided that a new language that was built from the ground up would be best because it would enable us to provide a more consistent environment. We were inspired by concepts in the UNIX shells; other scripting languages such as PERL, PHP, PYTHON and programming languages like C# to create a consistent, intuitive language that is an interactive environment.
Page 72:
Similar to the UNIX model, the majority of users will find that the use of commands is sufficient to accomplish what is required. However, there are conditions when existing commands do not provide the required functionality. In these cases, there are generally two choices. First, if the functionality is able to be composed, create a script to provide the necessary functionality. Second, create a new command to provide the needed functionality (much in the same way that the functionality of text parsing utilities for the UNIX system have increased over time and is arguable why PERL, TCL, and other scripting languages developed). Unfortunately, the complexity of creating a new command can be high, and in some cases, the required tools (such as a compiler) are not available.
For the records... Perl is named 6 times. C#, 14. Java, 0. TCL, 2. Python, 2. Ruby, 1.
Somebody should point out that they need to do a s/PERL/Perl/ :-)
$world=~s/war/peace/g
We investigated a number of different options; whether to extend the current CMD.EXE syntax or to modify the current Visual Basic to better enable an interactive use...INTERIX: M$ Linux
...But something's missing :) ...
- Landlords production is only eaten by landlords...
- Wherever I lay my KNOPPIX disk, a new FREE LINUX nation could be established
I would say the vast majority of professional coders out there know very little about programming or the history of computing in general; they will be at the mercy of a company that knows how to bait them and advertise to them with gimmicks that "new" languages can offer.
Microsoft will continue to release new languages and do everything in their legal power to inhibit native support for anything that competes with spaces they operate in (browser support for Hotmail, language support in browsers, HTML compatibility, blah blah).
Are you forgetting already that Microsoft once added into their operating system a scanner that uploaded information about everything you had on your hard drive (this was eventually removed from Windows 95 after journalists discovered this with beta editions and a community uproar assisted MS in changing their minds)?
You can help! Just be a professional. Speak out when someone is doing something excessively stupid - like using a MS exclusive technology when many existing technologies are available that are more powerful, more efficient, better known, more portable, etc etc.
To be honest, I have never come across anybody using Perl in the .NET environment. It has been suggested to me that one of the reasons that ActiveState dropped the Perl .NET support was because of very low usage rates. But Perl on Win32 doesn't rely on .NET ir any of the .NET hooks - unless you want it to.
Whatever happens between ActiveState and Microsoft will quite likely not affect the distribution at all. Microsoft tends to be full of internal hype and bluster - which ultaimtely translates into very little! I haven't seen any less support from AS for Perl and I do know some pretty big governments that will not accept anything written in a Microsoft propretary language unless it was written by Microsoft.