patrickd@chinet.chi.il.us (Patrick Deupree) (06/27/90)
In article <41900010@sunb3> meyer@sunb3.cs.uiuc.edu writes: >Let's put it this way: > Assume: for each developer, 10 users will be created. (an average) > > Marginal cost = 1 developer @ $500.00 500.00 Actually, I don't think they make this much off every copy of the SDK sold since most all of their sales are through dealers that charge somewhere along the lines of $300, which probably means that Microsoft is making somewhat less. > Marginal Revenue= 10 users @ $100.00 1000.00 > (Street price of Windows) To be fair, the software resellers will charge around $100 (the suggested retail is $150 for Windows 3.0) so you can figure that Microsoft is making somewhat less per sale. Now, as you'll see Microsoft would still make more from selling low cost SDK's however they'll not make nearly as much as this projection would indicate. So, if Microsoft dropped the retail price of the SDK to $150 they would have to either sell direct or they'd have to take a serious cut in their profits to go through their dealers. Selling direct would be tricky since the required enhancements to their sales staff would be difficult to deal with. >One must also keep in mind that the development of the SDK, to a major degree, >was NECESSARY to the development of Windows 3. Without putting the time and >effort into the SDK, Windows 3 would never have been. Therefore, SDK >development costs are, for the most part, a sunk cost. They are more properly >recovered from the sales of the final product, the environment. I'm sure that, if the SDK didn't exist, it would mean the price of Windows would go up. Selling the SDK is a way of dividing the profit into two smaller chunks instead of one large one. >And for Pete's sake, >provide upgrades for the poor S.O.B. who bought the last version of the SDK, >and helped to make that version successful. Hmm, I wasn't aware that Microsoft was not offering an SDK upgrade. >By your method, Patrick, the other developers are being charged for the >development of the environment, as well as having to pay for their own >development. Since this, too, must then be passed on to the user, this serves >to drive the applications' prices up, which results in a fewer number of users >buying the environment because they can't afford the applications they want to >use, or because the costs to the users outweigh the perceived benefits. Now, just to make one thing clear, I've not been talking as a spokesperson for either Microsoft or ourselves. My interest in this topic is purely economic since I've always had a love for marketing philosophy and economic strategy (or should that be marketing strategy and economic philosophy?) I would like to note that the price of Actor most likely does not have to do with the $300 or so that we've spent on the SDK or the $700 we've spent on On-Line. Quite frankly, this is a drop in the bucket compared to the man hours spent creating, maintaining, and enhancing Actor, the Toolkit, WinTrieve, Language Extensions, and Object Graphics. -- "Organized fandom is composed of a bunch of nitpickers with a thing for trivial pursuit." -Harlan Ellison Patrick Deupree -> patrickd@chinet.chi.il.us
nelson_p@apollo.HP.COM (Peter Nelson) (06/29/90)
:Actually, I don't think they make this much off every copy of the SDK sold
:since most all of their sales are through dealers that charge somewhere along
:the lines of $300, which probably means that Microsoft is making somewhat
:less.
[ etc ]
I think that our concern with the cost of the SDK is misplaced.
I think a bigger impediment to developing Windows apps is
the extreme complexity of the software required for writing
Windows and the lack of more tools to make it easier and
quicker. The only alternative to the SDK I know of is
Actor, which is also pricey, and which requires you to
learn Yet Another Language. I spend all day at work
writing in Pascal and then I go home and write programs
in C and I'm constantly typing "{" or "=" or "==", etc,
when I mean to do something else. (Thank God we're switching
over to more C at my job!)
Ever since Xlib came out there have been all kinds of layers
of tools and widgets built on top of it to make writing X apps
easier, although I can't personally vouch for how effective
they are. Why can't someone do this in Windows? Why can't
I buy a C library and set of <include> files to make writing
Windows apps simple so it doesn't take 100 lines, or whatever
to do "hello world"? The first guy who comes up with a good
product along these lines will have a real money-maker.
---Peterpkr@media01.UUCP (Peter Kriens) (06/29/90)
I don't think the price of the SDK is the real problem. The basic problem is that you need something like the SDK and, not to forget an expensive and unpleasant compiler like Microsoft C. If you look at the Mac & X-windows and many other windowing extensions, it seems possible to build a window system based on a run time interface. On the Mac it is the definition of the unused 68000 op-codes and in X-window it is Xlib. Because this relatively simple interface to a complex system it is possible to pick your choice in development tools. In microsoft windows you need a special compiler, a special linker and the SDK. All these products have been specialized for windows. What I would have liked, or like is a public domain specification of how to talk to a library and then use any commercial compiler in the market. In that case I wouldn't have the problem of paying a couple of hundred dollars for a SDK that offers me example code and utilities. And Microsoft could always bring out books to make money from. The biggest problem seems to be that Microsoft allowed the windows developers to specialize the linker and the compiler. Another big drawback of windows that we have found it extremely difficult to develop code for windows that is portable across multiple platforms because of the problems associated with memory management. All the code I have tried to write for ms-windows end up awfully bound to windows. Especially the moving segments make it very difficult to write code. A fact that is recognized by Microsoft from the fact that all the examples are compiled in small model (The "preferred" model [try writing a more usefull program than a clock in 64K!]). From our application side I would love to use windows because of the portability and choice in hardware. But we had so many problems in fighting the compiler and the memory management that we actually gave up. This in contrast with the Macintosh where you do not have to worry about all the problems associated with windows. Conclusion: I like the look of Windows 3.0 but the development process Microsoft forces you to use is so awfull that I am waiting for Broland or someone else to make it workable for larger projects.
wallwey@snoopy.Colorado.EDU (WALLWEY DEAN WILLIAM) (06/29/90)
In article <1270@media01.UUCP> pkr@media01.UUCP (Peter Kriens) writes: >The biggest problem seems to be that Microsoft allowed the windows >developers to specialize the linker and the compiler. It's not like MicroSoft had much of a choice. The reason the linker and compiler are so much different is because Windows Code is considerably different, most notably the calls to and from procedures. This is because windows is trying to move code around in memory to allow more efficient use of memory. (More important in a multitasking operating system.) If you are looking for something that is closer to X and the Macintosh, look to OS/2 version 2.0 This is were windowing software on the PC gets rid of its segmentation problems that make Windows and OS/2 ver 1.x so hard! Dean Wallwey ****************************************************************************** *-Dean Wallwey wallwey@snoopy.colorado.edu or wallwey@128.138.238.103 * *"If people drove cars like they run computers, 5% of the driving populating * *would die every business day in automobile accidents!" * * #define DISCLAIMER \ * * The above comments are my own and not necessarly that of my employer or\ * * school. grammer, spelling errors, real heavy flames > NULL * ******************************************************************************
hdan@walt.cc.utexas.edu (Dan Higdon) (06/29/90)
In article <4b476718.20b6d@apollo.HP.COM> nelson_p@apollo.HP.COM (Peter Nelson) writes: > > ......... Why can't someone do this in Windows? Why can't > I buy a C library and set of <include> files to make writing > Windows apps simple so it doesn't take 100 lines, or whatever > to do "hello world"? The first guy who comes up with a good > product along these lines will have a real money-maker. > > ---Peter Why don't you try using the "GENERIC" application that comes with the SDK? All it does is provide a "working" template of a very boring application, which you can then go into and change incrementally to be more like the exciting application that you want it to become. Using GENERIC, "hello world" takes about 1 line of additional coding: just hunt down the WM_PAINT message and replace the FillRect with a WriteString (or whatever Windows calls them, I'm personally an OS/2 PM programmer :-).
meyer@sunb5.cs.uiuc.edu (06/30/90)
>>And for Pete's sake, >>provide upgrades for the poor S.O.B. who bought the last version of the SDK, >>and helped to make that version successful. >Hmm, I wasn't aware that Microsoft was not offering an SDK upgrade. I was told by a MS Rep that there "Never have been and never will be, any updates to SDKs." I wish I could remember that guy's name - I was suspicious at the time, but I was more angry. Anyway, I noticed a couple of days ago that MS will be offering a SDK upgrade, after all. Me thinks Microsoft had better get some reps that are a 'bit more on the ball... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Don Meyer internet: dlmeyer@uiuc.edu "He who restricts another's right to self-defense is accomplice to any crime committed because of the lack of self defense."
bchin@wam.umd.edu (Weiyuan W. Chin) (06/30/90)
in response to the message from:
nelson_p@apollo.HP.COM (Peter Nelson)
Hewlett-Packard Apollo Division - Chelmsford, MA
>I posted questions about it a couple of months ago and
>received, on the net and via email, lots of horror stories
>about it. About how most standard C library functions like
>printf can't be used in the SDK, about the number of lines it
>takes to do even simple things, about how long it takes to
>get up to speed on it (*two* different people quoted me the
>figure of SIX MONTHS before I would be able to productively
>write code with the SDK), and about the difficulties in writing
>code for different hardware configurations.
I think it learning curve is about 3 to 4 months initially, then
about a month per major concept (ie. MDI, DDE, DLL ) if one is
trying to learn this *alone*, with just the manuals and a couple of
books. Having a guru around, using BBS's, Usenet, or Online support
will drastically cut down the time required. Yes, several standard
C functions will not work... but do you really *want* to use them?
And forsake the ability to swap out unused portions of code, move
memory around to get larger contiguous blocks, etc....?
The only one that seems a pain at first is printf(), which is easily
replaced with textout or MessageBoxes, and the rich set of new
Windows functions more than make up for the loss (however, that
also contributes to the learning curve). The real pain is learning the
message processing method Windows (_and_ other GUI's) operate, and
learning to be cooperative instead of assuming total control of the
system. The concept of Device Contexts (DC's) and handles help in
writing multi-configuration programs. Where else are you going to
find a program that can let you print to hundreds of different
printers and dozens of displays through one routine? Are you going
to limit yourself to CGA, EGA, and VGA? As long as you have a
driver (most companies write their windows driver right after their
autocad driver) you can use it. And I can design my program w/o
too much difficulty to look great using VGA, VESA, 8514/A, or
other custom screens.
>Just for fun I recently wrote a little GUI library in (Zortech) C.
>Nothing fancy; just buttons and sliders (3D, of course) and dialogue
>boxes and ways of associating screen-events like button pushes with C
>functions, etc. I used it to implement a 3D graphics viewer, but
>it's general purpose and now I'm porting my other apps to it.
>It's very simple, maybe a couple of dozen functions, and requires
>very little change to existing apps, except that it assumes you're
in graphics mode.
>
>Now I'm *not* trying to compare this to Windows except to say that
>that's all the functionality I NEED. Memory-management issues and
>multi-tasking and resizing the window, and so forth are not things
>the APPLICATION should have to worry about. They should be invisible
>to the application, as much as possible. ( I realize that DOS apps
If you don't worry about memory or how the window looks when resized,
who will? You don't have to worry about *how* windows moves memory
or where or when it moves it... you've got the handle and so when you
need it just lock the block down. And remember to unlock it. (for
most apps)
>have to worry about things like <near> or <far> pointers and such,
>but that's true even if you're not in Windows. Heck, Windows
>can already multitask lots of DOS apps as it is. If the apps were
>written with a compiler and run-time libraries designed to ensure
>well-behaved programs for a Windows environment it could probably
>multitask any such app.
>So I guess what I don't understand is why it's necessary for the
>API to be so complicated. It doesn't take a lot of complication
>just to support bottons and menus. And most of the other things
>I've seen people mention here would appear to be better addressed
>by the compiler, the libraries, or the run-time package.
True, it can multitask DOS apps... but that's not the primary reason
one would use Windows. If that's all you want, use Desqview. I
think the attraction are all the *goodies*: clipboard, Dynamic
Data Exchange, memory management ( I love to be able to do this:
hGlobalMem = GlobalAlloc( GMEM_MOVEABLE, 2048000 ); <--- two meg ),
Multiple Document Interface, Device Independent Bitmaps, multi-tasking
( I agree this area is a bit weak, though), hardware device independence
(both displays and printers), etc... And the Mac only has a few of
the above. As a Windows developer, you've got a lot more toys (oops,
tools) to play with and you can present a better, more cooperative, and
flexible (we're in the Bush era) app.
>>One excuse for complication people often mention is *performance
tuning*. Fine. Make such features available but don't force me to use
>them. CPU's are a LOT more powerful than they were a couple of years
>ago and for many people even hideously innefficient might run just fine.
If you're interested in only performance, Windows won't work for you.
Hell... multitasking a DOS machine won't help you either. I recommend
a 20mhz 386 w/ dual monitors (in order to run Codeview Windows), 4mb
of physical RAM and a fast HD for development work, but if you're just
going to run Windows apps, a 12mhz 286 with two-four megs would do.
Multitasking screen intensive DOS apps aren't efficient either...
and multitasking (in a window) graphics apps almost impossible under
Windows 3.0. And of course, the real solution is OS/2.
>Remeber,I'm saying this without having seen the SDK so if I have some
>major misconceptions feel free to flame me.
> ---Peter
Disclaimer:
My opinions are my own, not my employer's or anyone elses.
--
Bill Chin
University of Maryland College Park
internet: bchin@cville.umd.edunelson_p@apollo.HP.COM (Peter Nelson) (07/02/90)
From: bchin@wam.umd.edu (Weiyuan W. Chin)
:>that's all the functionality I NEED. Memory-management issues and
:>multi-tasking and resizing the window, and so forth are not things
:>the APPLICATION should have to worry about. They should be invisible
:>to the application, as much as possible. ( I realize that DOS apps
:
:If you don't worry about memory or how the window looks when resized,
:who will?
I assumed that this was handled by the Windows environment.
Look, I've been writing 3D graphics software for years for a
living and I don't recall ever having to concern myself with
resizing or moving windows. If effect, in a modern graphics
programming environment (by which I mean anything post - mid
1980's), applications write to *virtual* displays. The app
is layered on top of low-level display libraries, invisible to
the app, which map the virtual display to the physical one.
Now, it's true that modern workstations are much more powerful
than typical PC's, but these concepts date back several years
when workstations were much *wimpier* than today's PC's.
: You don't have to worry about *how* windows moves memory
:or where or when it moves it... you've got the handle and so when you
:need it just lock the block down. And remember to unlock it. (for
:most apps)
Since I'm not a Windows programmer, I don't know what "lock"
refers to. Why can't I just malloc the memory I need? The Windows
environment should "know" when my process is swapped in and ought to
be able to make sure that the space I malloc'ed is mapped. What's
the big deal?
---Peter
jshekhel@feds19.prime.com (Jerry Shekhel ) (07/02/90)
In article <22922@boulder.Colorado.EDU> wallwey@snoopy.Colorado.EDU (WALLWEY DEAN WILLIAM) writes: >In article <1270@media01.UUCP> pkr@media01.UUCP (Peter Kriens) writes: >>The biggest problem seems to be that Microsoft allowed the windows >>developers to specialize the linker and the compiler. > >If you are looking for something that is closer to X and the Macintosh, >look to OS/2 version 2.0 This is were windowing software on the PC gets >rid of its segmentation problems that make Windows and OS/2 ver 1.x so >hard! > I develop on OS/2 1.x, and guess what -- it ain't so hard! I just use the large memory model and ignore the segmentation "problems". OS/2 runs in protected mode with real virtual memory, so the OS shuffles memory around without the program ever knowing about it. I've NEVER had to use "far" or "near" in an OS/2 program, although you do have to use "_loadds" for all functions called back by PM (or alternately, register them as EXPORTS in the DEF file). As far as the API is concerned, I find it very logical. The Win library is object-oriented, which, I think, makes it easier to develop with than the Mac. The Gpi (graphics) library has capabilities that the base Mac and X libraries can only dream about. Overall, I find OS/2 to be an excellent development environment. I'm about to try Windows. > >Dean Wallwey > -- Jerry Shekhel