| |||||||||||||
Yesterday...Yesterday...Posted Jan 23, 2012 19:31 UTC (Mon) by khim (subscriber, #9252)In reply to: What success??? by dgm Parent article: Poettering: systemd for Administrators, Part XII
What was the last time you heard somebody that some random program stopped working in Linux because unstable ABI? Wrong question. Right question: when was the last time you heard somebody that some random program is no longer available in their distribution repository. And the answer will be: yesterday (gnochm). And it's quite hard to find out how many developers just gave up, but there are some estimates. At this point Windows Phone 7 has less users then Linux - yet there are some 50'000 apps for it. Debian has less then half of that. Sure, applications in Debian are usually more serious then some random screensavers in Android/iOS/WP7 markets - but this exactly the problem: it's not that hard to develop Linux program (Android or iOS APIs certainly look more alien then Linux APIs for Windows developer), but try to make it available for the user... and you'll hit the wall. Why? because all the Linux users I know of use software that comes from their distro repositories. Yup. That means that for 99% of users Linux is absolutely useless. People complain that iOS is "golden cage" because the only way to publish iOS program is to ask Apple, but in comparison to Linux it's paradise: Apple will kick you out only if it decides to compete with you, while Linux distributions can kick you out for bazillion different reasons - the most popular being "this obsolete application uses XYZ library which we want to remove and authors are not responsive. Come one: just why the authors should be "responsive"? They have create program, it works, users are happy, what right do you have to demand anything else? As drag said: As I've said years ago: Friedliness to ISV is almost directly proportional to market share: Linux is 1% (because of the aforementioned problems), Mac OS is 5-10% (it's better then Windows, but it still likes to do things like drop support for Carbon when 100% incompatible replacement was only available for eight years), and the rest is Windows (which is horrible in many ways but has excellent backward compatibility). As long as question about "how to install program on Linux?" question will remain "use the distribution's repo, stupid" Linux will be 1% niche. P.S. Note: I use Linux myself and I'm quite happy with it. I still hate the fact that I need to compile some programs from sources and I understand that as long as that's the case I can not in good conscience recommend it to my non-IT friends.
(Log in to post comments)
Yesterday... Posted Jan 24, 2012 14:56 UTC (Tue) by dgm (subscriber, #49227) [Link]
> Right question: when was the last time you heard somebody that some random program is no longer available in their distribution repository.
A good question for the distro, but not in the context of a reply to the original assertion, wich was: "Absolutely. If you do offer stable ABI then it's not guarantee of success (see Windows Phone), if you break the ABI then you lost".
In the same vein, Microsoft DOES break up ABI and API compatibility from time to time. I'm told that there are many programs that worked just fine under XP, but no longer do under Vista and Win 7.
Yesterday... Posted Jan 24, 2012 15:33 UTC (Tue) by khim (subscriber, #9252) [Link] In the same vein, Microsoft DOES break up ABI and API compatibility from time to time. I'm told that there are many programs that worked just fine under XP, but no longer do under Vista and Win 7. Sure. Nobody is perfect. Some programs don't work or work incorrectly. Especially low-level stuff like Visual Studio 6.0 (there are some problems with debugger). But the fact that Visual Studio 6.0 (released over 10 years ago) still works at all (and Visual Basic 6.0 is still fully supported) says you something.
Yesterday... Posted Jan 24, 2012 19:08 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> But the fact that Visual Studio 6.0 (released over 10 years ago) still works at all
Visual Studio 6.0 never worked to begin with, unless a very loose definition of "work" is applied. And besides, making old software work on Linux is usually just a matter of installing a few really old libraries.
Yesterday... Posted Jan 24, 2012 21:30 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Please, VisualStudio 6 was a very good IDE. It was fast, snappy and with Tomato plugin it had great autocomplete.
VisualC++ 6 was mediocre, mostly because it hasn't supported features like SFINAE and member templates. But it worked OK for simple C++.
Yesterday... Posted Jan 24, 2012 16:04 UTC (Tue) by mpr22 (subscriber, #60784) [Link] I'm told that there are many programs that worked just fine under XP, but no longer do under Vista and Win 7. Yes. The difference being, a significant proportion of them were doing things that Microsoft had told people to stop doing back when Windows 2000 was current.
Yesterday... Posted Jan 24, 2012 16:51 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Not really. Windows ABI is well designed and is incredibly stable. One can still run NT4-era programs without much problems now. Windows Vista mostly broke a lot of programs with embedded Internet Explorer controls. And usually not even seriously.
Besides, Windows uses "bring all your libraries with you" ideology, so it's very easy to package stuff.
To be fair, Linux kernel ABI and libc are very stable. And if you care to bring along all other libraries you can still run software from 1995 on the newest distributions. However, as we know, bundling libraries is discouraged in Linux.
Yesterday... Posted Jan 25, 2012 1:13 UTC (Wed) by Trelane (subscriber, #56877) [Link]
> However, as we know, bundling libraries is discouraged in Linux.
Last I knew, it was discouraged everywhere. Otherwise, you get to maintain security updates for all those libs.
Yesterday... Posted Jan 25, 2012 6:37 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Yet it's commonplace on Windows because it's easy. On Unix systems it's noticebly more complex.
Yesterday... Posted Jan 25, 2012 16:37 UTC (Wed) by nybble41 (subscriber, #55106) [Link]
Setting LD_LIBRARY_PATH is "noticeably more complex"? Personally I find that quite easy to do, and prefer it to the security nightmare which is the Windows default of automatically loading libraries from the current directory.
Yesterday... Posted Jan 25, 2012 16:48 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Try to bundle glibc with your app.
Bundling MSVCRT in Windows is a piece of cake.
Yesterday... Posted Jan 25, 2012 17:11 UTC (Wed) by nybble41 (subscriber, #55106) [Link]
I'll grant that glibc is an exception. Among other things, it's closely tied into the dynamic loader (ld-linux), the path to which is hard-coded into every executable, so setting LD_LIBRARY_PATH isn't sufficient here. The glibc team recommends a chroot environment, though you might be able to get away with specifying the proper loader explicitly. (It can be run as a normal program, with the dynamic executable path as an argument.)
Out of curiosity, why would you *want* to bundle glibc? They actually do a very good job of ensuring backward-compatibility, versioning the symbols where necessary. The fact that many Windows developers seem to feel it necessary to bundle their version of the C runtime with their application feels more like a handicap than a feature by comparison; on UNIX, the C runtime is traditionally considered a system component, not part of the application. If you're going so far as to bundle glibc, I don't see why you wouldn't just statically link the entire executable. That would certainly be much simpler from a distribution point-of-view.
Yesterday... Posted Jan 25, 2012 17:14 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Well, I've just built an executable on recent Ubuntu. And now I want to run it on RHEL 6.2. Guess what happens?
Static linking of glibc would be nice if it were supported.
Actually this is the case which is absolutely identical in Windows world. Posted Jan 25, 2012 17:21 UTC (Wed) by khim (subscriber, #9252) [Link] Well, I've just built an executable on recent Ubuntu. And now I want to run it on RHEL 6.2. Guess what happens? Absolutely the same thing as in Windows world. Hint: recent versions of MVCR*.dll just flat out refuse to work if you don't install them properly. To make portable application you need jump trough hoops. On Linux it means using older version of GLibC, on Windows you need specially crafted project. And you should not use features not available in older version of your OS (or you can use them conditionally when they are available). This is not such a big deal. Lack of forward compatibility is [relatively] easy to handle, but the fact that Linux constantly breaks backward compatibility is complete disaster.
Actually this is the case which is absolutely identical in Windows world. Posted Jan 25, 2012 17:29 UTC (Wed) by raven667 (subscriber, #5198) [Link]
That article is pretty funny, at every point the author has to say "wait, it's actually more complicated than that" and then drop another level down the rabbit hole. It's amazing Windows works as well as it does because what goes on under the hood is just ridiculous.
Actually this is the case which is absolutely identical in Windows world. Posted Jan 25, 2012 18:06 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Windows is like that. Over the years the famous DLL Hell problem led to a lot of "solutions" which are worse than problems they try to solve.
Yet it all somehow clunks along...
Actually this is the case which is absolutely identical in Windows world. Posted Jan 25, 2012 17:32 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
>Absolutely the same thing as in Windows world. Hint: recent versions of MVCR*.dll just flat out refuse to work if you don't install them properly.
Not true. MSVCRT DLLs work just fine if you put it beside the application. It's just that they have special 'magical' hooks into SxS.
But you can bundle them with your app. MS even recommends it: http://support.microsoft.com/kb/326922 and I've done it personally.
>On Linux it means using older version of GLibC
Which means that I have to find the most ancient distro, replicate all the toolchain (hey, do you know what fun it is to compile GCC 4.7 on CentOS 4?) and then build your app.
That is a very real pain point. And Something Must Be Done.
I'm thinking about binary patching executable file to make it look like it requires older version of glibc.
Actually this is the case which is absolutely identical in Windows world. Posted Jan 25, 2012 17:49 UTC (Wed) by jrn (subscriber, #64214) [Link]
Might be worth trying lsbcc first.
Sorry, but you are wrong... Posted Jan 25, 2012 19:05 UTC (Wed) by khim (subscriber, #9252) [Link] Not true. MSVCRT DLLs work just fine if you put it beside the application. Nope. msvcrt.dll (the old one from MSVC 6.0) does. Newer ones just complain bitterly "R6034 An application has made an attempt to load the C runtime library incorrectly". You can only install them as Shared Side-by-Side Assemblies (as explained here). It's just that they have special 'magical' hooks into SxS. Not only that. They are always shared (real private installation is no longer an option) and they must be installed in the system, not just dropped in the directory with your binary. I'm thinking about binary patching executable file to make it look like it requires older version of glibc. Will not work™. Linux does not even store the version of GLibC needed to run your application in binary linked with GLibC. What it does store is version of library function called from your program. And if you call new function not available in old version of GLibC (because you are using headers with redirect "open" to "__open_2") then you really need GLibC (or some other library) which will actually include these functions. What you can do is to create library which will provide such symbols (as weak alias, probably) for older versions of GLibC. But this sounds like an SDK - and if you are doing an SDK then you can just use older version of GLibC in it...
Sorry, but you are wrong... Posted Jan 25, 2012 20:10 UTC (Wed) by boudewijn (subscriber, #14185) [Link]
"Nope. msvcrt.dll (the old one from MSVC 6.0) does. Newer ones just complain bitterly "R6034 An application has made an attempt to load the C runtime library incorrectly". You can only install them as Shared Side-by-Side Assemblies (as explained here)."
And certain version(s) of Visual Studio would actually create the side-by-side assembly wrong, which meant we had to patch some xml files when delivering our application on Windows. That was quite a bit of an eye-opener.
Frankly, having produced software for Windows for twenty years, Linux for fifteen years and OSX for three years, I find there's precious little to advocate one platform over another. All have peculiarities, pitfalls and idiosyncrasies that are consume roughly the same amount of time when making end-user software ready for installation.
Free software on Linux has the advantage that as a volunteer developer I can leave most of that to the distributions, though. Makes life easy and lets me focus on coding...
There are huge difference, however... Posted Jan 25, 2012 21:27 UTC (Wed) by khim (subscriber, #9252) [Link] Frankly, having produced software for Windows for twenty years, Linux for fifteen years and OSX for three years, I find there's precious little to advocate one platform over another. All have peculiarities, pitfalls and idiosyncrasies that are consume roughly the same amount of time when making end-user software ready for installation. The interesting question happens after you've managed to write working installer. On Windows compatibility is big deal™ - this means that next versions of Windows will include bunch of hacks which will try to keep your software from breaking. They will not always work (it's not really possible), but it'll try to guess what to do with your program to make it usable (for example Windows Vista will automatically ask for administrator privileges for programs named install.exe or setup.exe - unless they include manifest which disabled such requests: this way old installers work and new installers may decide to not request admin provileges by default). On MacOS the same happens - but for limited time only. For example when Mac was transitioned from PowerPC to x86 it only supported old binaries for pathetic five years. Developers were forced to recompile (and sometimes rewrite) everything in this short period. On Linux... nobody cares. Beauty os the desktop is paramount and if it requires breaking the ABI - nobody will think twice. Libraries are added and removed in each revision of OS (sometimes even minor security updates change SO versions), files are moved around without any kinds autodetection, etc. And it looks like temporary stabilization I've talked about back then was short-lived: in last 3-4 years almost everything was broken on desktop (on level above libx11/glibc).
There are huge difference, however... Posted Jan 26, 2012 1:34 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> On Linux... nobody cares.
Yeah, except that they *do* care. That posting you've linked to is full of FUD and lies, you can find the details in my response to that posting (which I had written before realizing I was responding to a 3-year-old posting. Oh well).
That's funny. really... Posted Jan 26, 2012 8:18 UTC (Thu) by khim (subscriber, #9252) [Link] That posting you've linked to is full of FUD and lies Hardly. Instead it includes bitter truth - which nicely explained why Linux is constantly losing battle for desktop. you can find the details in my response to that posting (which I had written before realizing I was responding to a 3-year-old posting. Oh well). Nope. Not well. In fact it makes all the difference in a world. All the compatibility layers were afterthoughts and they were often added to the system later, often years later. When users have cried themselves hoarse and developers have left. In cases where they were added from the start (V4L) they were often buggy - and response from the driver developers was often "just stop using this obsolete interface", which is insulting for developers (who have other plans besides the need to chase random changes in Linux ABI) and absolutely unsuitable for users (who have no way to "stop using the obsolete interfaces"). As I've said: situation is slowly improving, but it's still far from perfect. You continue to say that you've run gtk2 and gtk3 applications side-by-side, that you've run Qt3 applications, etc but you forget to say what you needed to do to make them work. Usually you need to find some libraries or modules and install them, use LD_LIBRARY_PATH or other tricks. Nothing works out of the box. This is what I call nobody cares: "naïve" developers think that backward compatibility is OS developers responsibility first and theirs second if at all (most think OS developers should solve everything without them), "naïve" users think that they don't care who's responsible - but they do know they are not (especially if they paid for the application and OS... since OS is often free and "you can't get much for free" developer is usually one who's drowned in complains) and "self-righteous" Linux desktop architects "know" it's not theirs problem. The end result? 1% on desktop, lost mobile platform, etc. BTW current 1% is actually good result: at least you still have hardware which you can use to play your power games. Don't count on it to be available forever, though.
That's funny. really... Posted Jan 26, 2012 11:28 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> Nope. Not well. In fact it makes all the difference in a world. All the compatibility layers were afterthoughts and they were often added to the system later, often years later.
Please, stop spreading bullshit. ALSA has had an OSS emulation layer ever since it was merged into the kernel. PulseAudio has supported OSS and ALSA compatibility for ages.
> In cases where they were added from the start (V4L) they were often buggy
> As I've said: situation is slowly improving, but it's still far from perfect. You continue to say that you've run gtk2 and gtk3 applications side-by-side, that you've run Qt3 applications, etc but you forget to say what you needed to do to make them work.
Besides, I'd like to see some kind of backup for your claim that compatibility is as important as you seem to think it is. The only "application" I use that only supports OSS is Unreal Tournament, which works just fine. And I don't know many other people who use applications of similar age. I can't think of anyone, actually.
That's funny. really... Posted Jan 26, 2012 14:44 UTC (Thu) by khim (subscriber, #9252) [Link] Please, stop spreading bullshit. ALSA has had an OSS emulation layer ever since it was merged into the kernel. It's one thing to have something called "emulation layer". It's something else entirely to support old programs. For years said emulation layer was buggy and basically unusable. When I start Adobe Reader I should not lose the ability to watch YouTube videos - even if both use "obsolete" OSS interfaces. Linux desktop finally got good, usable OSS emulation in 2008 - years after switch from ALSA to OSS. > As I've said: situation is slowly improving, but it's still far from perfect. You continue to say that you've run gtk2 and gtk3 applications side-by-side, that you've run Qt3 applications, etc but you forget to say what you needed to do to make them work. Hardly. I use ekiga (gtk2) and pavucontrol (gtk3). Both are shipped with debian, the package manager pulls in the required dependencies. Ah, so to make them work you only need to give up your freedom and stop choosing your software for yourself - you should just use what your distribution offers you. This is good band-aid, but it does not solve the problem. ISVs are still out of the loop and this means Linux is still unsuitable for a desktop. The only "application" I use that only supports OSS is Unreal Tournament, which works just fine. And I don't know many other people who use applications of similar age. I can't think of anyone, actually. That's because there are none. Unreal Tournament is remnant of the brief era in which it looked like Linux is gearing to be real contender for a desktop. Then "great desktop designers" started breaking stuff repeatedly and ISVs abandoned their Linux efforts. Besides, I'd like to see some kind of backup for your claim that compatibility is as important as you seem to think it is. Well, it's kinda hard to do proper scientific experiment in this area, thus we only have one observation - but it's damning. We've had lots of OSes created for user-facing devices (desktops, mobile phones, tablets). Some of them cared about ABI stability (Windows/WindowsCE, MacOS/iOS, Palm, Symbian, etc), some have not (WindowsCE, Linux, Palm, etc). Note that couple of OSes are in two categories at once (WindowsCE and Palm). That's because they had two distinct phases: in one phase they cared about backward compatibility very much and in the next - they dropped it to create "greater, more popular platform". In all cases these attempts led to disaster: platform either died altogether or went below 1% market share for many years (most died, WindowsCE become incompatible Windows Phone 7 and while it's not technically dead yet it's market share collapsed catastrophically). Correlation looks quite striking - but one-sided. There are plenty of OSes which had good backward-compatibility yet failed anyway, but we have no widely used OSes which treat backward-compatibility as cavalierly as Linux does. Even MacOS does it better: it gives ISVs short time (just a few years) till they are forced to do major changes to the programs - but at least in this short period old programs still work just fine and neither users nor developers are forced to search for the solution on forums. Start PowerPC program in Intel Mac - and it works, no question asked. Believe me, difference between PowerPC binary and Intel binary is much larger then difference between OSS and ALSA.
That's funny. really... Posted Jan 26, 2012 15:10 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> It's one thing to have something called "emulation layer". It's something else entirely to support old programs. For years said emulation layer was buggy and basically unusable. When I start Adobe Reader I should not lose the ability to watch YouTube videos - even if both use "obsolete" OSS interfaces.
What you're asking for has nothing whatsoever to do with compatibility. You're asking for new features that exceed the ones that OSS provided in the first place, not for compatibility.
> Ah, so to make them work you only need to give up your freedom and stop choosing your software for yourself - you should just use what your distribution offers you. This is good band-aid, but it does not solve the problem. ISVs are still out of the loop and this means Linux is still unsuitable for a desktop.
> That's because there are none.
> Correlation looks quite striking - but one-sided.
Anyway, I'm really tired of wasting my time with your stupid trolling attempts. Have a nice life.
Please Posted Jan 26, 2012 15:31 UTC (Thu) by corbet (editor, #1) [Link] Can we please aim for a slightly higher level of discourse here?This is aimed at everybody, not just the immediate parent post. Disagreements are fine, but we do not need to fling personal insults at each other. If you think somebody is a troll, then don't feed them! If you must respond, please find a way to do so without turning LWN into some sort of elementary school playground, OK?
No, that's regression... Posted Jan 26, 2012 16:29 UTC (Thu) by khim (subscriber, #9252) [Link] What you're asking for has nothing whatsoever to do with compatibility. You're asking for new features that exceed the ones that OSS provided in the first place, not for compatibility. I've used RealVideo player in parallel to MP3 player with OSS in 1998, sorry. ALSA broke this ability not just for OSS applications, native ALSA applications can not issue any sound if Adobe Reader hogs the device either. And support was only reintroduced in 2008. That's 10 years, give or take. In fact, they do, e. g. Skype provides packages for various distros and a statically linked binary, in case all else fails. Exactly! They provide one version for Windows (85-90%+ market share), one version for Mac (5-10% market share) and eight versions for Linux (2-3% market share). Why? Because all these Linux versions have forsaken compatibility in the pursuit of pretty colors. And even then it does not work with all versions of Linux. For most ISVs this mess just does not make sense. There are hope: at least they can write "Ubuntu 10.4+ 32-bit." and are not forced to provide separate versions for Ubuntu 10.4, 10.10, 11.04, 11.10... but the fact that it's problematic to use 32bit version on 64bit Ubuntu is already quite aggravating and the need to provide eight packages to cover most (but not all!) distributions is just wrong. Yes, and that's the reason why nobody really cares about OSS compatibility (except for trolls like you). I don't care either at this point. OSS compatibility was sore point five years ago, but today it's thing of the past. Sadly linux desktop developers invent something new to break almost every year. Command & Conquer for Windows 95 wouldn't work on Windows XP (the installer crashes). Unless you'll run it in compatibility mode. I know: right-click and Run this program in compatibility mode is ubercomplicated trick and not all Windows users can do that. But it says something about expectations, too. And I didn't get Unreal II to work on Windows 7 either. Which is still possible if you install appropriate .dll files. Yes, Unreal II is rare case where Microsoft decided that small piece of API is not worth supporting in future versions of Windows thus you need to hunt down and install Windows Server 2003 DirectMusic Patch with proper versions of DirectMusic .DLLs. Somehow such activity is perceived as simple (some even say trivial) in Linux, yet when you hit the same trouble in Windows you've given up immediately. Don't it say something about your expectations?
No, that's regression... Posted Jan 26, 2012 20:22 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> I've used RealVideo player in parallel to MP3 player with OSS in 1998, sorry.
Then the sound card you used then probably had a hardware mixer.
> ALSA broke this ability not just for OSS applications, native ALSA applications can not issue any sound if Adobe Reader hogs the device either.
> Exactly! They provide one version for Windows (85-90%+ market share), one version for Mac (5-10% market share) and eight versions for Linux (2-3% market share). Why? Because all these Linux versions have forsaken compatibility in the pursuit of pretty colors. And even then it does not work with all versions of Linux.
> There are hope: at least they can write "Ubuntu 10.4+ 32-bit." and are not forced to provide separate versions for Ubuntu 10.4, 10.10, 11.04, 11.10... but the fact that it's problematic to use 32bit version on 64bit Ubuntu is already quite aggravating
> Unless you'll run it in compatibility mode.
> Which is still possible if you install appropriate .dll files.
That's funny. really... Posted Jan 26, 2012 18:12 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
>Yeah, except that it doesn't, because Windows really isn't all that backward-compatible either. Command & Conquer for Windows 95 wouldn't work on Windows XP (the installer crashes). And I didn't get Unreal II to work on Windows 7 either.
I actually have the original C&C disks. I've tried to install C&C from them, but disks have become unreadable over the years. So I downloaded it from TPB and installed it just fine in Win7 in compat mode.
There's a good story about Windows compatibility - they've actually made a special-purpose memory allocator for Win95 to work around a bug in Sim City.
Read it here: http://www.joelonsoftware.com/articles/APIWar.html - that's how much MS cared about compatibility.
That's funny. really... Posted Jan 26, 2012 19:56 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> I actually have the original C&C disks. I've tried to install C&C from them, but disks have become unreadable over the years. So I downloaded it from TPB and installed it just fine in Win7 in compat mode.
Well, it didn't work when I tried to install it from my disks. Perhaps this issue only applies to the german version or something.
That's funny. really... Posted Jan 29, 2012 15:00 UTC (Sun) by boudewijn (subscriber, #14185) [Link]
Hm... Emboldened by this discussion I tried to install any of my collection of Corel Painter disks on my Windows 7 installation. None would start. Items tried range from a ten year old Corel Painter Essentials disk to a Corel Painter X trial -- we're now at Corel Painter XII, btw.
We can blame Corel, of course... Their products have never had a reputation for being solid, well-built applications, but then, wasn't the contention in this thread that on Windows that's not necessary, since Windows keeps everything running through amazing binary compability through the ages?
Have you tried the usual tricks? Posted Jan 29, 2012 16:12 UTC (Sun) by khim (subscriber, #9252) [Link] Have you tried to run setup in "Windows XP" compatibility mode? Corel Painter 11 works fine. You can find and start setup.exe directly. In general the appropriate help page can help you. AFAICS from forum posts Corel Painter Essentials works fine with Windows 7... with the exception that it insists in scanning the whole system drive at each program start. Which is sloow as you can guess (45min startup time is not unheard of). Yes, Windows tries to stay compatible very hard - but it can not fix all the bugs in all the programs.
There are huge difference, however... Posted Jan 26, 2012 8:11 UTC (Thu) by boudewijn (subscriber, #14185) [Link]
"The interesting question happens after you've managed to write working installer."
After having created the installer, I write the next version of the application which means I'll have to write update installers, and on windows, figure out some way of semi-automatically updating the existing installed base. Which is always fun, if you've got half a million users.
And after having created the installer, I get bug reports, often about obscure incompatibilities between the development and testing systems and the user's windows system. For which I, sometimes, have to actually buy the actual hardware the user uses so I can figure out that the problem is related to the particular version of the Intel graphics driver Asus installs on that particular laptop model.
Or (ten years ago) that the application crashes Windows because the font the user has installed has some broken truetype code embedded that causes a kernel panic when hyphenating.
We have to face it: all operating systems suck, all hardware sucks and there is no such thing as a free lunch. Arguing that Windows makes life easier for a software developer than Linux is an exercise in futility.
Sorry, but you are wrong... Posted Jan 26, 2012 12:17 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
You're confusing two issues. You DO need a manifest to bind with the correct MSVCRT.
However, you can ship MSVCRT DLLs along with your app by simple copying without any installation. That's called "Private Assemblies": http://msdn.microsoft.com/en-us/library/aa375674.aspx
Let me quote this: http://msdn.microsoft.com/en-us/library/ms235299.aspx
>To deploy Visual C++ redistributable files, you can use the Visual C++ Redistributable Package (VCRedist_x86.exe, VCRedist_x64.exe, or VCRedist_ia64.exe) that is included in Visual Studio, or use Redistributable Merge Modules, or you can directly install specific Visual C++ DLLs to the application local folder. An application local folder is a folder that contains an executable application file. DLLs must be deployed to the application local folder.
As I've said, I've done this personally. It works.
Yesterday... Posted Feb 6, 2012 7:20 UTC (Mon) by elanthis (guest, #6227) [Link]
It's mostly commonplace on Windows because upstream often gives us little choice. Even if I compiled something like TinyXML, where would I put it that it would be found? How would I version the DLL? How do I make sure that my app isn't relying on a broken modified version someone else installed? It's not hard or difficult to build redistributable packages for Windows DLLs, but most upstream developers just don't bother. Possibly the installer toolchain just needs to be nicely integrated with Visual Studio.
The Linux ecosystem solves this with ham-fisted militarized regulation of software via the distribution package repositories. Which in turn results in very slow update cycles, a constant churn and a need to follow the bleeding edge for the entire OS to get a bug in one app fixed, and an inability to get a lot of software packaged for enough users because that packaging work has to be done 1000x times over for every possible distribution.
Which way is better? It depends on the use case (server, embedded, desktop, etc.). The desktop and consumer device market seems to be leaning towards bundled libraries, via means like the iOS App Store, Steam, and soon Windows Store. Especially when the Web hyperlink capabilities are used properly, they allow users to find software that most natural way (the Web) and then install software with minimal of fuss. No need to dig through a package repository after already having found the software online. No need to find out the latest available version of the software requires a library version the OS hasn't packaged yet. No need to find out that the latest version of the software has a bunch of features and fixes that the OS bundled package doesn't include and won't include for another 6 months (in which case the entire OS must be upgraded, along with possibly getting a whole new UI and a new slew of bugs, just to get that one application update).
The primary issues of bundled libraries -- space and security -- are a lot less interesting than most people think. Disk space is certainly cheap these days, and even the memory costs of loading multiple versions of a library for different apps are easy to ignore in today's post-32-bit world. The library security issues are things to be concerned about, but less so than most think. Sure, getting a patched OpenSSL right away is important on Linux, but then Linux is primarily a server OS. Everything it's running is some Internet-facing risk, and quite a few libraries are processing data that is literally sent to the machine from any ol' random node on the Internet.
On a modern day desktop OS there's practically only app that ever even hits the wide open 'Net is the Web browser. Users don't have much need to care that Random Grandma-Friendly Family Geneaology Wizard 2008 doesn't have the latest patched libpng because frankly it doesn't matter if it does or not; it doesn't grab random PNGs off the Internet and it's not an attack vector for any plausible threat.
Of course the "consumer-friendly" Linux-based OS (Android) uses this same application-centric distribution model. Users install and update individual self-contained applications or entire OS updates, not individual components of an OS+Apps repository. Small wonder.
Yesterday... Posted Feb 7, 2012 15:01 UTC (Tue) by dgm (subscriber, #49227) [Link]
Very accurate. But do not forget another of the consequences of the application-centric model: malware.
On a repository based system you have an additional layer of people reviewing the software that you will end running in your machine. Part of the responsibility for the excellent track record of desktop Linux with regards to malware is by this layer of people. A tightly controlled App Store, like Apple's, has a similar effect, but having access to the source code makes repositories much more effective.
Yesterday... Posted Jan 24, 2012 15:43 UTC (Tue) by dgm (subscriber, #49227) [Link]
> it's not that hard to develop Linux program (Android or iOS APIs certainly look more alien then Linux APIs for Windows developer), but try to make it available for the user... and you'll hit the wall.
Not my experience. Many moons ago I wrote a silly little app that relied on the GTK 1.2 toolkit. After publishing it in Sourceforge, an Ubuntu packager (hi Chris) got in touch, and shortly after I could install it from repositories. I doesn't get any easier, does it?
> Friedliness to ISV is almost directly proportional to market share
We do agree on that. But, again, that's not what I was replying to. Lack of (ABI) compatibility is not the cause for failure. Rather ISV unfriendliness (witch is a greater subject) is. Or put another way, you can be successful begin incompatible (OS X) and you can fail being compatible (OS/2). It's a bit more complex than that.
OEM friendliness is also a sore point. Note I mean the kind that just rushes cheap consumer hardware with crappy closed source drivers out the door and moves on. Currently you could buy any cheap piece of sh^Whardware and expect it to work on Windows. Or you could reach an Apple store and shell extra bucks for Apple approved hardware that will work with Macs. In any case, the rules are clear and easy. With Linux... well, it's a bit more work. But surprisingly Joe and Jane Sixpack don't care a bit. They want it easy, so they can go on with their own lives. Who nows, maybe they are up to something.
In any case, we seem to be in an stale mate situation. Ubuntu is trying HARD to break that, but even after all those years, you cannot go out and look for "made for Ubuntu" (or whatever) hardware and software in stores. Maybe the time will come. But a few things will have to change for that.
|
|||||||||||||