For example, take the XBox. To run code on it, you have to have your code signed by Microsoft.
But that's always been the model in the console market: the hardware's a loss-leader, you make your money on the games.
Nintendo even did this way back with the NES: to run, each cartridge had to have a special chip sold by Nintendo. Some publishers worked around this by selling a small cart with a socket in the back for you to plug a properly licenced cart into: the first cart used the Nintendo licence chip in the second cart to satistfy the console. I think that got stamped on, though.
Once you understand how Passport works and would work in the future, it is so clearly a horrible idea that it is not funny. People often only think of it as a central repository for storing their passwords. Some like this idea for its convenience but the Passport model is so half-baked it is not even funny.
Do you have a source for this?
I've seen this misconception a few times in this story so I'm going to put it in bold: the current passport system DOES NOT STORE PASSWORDS. It's a trusted third party for authentication. You log into Passport and it vouches for you to eBay.
You do not have to enter all your personal details into Passport. If you do enter your personal details into passport then you can always clear the "pass the details onto sites" checkboxes. If you clear all the checkboxes, the only information the end sites get about you is your 64-bit Passport user ID. There is no mechanism for the end site to upload information about you to Passport. If you want to change the data in your Passport record, you have to go to the Passport site to do it.
Mouseover the "How do I become a.NET Passport Site?" on the directory site and it shows "http://www.microsoft.com/net/services/passport", but click it and your redirected to "http://www.microsoft.com/NET/default.aspx" with not a mention of.NET Passport.
I don't think the docs have ever been there - looks to me like they're putting that site together but put it live before they finished it yet. The best link to follow is the Getting started link on the passport front page.
The Passport docs have been stale for some time. The download contains a *way* out of date configuration file and I think the code to refresh it is hosed to - you have to jump through hoops to update it manually.
Without that level of security, a lot of the engineering and compliance testing and associated costs aren't necessary.
But someone has to pay. Yeah, I'd like Microsoft to offer this to webmasters cheaply - it'll probably save them enough money in-house to pay for itself anyway - but they need to set a cover charge to keep the riff-raff out and keep their own support burden down. It's just they've set it too rich for me. If it was $100, I'd code passport into all the websites I work on.
Better still, give passport licences away with MSDN:-) or free for Microsoft Certified Partners.
I don't want my password to be stored on a computer.
Jesus.
Look, Passport does not "store your password". It's a trusted third party for authentication purposes. You log into passport and passport vouches for you to eBay. Passport does not know your regular eBay password.
Yes, you can give it your real name and email address to hand out to sites you log into *but you don't have to*. And if you do type it in, you can clear the checkbox giving passport permission to pass on your details to sites you log into. Then all the site will get from passport is a 64-bit user ID.
Single-sign in, properly implemented, is a good thing. Sure, don't use it for anything you want ultra-secure, but it's convenient for the day-to-day stuff. In order to be widely accepted, a single-sign-in system would need a big name behind it. Like it or not, Microsoft are a big name.
The MAPI client-side API has an associated on-the-wire protocol that is undocumented;
Yes, but the protocol really belongs to the Exchange transport/store provider, not MAPI. You can use MAPI as a common interface to other protocols via differnt transport providers.
You still haven't addressed the reality that intentionally breaking support and patching is viable for MS given the ability to provide the new info to 3rd party.
I don't think it is. Big business would jump up and down and say "you're causing us a huge headache for no good reason, this isn't on". It'd take many man-years to make a MAPI client that competes with Outlook and you'd be playing catch-up - I don't think they'd go to exteme lengths to squash a small competitor out of spite. But maybe I've got too much faith in them.
NTFS is an entirely different matter - the format isn't published, which gives them freedom to enhance or optimse the structures without being constrained by compatibility. MAPI is a published API.
I suppose it's easier than reverse-engineering the MAPI protocol and hoping MS doesn't break your work with the next Exchange revision.
They can't. There's a huge installed base of existing MS Office products and they need forward and backward compatibility between Office and Exchange.
And MAPI isn't a protocol, it's the client-side API through which you access (amongst many other things) the Exchange messaging transport and store providers.
They've broken something a few times, seeing as Outlook 2k isn't to run with Exchange 2k3 and vice versa...
I don't think I've ever seen problems accessing Exchange 2003 from Outlook 2000. I'm fairly sure someone in our office does, or used to, do that. Sure, you might not get all the features of Outlook 2003 but you'll still be able to do everything Outlook 2000 used to.
Exchange Server 2003 also operates with Microsoft Office Outlook 2003, Outlook 2002 (Office XP), and Outlook 2000. Outlook Web Access can be used on other client platforms through browsers.
OK, they don't list '98 or older but I expect they've been EOLed rather than actively not work.
Yes, they can issue a patch to break all MAPI and just fix Outlook but that'd be an insane thing to do. Outlook isn't the only thing that uses MAPI - there's plenty of other software out there they'd be breaking for no good reason.
As documented as MAPI may be, I wouldn't want to be chasing MS - NTFS and to an extent SMB are an example of why I'd rather see dependence on MAPI being a side feature not a primary.
Well, you're not really. NTFS is undocumented and it had to be reverse-enginered. If MS breaks MAPI they break all existing versions of Outlook and they can't do that.
If you implement an Exchange client only to the documented MAPI spec and documented set of object properties then you won't be able to see that someone's put a colour code on an appointment in the calendar, for example, but you'll still be able to interact with the calendar and send / receive mails. Exactly as if you were running Outlook 98.
That's what Ximian's first Evolution Connector was based on. It's all IMAP based. Outlook pre-2003 (and maybe post) both use RPCs and MAPI stuff.
Sure, but MAPI is a documented API and you don't have to be Outlook to use it. You do have to be on Windows, though, which is why it's useless for Ximian. (The RPC stuff, I think, is Outlook 2003 talking to Exchange 2003 over HTTPS so you don't actually need to be on the same LAN / VPN as the exchange server.)
The grandparent seemed to be saying that having MAPI wasn't enough to implement an Exchange client. AFAIK, it is. I was asking what else you needed.
at least for the mail part, outlook server access is integrated in the mac os x mail client.
Well the MAPI object model is pretty simple - a mail is just an object in a particular folder with a particlar set of properties. A calendar entry is just an object in with a different set of properties. To send a mail you create an object in the 'outbox' folder.
I'd be surprised if this didn't map very closely to the Exchange wire protocol. If you've got enough of the Exchange protocol in the Mac OS X client to read / write mail, you've probably got enough to do everything else too (with the right UI).
Oh, and for all you M$ fanboys: Microsoft is going to unbundle Media Player by January. So, in 9 days over the Christmas and New Year's holidays, Microsoft is going to be able to unbundle Media Player from the OS? Boy, it must have been really tightly integrated, eh?
I don't get what you're saying.
I don't think MS ever claimed it was tightly integrated, did they? There's no reason they can't just strip the app and leave all the underlying APIs and ActiveX objects - in fact they'd be irresponsible if the gutted them out too, it'd break loads of applications e.g. the copying animation in explorer.
Although there is the MAPI protocol for communication with Exchange, it appears that you generally need a connector on the client side for non-Outlook clients.
Sorry, maybe I'm being dumb, but what do you mean by this? Doesn't MAPI give you full access to all of Exchange's objects and properties? What else is there?
I would be willing to use any Open Source client but the Outlook server won't allow any other client to connect to it other than MS Outlook. Any hints on how to trick the thing to let me use other clients.
There's no reason why Windows-based clones can't talk to Exchange - the MAPI Exchange client is independent of Outlook, IIRC, and the API is reasonably well documented. (Up to about '98, at least - the newer features aren't I think.)
The problem is only on other OSes. As others have mentioned, a few have tried.
though one coded for prewindows DOS wouldn't work with 2000 or XP they could easily be ported.
Only if they intercept BIOS calls and somehow survive the transition into protected mode, and if the protected mode hardware drivers actually use the BIOS rather than go directly to the hardware. Which I think is very unlikely.
So no, I don't think this is possible *easily*. The best you could do would be to try and interfere with NTLDR and load a fake device driver than handles the re-infect, but that's a substantial amount of work, requiring a substantial amount of code to be hidden at boot time and would very likely be specific to a few versions of NTLDR.
In any case, to go back to the OP's case, you'd never trigger a boot sector virus on a slave drive.
Could you please explain what are the "problems it causes with SQL Server"?
As someone else pointed out above, there's a KB about it: default firewall settings break SQL Server's TCP/IP interface. Which, IMO, you shouldn't use ever.
Thanks for the link - so default firewall settings break SQL server's TCP/IP interface: I didn't know that.
That said, you *shouldn't* be using the TCP/IP interface pretty much ever. If your client is on the same PC you should use "(local)" which will use either named pipes or shared memory IPC; if you're accessing another PC on the same network you should use named pipes and if you *really* need remote enterprise manager across the NET you should remote desktop into the PC and run it locally. Then there's no SP2 vs SQL Server issue *at all*.
on MSDN subscriber downloads. They're marked build 1214 which ties up with the last-but-one build of Windows XP 64-bit available. They've now just release Windows XP 64-bit build 1247 so chances are this is build 1247 of the 2003 SP1 code.
But we haven't tried it here yet: no obvious victim 2003 machine, and no problems with our web app on WinXP SP2 code.
I'm just wondering if there's something about Steam that really is radically different in terms of content delivery from typical online delivery, or the sort of delivery implemented by e.g., Bioware.
Critical mass. Everyone who has HL2 has Steam, and HL2 will likely sell big.
Slashdot Mirror
For example, take the XBox. To run code on it, you have to have your code signed by Microsoft.
But that's always been the model in the console market: the hardware's a loss-leader, you make your money on the games.
Nintendo even did this way back with the NES: to run, each cartridge had to have a special chip sold by Nintendo. Some publishers worked around this by selling a small cart with a socket in the back for you to plug a properly licenced cart into: the first cart used the Nintendo licence chip in the second cart to satistfy the console. I think that got stamped on, though.
Once you understand how Passport works and would work in the future, it is so clearly a horrible idea that it is not funny. People often only think of it as a central repository for storing their passwords. Some like this idea for its convenience but the Passport model is so half-baked it is not even funny.
Do you have a source for this?
I've seen this misconception a few times in this story so I'm going to put it in bold: the current passport system DOES NOT STORE PASSWORDS. It's a trusted third party for authentication. You log into Passport and it vouches for you to eBay.
You do not have to enter all your personal details into Passport. If you do enter your personal details into passport then you can always clear the "pass the details onto sites" checkboxes. If you clear all the checkboxes, the only information the end sites get about you is your 64-bit Passport user ID. There is no mechanism for the end site to upload information about you to Passport. If you want to change the data in your Passport record, you have to go to the Passport site to do it.
Mouseover the "How do I become a .NET Passport Site?" on the directory site and it shows "http://www.microsoft.com/net/services/passport", but click it and your redirected to "http://www.microsoft.com/NET/default.aspx" with not a mention of .NET Passport.
I don't think the docs have ever been there - looks to me like they're putting that site together but put it live before they finished it yet. The best link to follow is the Getting started link on the passport front page.
The Passport docs have been stale for some time. The download contains a *way* out of date configuration file and I think the code to refresh it is hosed to - you have to jump through hoops to update it manually.
Without that level of security, a lot of the engineering and compliance testing and associated costs aren't necessary.
:-) or free for Microsoft Certified Partners.
But someone has to pay. Yeah, I'd like Microsoft to offer this to webmasters cheaply - it'll probably save them enough money in-house to pay for itself anyway - but they need to set a cover charge to keep the riff-raff out and keep their own support burden down. It's just they've set it too rich for me. If it was $100, I'd code passport into all the websites I work on.
Better still, give passport licences away with MSDN
I don't want my password to be stored on a computer.
Jesus.
Look, Passport does not "store your password". It's a trusted third party for authentication purposes. You log into passport and passport vouches for you to eBay. Passport does not know your regular eBay password.
Yes, you can give it your real name and email address to hand out to sites you log into *but you don't have to*. And if you do type it in, you can clear the checkbox giving passport permission to pass on your details to sites you log into. Then all the site will get from passport is a 64-bit user ID.
Single-sign in, properly implemented, is a good thing. Sure, don't use it for anything you want ultra-secure, but it's convenient for the day-to-day stuff. In order to be widely accepted, a single-sign-in system would need a big name behind it. Like it or not, Microsoft are a big name.
The MAPI client-side API has an associated on-the-wire protocol that is undocumented;
Yes, but the protocol really belongs to the Exchange transport/store provider, not MAPI. You can use MAPI as a common interface to other protocols via differnt transport providers.
You still haven't addressed the reality that intentionally breaking support and patching is viable for MS given the ability to provide the new info to 3rd party.
:-)
I don't think it is. Big business would jump up and down and say "you're causing us a huge headache for no good reason, this isn't on". It'd take many man-years to make a MAPI client that competes with Outlook and you'd be playing catch-up - I don't think they'd go to exteme lengths to squash a small competitor out of spite. But maybe I've got too much faith in them.
NTFS is an entirely different matter - the format isn't published, which gives them freedom to enhance or optimse the structures without being constrained by compatibility. MAPI is a published API.
Anyway, I've got to get back to work
I suppose it's easier than reverse-engineering the MAPI protocol and hoping MS doesn't break your work with the next Exchange revision.
They can't. There's a huge installed base of existing MS Office products and they need forward and backward compatibility between Office and Exchange.
And MAPI isn't a protocol, it's the client-side API through which you access (amongst many other things) the Exchange messaging transport and store providers.
I don't think I've ever seen problems accessing Exchange 2003 from Outlook 2000. I'm fairly sure someone in our office does, or used to, do that. Sure, you might not get all the features of Outlook 2003 but you'll still be able to do everything Outlook 2000 used to.
Furthermore, MS's exchange marketing says:OK, they don't list '98 or older but I expect they've been EOLed rather than actively not work.
Yes, they can issue a patch to break all MAPI and just fix Outlook but that'd be an insane thing to do. Outlook isn't the only thing that uses MAPI - there's plenty of other software out there they'd be breaking for no good reason.
As documented as MAPI may be, I wouldn't want to be chasing MS - NTFS and to an extent SMB are an example of why I'd rather see dependence on MAPI being a side feature not a primary.
Well, you're not really. NTFS is undocumented and it had to be reverse-enginered. If MS breaks MAPI they break all existing versions of Outlook and they can't do that.
If you implement an Exchange client only to the documented MAPI spec and documented set of object properties then you won't be able to see that someone's put a colour code on an appointment in the calendar, for example, but you'll still be able to interact with the calendar and send / receive mails. Exactly as if you were running Outlook 98.
That's what Ximian's first Evolution Connector was based on. It's all IMAP based. Outlook pre-2003 (and maybe post) both use RPCs and MAPI stuff.
Sure, but MAPI is a documented API and you don't have to be Outlook to use it. You do have to be on Windows, though, which is why it's useless for Ximian. (The RPC stuff, I think, is Outlook 2003 talking to Exchange 2003 over HTTPS so you don't actually need to be on the same LAN / VPN as the exchange server.)
The grandparent seemed to be saying that having MAPI wasn't enough to implement an Exchange client. AFAIK, it is. I was asking what else you needed.
at least for the mail part, outlook server access is integrated in the mac os x mail client.
Well the MAPI object model is pretty simple - a mail is just an object in a particular folder with a particlar set of properties. A calendar entry is just an object in with a different set of properties. To send a mail you create an object in the 'outbox' folder.
I'd be surprised if this didn't map very closely to the Exchange wire protocol. If you've got enough of the Exchange protocol in the Mac OS X client to read / write mail, you've probably got enough to do everything else too (with the right UI).
Oh, and for all you M$ fanboys: Microsoft is going to unbundle Media Player by January. So, in 9 days over the Christmas and New Year's holidays, Microsoft is going to be able to unbundle Media Player from the OS? Boy, it must have been really tightly integrated, eh?
I don't get what you're saying.
I don't think MS ever claimed it was tightly integrated, did they? There's no reason they can't just strip the app and leave all the underlying APIs and ActiveX objects - in fact they'd be irresponsible if the gutted them out too, it'd break loads of applications e.g. the copying animation in explorer.
So what's your point?
Although there is the MAPI protocol for communication with Exchange, it appears that you generally need a connector on the client side for non-Outlook clients.
Sorry, maybe I'm being dumb, but what do you mean by this? Doesn't MAPI give you full access to all of Exchange's objects and properties? What else is there?
I would be willing to use any Open Source client but the Outlook server won't allow any other client to connect to it other than MS Outlook. Any hints on how to trick the thing to let me use other clients.
There's no reason why Windows-based clones can't talk to Exchange - the MAPI Exchange client is independent of Outlook, IIRC, and the API is reasonably well documented. (Up to about '98, at least - the newer features aren't I think.)
The problem is only on other OSes. As others have mentioned, a few have tried.
though one coded for prewindows DOS wouldn't work with 2000 or XP they could easily be ported.
Only if they intercept BIOS calls and somehow survive the transition into protected mode, and if the protected mode hardware drivers actually use the BIOS rather than go directly to the hardware. Which I think is very unlikely.
So no, I don't think this is possible *easily*. The best you could do would be to try and interfere with NTLDR and load a fake device driver than handles the re-infect, but that's a substantial amount of work, requiring a substantial amount of code to be hidden at boot time and would very likely be specific to a few versions of NTLDR.
In any case, to go back to the OP's case, you'd never trigger a boot sector virus on a slave drive.
Could you please explain what are the "problems it causes with SQL Server"?
As someone else pointed out above, there's a KB about it: default firewall settings break SQL Server's TCP/IP interface. Which, IMO, you shouldn't use ever.
WTF are you doing running a server database on XP in the first place? Really buddy, c'mon... SQL Server in XP?
Development. And testing.
And, as others have pointed out, running MSDE for applications that need it.
Thanks for the link - so default firewall settings break SQL server's TCP/IP interface: I didn't know that.
That said, you *shouldn't* be using the TCP/IP interface pretty much ever. If your client is on the same PC you should use "(local)" which will use either named pipes or shared memory IPC; if you're accessing another PC on the same network you should use named pipes and if you *really* need remote enterprise manager across the NET you should remote desktop into the PC and run it locally. Then there's no SP2 vs SQL Server issue *at all*.
on MSDN subscriber downloads. They're marked build 1214 which ties up with the last-but-one build of Windows XP 64-bit available. They've now just release Windows XP 64-bit build 1247 so chances are this is build 1247 of the 2003 SP1 code.
But we haven't tried it here yet: no obvious victim 2003 machine, and no problems with our web app on WinXP SP2 code.
Well duh, the code got corrupted in the time machine you used to get the Windows Server 2003 SP2.
He means XP SP2. (As you probably knew.)
FWIW, the XP SP2 release candidates broke SQLXML 3 which broke our web application but we've have *no problems* with SQL server on the final SP2 code.
NT4 SP3
Uh, on second thoughts I mean SP4 don't I? Bah.
Is it just me or are others pissed off that M$ has taken the term "Service Pack" and stretched it way beyond it's intended meaning?
They pioneered this years ago, way back with NT4 SP3. That was basically NT 4.5.
But *it was a free upgrade*. That's the distintion here: new version number, you pay for it.
I'm just wondering if there's something about Steam that really is radically different in terms of content delivery from typical online delivery, or the sort of delivery implemented by e.g., Bioware.
Critical mass. Everyone who has HL2 has Steam, and HL2 will likely sell big.