Why did MS make it so hard

Another vitally important detail is that Microsoft highly values backward compatibility. THAT’S A GOOD THING, PEOPLE!

Almost always, any program created NOW works on WinXP. That’s an amazing feat. Apple? That’s forced obsolescence taken to the Nth degree. I can’t tell you how many times I’ve seen the latest update of a program “require Lion and up” etc.

I totally disagree, these are extremely rare situations. If you are depending on something any higher than Standard/Home, you are a specialty app and that’s part of your work. Don’t whine about it.

Look, these discussion devolve into MS-bashing where everyone’s an expert and poses as a de facto Consumer Reports critic. In my experience, once I knew the rules, things worked just fine. I have my opinions (Win8 sucks, but I can completely avoid the new interface), but who really cares what I think? One of the reasons I work tech is that I wanted to avoid the boorish conversations between auto buffs about Ford and Chevy. Nothing ever changes, I guess.

Really, Window’s system is not terribly complicated as far as the user is concerned. And in comparison with OSX’s, it’s not any more complicated. What OSX does better is streamline it as far as the user’s PERCEPTION is concerned.

But as a programmer you can protect your customer from being embroiled in Windows abuses, if you follow the rules (funny, it’s the same in the OSX world). Simply install where you are supposed to, and provide your own DLL’s and try to minimize dependencies.

Welcome Garth, in a thread with the name “Why did MS make it so hard”,
and bashing Microsoft could be part of it :slight_smile:

Thats the point: I have to know about all of the differences in Home, Standard, Professional, Enterprise and how it influences my task of programming. And not all differences are well documented. That is a lot more of complexity for a programmer than to have one Operating System Version.
The .Net framework growth in functionality and things like Linq were extended to it so we developer have enough to know and learn to be up-to-date.

Systems evolv and grow, but at some point, their should be a review and the system has to be purified where possible. I wish the same for Java which has grown and grown and is now an ugly monster to me.

I do some pretty intense Windows programming and I never consider those differences. I could be wrong in that I can’t speak for everyone though, like I don’t delve into DB stuff.

One of my main points was to DIY. If you have to be concerned with OS variants, it means you are heavily leveraging the apps within the OS, not the core OS itself, and in my mind that can be a mistake. The OS variants aren’t different API’s per se but extra feature sets and internal (what I call) applications. For example, I wanted to be able to be able to log in remotely to a Win8 machine when Iw as out fo the office, but the 8 I have is just Home and that isn’t included. I don’t see what bearing that has on programming and API.

Sure, you can use a Win8-only API call, but everyone has to know what minimum system requirements are, even on Mac, so that’s not a complaint.

Lastly, part of the appeal of Xojo is that it protects you from these things, basically. (Or it’s not appealing, since Xojo really has to improve their Win support as far as look-and-feel.)

The backward compatibility has been strong but today it seems to have less importance.

When we look back today and use today’s frame of preference it’s not that difficult to point out major issues with one platform. But under all circumstances it’s indeed a poor solution that we have to accept.

I believe the bundle was a NextStep concept, which Apple bought (when their stock was about 83 cents/share) and built OSX and iOS upon. Hence NSBundle…(and NS everything) If Apple hadn’t made the giant leap of abandoning OS9/Classic for OSX/NextStep, I’m pretty sure this conversation would be “Why did Apple and MS make it so hard”. I would bet that if MS felt they were in danger of closing shop soon, they might abandon the Registry/Dll concepts and start from scratch too… (I bet they could do some amazing stuff if not anchored to 20+ years of baggage)

I am not sure to follow : what are exactly the differences between these versions ? A Xojo app will work the same under Standard, Pro, Enterprise, and Home. Of course, if you tap into more recent specifics, it will become a bit like Mac, you will not be able to keep legacy compatibility.

Tough love is part of love. Blind devotion is as bad as outright rejection. Pointing out bad aspects of Windows is not Windows bashing. As long as it remains factual, I see this as valuable information. As long as one sticks to pure Xojo, both Apple and Windows systems are quite equivalent. When it comes to calling the system, I find Windows more amicable. Maybe because I am more familiar with the API since VB4. And indeed what worked then still works today, a tribute to legacy compatibility. I am not sure about calling .NET functions, though. It may prove a challenge with older Windows system.

Windows 8 in Desktop mode is no more traitorous than Windows 7 : all Xojo programs work as ever without a glitch.

Now where Windows 8 and 8.1 really have done it, is with the “Windows Store”, or you will forgive me for nailing it, “Metro” UI and framework. Total incompatibility with Desktop, even the programming interface is different and that includes VB so keeping developers assets seem a daunting task that even Cocoa never required of Mac developers, the list could go on. Of course it means Xojo will probably never support that environment.

There is a huge contrafiction between the always repeated MS devotion for backwards compatibility, and the actual fact that Windows Store forces developers to rewrite all their apps with a new API, new tools, and not be able to easily port their code. Worse, the obligation to distribute through the Windows Store effectively cuts the legs of anyone pretending to distribute through his own web site. Beatrix Willius is right : the Metro thingy is a misguided attempt to force a phone UI into a desktop experience. But Microsoft missed the mark : forcing all desktop users into an iTunes Store is as ridiculous as if Apple suddenly made installation of Cocoa apps impossible out of the Apple Store. I can just imagine the outrage…

I endured the transition between OS9 and OS X. Was not always pretty. But indeed the new system has been a godsend. And the idea to rest on Unix made OS X a truly modern OS, when MS painfully tried to get its inspiration from its common work from OS/2. Some even suggested that without the IBM influence Windows would be even further backwards.

Interestingly enough, If MS was not busy destroying 30 years of Windows-with-windows, they could very easily evolve into a bundle of their own : nothing prevents them to place all the DLL into their own container the way Apple does. Unfortunately, they embarked on the Metro wild goose chase, and have forgotten all sense since.

Commonly shared DLLs that could be changed by another vendor was a bad design but I understand the decision. 84 MB drives were going for about $300 at the time. You simply couldn’t expect the users to be able reinstall the necessary DLLs along with each application back then. You also had tiny diskettes that you were having to use to distribute programs with (I once installed a program that came on 25 3.5 diskettes). DLL Hell was the end result of all of this, but really in the early 90’s, self-contained applications with all the files needed would have been a tough sell (although I wished they had given us that as a build option in the IDE).

Apple actually had used “Packages” prior to buying next and they served many similar purposes

That’s right. The OS/9 System suitcase must have been using that technology. Fonts too, if I remember right. Except they where a lot less easy to open than today’s bundles.

[quote=100972:@Michel Bujardet]That’s right. The OS/9 System suitcase must have been using that technology. Fonts too, if I remember right. Except they where a lot less easy to open than today’s bundles.

[/quote]

Oh, I forgot about those! I have to say I am glad the resource forks went away though. Cool concept, but not X-platform friendly at all

Suitcase files were actual files with resources; they were a special kind of resource file that could be opened without using ResEdit, either by double clicking or (prior to System 7) with Font/DA Mover.

And btw, even OS X 10.9 supports and uses the resource fork of files.

NTFS supported forked files too (Alternate data streams)
Very few apps including those from MS used it

Wow, you are completely fooled by Mac.

99.99% of programs on windows AND MAC use support files, the only difference is that MAC fools their user hidding the support files in a “container”

If you develop using a framework, your programs will need that framework’s support files, The difference is that in windows you instal this files ONCE, and all programs can share them.

For example in windows you can install the VB6 Runtime, or the .NetFramework, and the programs are only a few Mb, but for MAC, the Framewor MUST BE inside the Program’s container, so the program is much larger.

Another advantage is that if two or more programs use the same framework, the support files are loaded into RAM only ONCE.

Windows approach has pros and cons, but must of the cons are because of bad habits of proggramers.

First, Mac is not an acronym.

We (Mac users) don’t consider it “fooling” anyone, it’s an ease of use thing. The Mac platform makes it’s success with a much nicer user experience. From not needing installers, to easy removal - the whole experience of using third party programs on the Mac OS is just overall nicer from a user standpoint.

VB6 Runtime and .NetFramework are like Apple’s AppKit.framework and Foundation.framework which are already part of the operating system. If an app uses CoreData it does not need to include CoreData.framework in the app, it’s already there in the OS. Third party frameworks are what’s included in the bundle. These are things like Sparkle, and the now useless Growl.

If a Windows program needs a third party framework (a DLL) it has to install it, which in the eyes of Mac developers is just more hassle for the user. The minor advantages to sharing dlls across every program aren’t really advantages anymore, they were workarounds for the limitations of computers from the time when harddisk space and memory weren’t plentifully available.

On paper this looks great, in practice we (I develop on Windows) lived through DLL Hell. And from what I see .NET hell is not too far away. One of the reasons I love Xojo is absolutely no DLL hell.

Could MS’s vision work? Absolutely, but it would require version control that seems to be beyond what MS are capable of today and yesterday and probably tomorrow (can’t say for sure though).

This argument seems to be about “Let’s take the world” vs “Let’s be great” - Your choice as to who won.

That may be a plus from the developer perspective, but double-clicking on a file to install is as easy as it gets. I found mounting on the Mac a little disconcerting when I first used the Mac. Uninstall is only slightly easier on the Mac. Cool factor…Mac. Productivity…whatever system you are used to.

Drag & drop install is where its at :stuck_out_tongue:

I recall the first version of Office that did that and quite literally the Mac BU guys at MS blew the Office for Windows folks away with that one touch.

That said I don’t think MS “intent” was to make life hard
DLL’s/dylibs/shared libraries have lots of good reasons for existing on many platforms
Shared code - but not shared data - makes sense
And as long as the system can distinguish one version of a dylib from another so apps can get the right one then sharing the code should save in memory, on disk etc
But it has downsides too
Unfortunately it USED to be the case that every app installed it’s own version of the TCP stack (anyone recall that one) and so you could use Compuserve OR AOL but not both at the same time without some serious gyrations.
And DLL hell was born - because there were few guidelines or what existed wasn’t followed.
It’s always been possible for DLL’s to live right next to the app executable and the search path has provided for searching there first for a very long time.
But that’s not how software vendors tended to do it - nor did MS set guidelines early on to say this is how you should do things when you ship your apps.
So DLL hell perpetuated.
Everyone installed DLLs in the Windows System & folks replaced common dll’s with their own & … arggggg !!!
Now they do provide good guidance on how to do it right and IF you follow it then you should be good to go and NOT cause DLL hell.

I agree.

There are a number of simple rules that must be followed very carefully in order to keep complex things - like modern OSs - from getting very complicated:

  • Abstraction - layering of technology very carefully so as to minimize the information passing between layers and to allow the switching out of layers as development advances.

  • Encapsulation - related to abstraction, it’s the strategy of keeping implementation details ‘secret’ within sections of a program or system. Again, it allows for switching out of system sections as well as keeps the security of a system much tighter. Sharing DLLs made sense for a short period of time a long time ago. It should have been abandoned long long ago.

There are numerous other axioms and it’s been many years since I got my CS degree but the two above ideas are very effective for app design as well as OS design.

I was flabbergasted years ago when MS created the registry. It goes against basic computing science 101 design.

Think about it:

  • the Mac has made TWO major cpu architecture changes over the years and both of them very successfully. Talk about abstraction!
    (actually 3 when you realize that iOS is OS X for mobile and it runs on ARM)

  • OS X is inherently more secure than Windows (the debate rages on but it’s true. No AV software required is proof). Effective encapsulation & abstraction both play big roles.

As a cross-platform developer I really do appreciate the value of a long term platform like Win32. It’s amazing how long it’s been around. But can anyone say that computing on the Internet in 2014 is a good idea, in any way, using Windows XP?

To shepherd an OS along over many years requires making tough decisions and leaving outdated technology behind. It’s painful at times but I certainly don’t miss RS-232, floppies, parallel ports, CRTs, 68000, PowerPC, ADB, SCSI, token ring, VGA, cooperative multitasking, 8bit, 16 bit, etc, etc.

Now we’re in the process of leaving PCI, spinning magnetic platters, optical drives, mice, 32 bits and for many uses, keyboards.

We’ve trusted Apple to say no to the right things at the right time. Sometimes it chafes, but for me, the view on the other side just keeps getting better. WWDC this year showed that Apple is firing on all cylinders and we have a very robust platform beneath us.

That’s my 2 cents at least.