| |||||||||||||
Actually this is the case which is absolutely identical in Windows world.Actually this is the case which is absolutely identical in Windows world.Posted Jan 25, 2012 17:21 UTC (Wed) by khim (subscriber, #9252)In reply to: Yesterday... by Cyberax Parent article: Poettering: systemd for Administrators, Part XII
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.
(Log in to post comments)
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.
|
|||||||||||||