|
|
|
| Authored by: Wol on Sunday, January 27 2013 @ 04:53 AM EST |
Let's say you're building a car. You engage General Motors to make your engine.
Six months from launch, GM say "sorry, you'll have to provide your own
engine".
Could you design, build and test an engine, from scratch, in six months? (And in
this case, no the option of going to a GM competitor to buy an alternative
"off the shelf" engine doesn't exist.)
Cheers,
Wol[ Reply to This | Parent | # ]
|
| |
| Authored by: tknarr on Sunday, January 27 2013 @ 06:46 AM EST |
The problem is, as Wol pointed out, MS didn't just remove an API. They
removed the only way to access basic functionality. It's the equivalent of them
saying of the Windows Forms framework "Oh, sorry, we're removing the Control
class and all classes derived from it.". The result isn't just a minor change
for developers, it means that they have to implement, from scratch, every single
control. Even ones as simple as buttons. And while it'd be one thing if Control
had been an undocumented class only present in a pre-release version with
nothing official indicating it'd be around, it's quite another to release it as
part of the development packages handed out to give developers a head start on
WFC programming, include it in official documentation, advertise it to
developers as providing all those basic controls without them having to do the
work themselves, and then after developers have begun building their
applications and committed resources to following the Microsoft way of
developing to WFC, indeed at the last moment (only a few weeks before the
official release of the tools and the obsoleting of other MS-supported
development frameworks), only at that point does MS make the
announcement.
And I'd note that the above is why I don't recommend basing
any business plan around Microsoft's roadmaps. This isn't the first time they've
done this, it wasn't the last, and I always bear in mind the maxim "There's
always a sucker at the table. If you look around and can't spot him, it's
you.". [ Reply to This | Parent | # ]
|
| |
| Authored by: artp on Sunday, January 27 2013 @ 01:26 PM EST |
I would recommend trying to understand more. History is your friend. Read the
documents on this site (shouldn't take you more than ten years or so), take a
look at the various "Microsoft Dirty Tricks" sites scattered around
the Web, including this one, and maybe you will start to see a trend here.
If your experience with Microsoft is only over the last five or ten years, then
you might be missing some of the longer-term strategies that Microsoft has had
in place that they don't have to take credit for in any obvious manner.
I first ran into Microsoft when I was handed an 8" floppy in 1982. They
were terrible then. They have maintained that margin with respect to other
software over the years, and have even widened it. Their software has always
been targeted at looking good. Performance and accuracy have always taken a back
seat. Stability and security are apparently not in their vocabulary.
If you have no other data points to measure Microsoft by, then, yes, they look
pretty good. You will assume that computers are supposed to work that way and
fail that way. But if you have used quality software (forget about how it
looks), then you will know the problem here.
---
Userfriendly on WGA server outage:
When you're chained to an oar you don't think you should go down when the galley
sinks ?[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Sunday, January 27 2013 @ 10:18 PM EST |
“If Novell programmers were competent, mature and
professional software
developers they would have adapted to
the API change quickly and met their
deadline or shortly
there after”, anonymous
You must be new to
groklaw, as the Novell case has been much
discussed, in particular you might be
interested in what the
Comes v.
Microsoft docs have to
say about the difficulties third party
developers
have writing to the Microsoft API.
-------
“the biggest
advantage our apps group has is a
ccess to the
operating systems source, as long as this
continues, the issue will never
go away”
“I believe that Microsoft application developers have
been given earlier and more detailed access to OCX
specifications than we have had here at Lotus”
“If that is
not w
hy these
programmers used the undoc'd APIs in the code,
then give me a plausable
explaination for why they did.
truthful would be nice”
`The
Windows Product Marketing team .. has decided to
produce and distribute a
"patch" disk for both PerfectOffice
and WordPerfect 6.1 for Windows .. It
should be noted that
these bugs, for the most part, are not problems with our software (the Win95 bugs are
problems we
addressed with Microsoft which they refused to
fix) .. Total cost for this
Project: $11,500.00'
“My MAPI service providers that used to
work in the M7
time frame (January beta) no longer seem to work. Can we get documentation on the changes that have been
made to the APls
(especially transport and address book)
since M7”.
“Below is
the text of 2 messages sent previously
regarding header files and libraries for
implementing a
Windows 95 Password Provider. .. If the constants and API's have been removed, why are they
so well
documented? Also, if they have been removed, how
do we integrated password
changes with Windows 95”
“the new MAPI32.DLL that is deployed as
part of Office 97
breaks GroupWise 5 operation. There are now "required" calls/properties that are not documented as such”
“should we
take the remaining
undocumented calls out of Excel? We don't need them”.[ Reply to This | Parent | # ]
|
|
|
|
|
