Re: lyx2lyx script broken (1.6.0 on Vista)
This has gone on far too long, and I'm not really interested in arguing the point. But some of your response is simply factually incorrect. So, for the record: Andre Poenitz wrote: On Sun, Nov 23, 2008 at 11:21:27AM -0500, Michael Wojcik wrote: Andre Poenitz wrote: On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote: I've worked on many projects that maintained backward compatibility with new releases of the API, and seen a great many more. Just for my curiosity: Which projects, which scope? - Early versions of Windows. The Windows 1.x to Windows 2.0 and Windows/286 transition maintained compatibility in the Windows API; Windows 1.x applications ran unchanged in the 2.0 family. Windows 2.0 was released pretty exactly two years after 1.0, Windows 3.0 completely broke the API 2 1/2 years later. 16-bit Windows applications continued to run unchanged under Windows 3.0. So, at best, that's a period of 4.5 years of API stability. That's close to a joke, especially when taking into account that 3.11 was not usable for any reasonable practical purpose... Tell that to the hundreds of customers we sold development tools for Windows 2.0. - X11R3. The X11 API was layered correctly: as long as the server follows the protocol spec, it doesn't matter what it does under the covers. I added support for new hardware to the ddx layer; wrote new window managers with completely different look-and-feel from the standard ones; added extensions to X11 itself. None of that interfered with existing clients one bit. X11R3: End of 88, X11R4: End of 89. And clients continued to work. And they still work, under X11R5. New releases came out and API compatibility was maintained. Which was my point. Pretty much around 1990 supposedly the last person died that used plain X. What's plain X? Everyone always ran windows managers on top of X11. That's part of the architecture. - The 4.3 BSD kernel. Extended multihead support in the console driver and wrote some drivers for new hardware. Enhanced the shared memory kernel option. Nothing that didn't want to use the new features needed to be recompiled. Spring (?) 2001 - January 2002. I don't know what those dates are supposed to refer to. BSD 4.3 was released in 1986. BSD 4.4 in 1994. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
On Thu, Dec 04, 2008 at 06:20:40PM -0500, Michael Wojcik wrote: This has gone on far too long, and I'm not really interested in arguing the point. When I am not really interested in arguing a point anymore, I just stop doing it. I don't consider that a bad habit. [...] So, for the record: 16-bit Windows applications continued to run unchanged under Windows 3.0. Except for the ones that did not get enough main memory anymore thanks to the fatter system. Those simply would refuse to work... [Win 1.0 - 3.0] So, at best, that's a period of 4.5 years of API stability. That's close to a joke, especially when taking into account that 3.11 was not usable for any reasonable practical purpose... Tell that to the hundreds of customers we sold development tools for Windows 2.0. First, this leaves a few more developers whom you did _not_ sell your development tools. Second, selling someone a brush and a few buckets of paint does not necessarily mean that the house he's living in is in good shape. Etc. Anyway. That's subjective. [...] X11R3: End of 88, X11R4: End of 89. And clients continued to work. And they still work, under X11R5. New releases came out and API compatibility was maintained. And still a lot of user code broke. Wasn't it even Motif++ that barely survived the jump from R3 to R4? [And where is it nowadays?] Which was my point. And my point was that maintaining compatibility is possible, if the feature set is pretty much frozen and all new development is done in some kind of add-on. And even then it's not _easily_ possible. Remember the time when suddenly no Turbo Pascal program could start on new machines because the time calibration loop was executed too quickly causing a division by zero? Luckily people could use hex editors back then ;-} Pretty much around 1990 supposedly the last person died that used plain X. What's plain X? Everyone always ran windows managers on top of X11. That's part of the architecture. Plain X as in Xlib, possibly with Xt. In contrast to, say, Athena, Motif, Gtk or whatever toolkit of the day - with way shorter life cycles than the basic library. [...] Spring (?) 2001 - January 2002. I don't know what those dates are supposed to refer to. BSD 4.3 was released in 1986. BSD 4.4 in 1994. I already admitted that I indeed mixed up the BSD factions here. So you are right. _Something_ was factual incorrect. Andre'
Re: lyx2lyx script broken (1.6.0 on Vista)
This has gone on far too long, and I'm not really interested in arguing the point. But some of your response is simply factually incorrect. So, for the record: Andre Poenitz wrote: On Sun, Nov 23, 2008 at 11:21:27AM -0500, Michael Wojcik wrote: Andre Poenitz wrote: On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote: I've worked on many projects that maintained backward compatibility with new releases of the API, and seen a great many more. Just for my curiosity: Which projects, which scope? - Early versions of Windows. The Windows 1.x to Windows 2.0 and Windows/286 transition maintained compatibility in the Windows API; Windows 1.x applications ran unchanged in the 2.0 family. Windows 2.0 was released pretty exactly two years after 1.0, Windows 3.0 completely broke the API 2 1/2 years later. 16-bit Windows applications continued to run unchanged under Windows 3.0. So, at best, that's a period of 4.5 years of API stability. That's close to a joke, especially when taking into account that 3.11 was not usable for any reasonable practical purpose... Tell that to the hundreds of customers we sold development tools for Windows 2.0. - X11R3. The X11 API was layered correctly: as long as the server follows the protocol spec, it doesn't matter what it does under the covers. I added support for new hardware to the ddx layer; wrote new window managers with completely different look-and-feel from the standard ones; added extensions to X11 itself. None of that interfered with existing clients one bit. X11R3: End of 88, X11R4: End of 89. And clients continued to work. And they still work, under X11R5. New releases came out and API compatibility was maintained. Which was my point. Pretty much around 1990 supposedly the last person died that used plain X. What's plain X? Everyone always ran windows managers on top of X11. That's part of the architecture. - The 4.3 BSD kernel. Extended multihead support in the console driver and wrote some drivers for new hardware. Enhanced the shared memory kernel option. Nothing that didn't want to use the new features needed to be recompiled. Spring (?) 2001 - January 2002. I don't know what those dates are supposed to refer to. BSD 4.3 was released in 1986. BSD 4.4 in 1994. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
On Thu, Dec 04, 2008 at 06:20:40PM -0500, Michael Wojcik wrote: This has gone on far too long, and I'm not really interested in arguing the point. When I am not really interested in arguing a point anymore, I just stop doing it. I don't consider that a bad habit. [...] So, for the record: 16-bit Windows applications continued to run unchanged under Windows 3.0. Except for the ones that did not get enough main memory anymore thanks to the fatter system. Those simply would refuse to work... [Win 1.0 - 3.0] So, at best, that's a period of 4.5 years of API stability. That's close to a joke, especially when taking into account that 3.11 was not usable for any reasonable practical purpose... Tell that to the hundreds of customers we sold development tools for Windows 2.0. First, this leaves a few more developers whom you did _not_ sell your development tools. Second, selling someone a brush and a few buckets of paint does not necessarily mean that the house he's living in is in good shape. Etc. Anyway. That's subjective. [...] X11R3: End of 88, X11R4: End of 89. And clients continued to work. And they still work, under X11R5. New releases came out and API compatibility was maintained. And still a lot of user code broke. Wasn't it even Motif++ that barely survived the jump from R3 to R4? [And where is it nowadays?] Which was my point. And my point was that maintaining compatibility is possible, if the feature set is pretty much frozen and all new development is done in some kind of add-on. And even then it's not _easily_ possible. Remember the time when suddenly no Turbo Pascal program could start on new machines because the time calibration loop was executed too quickly causing a division by zero? Luckily people could use hex editors back then ;-} Pretty much around 1990 supposedly the last person died that used plain X. What's plain X? Everyone always ran windows managers on top of X11. That's part of the architecture. Plain X as in Xlib, possibly with Xt. In contrast to, say, Athena, Motif, Gtk or whatever toolkit of the day - with way shorter life cycles than the basic library. [...] Spring (?) 2001 - January 2002. I don't know what those dates are supposed to refer to. BSD 4.3 was released in 1986. BSD 4.4 in 1994. I already admitted that I indeed mixed up the BSD factions here. So you are right. _Something_ was factual incorrect. Andre'
Re: lyx2lyx script broken (1.6.0 on Vista)
This has gone on far too long, and I'm not really interested in arguing the point. But some of your response is simply factually incorrect. So, for the record: Andre Poenitz wrote: > On Sun, Nov 23, 2008 at 11:21:27AM -0500, Michael Wojcik wrote: >> Andre Poenitz wrote: >>> On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote: I've worked on many projects that maintained backward compatibility with new releases of the API, and seen a great many more. >>> Just for my curiosity: Which projects, which scope? >> - Early versions of Windows. The Windows 1.x to Windows 2.0 and >> Windows/286 transition maintained compatibility in the Windows API; >> Windows 1.x applications ran unchanged in the 2.0 family. > > Windows 2.0 was released pretty exactly two years after 1.0, Windows 3.0 > completely broke the API 2 1/2 years later. 16-bit Windows applications continued to run unchanged under Windows 3.0. > So, at best, that's a > period of 4.5 years of "API stability". That's close to a joke, > especially when taking into account that < 3.11 was not usable for any > reasonable practical purpose... Tell that to the hundreds of customers we sold development tools for Windows 2.0. >> - X11R3. The X11 API was layered correctly: as long as the server >> follows the protocol spec, it doesn't matter what it does under the >> covers. I added support for new hardware to the ddx layer; wrote new >> window managers with completely different look-and-feel from the >> standard ones; added extensions to X11 itself. None of that interfered >> with existing clients one bit. > > X11R3: End of 88, X11R4: End of 89. And clients continued to work. And they still work, under X11R5. New releases came out and API compatibility was maintained. Which was my point. > Pretty much around 1990 supposedly the last person died that used plain X. What's "plain X"? Everyone always ran windows managers on top of X11. That's part of the architecture. >> - The 4.3 BSD kernel. Extended multihead support in the console driver >> and wrote some drivers for new hardware. Enhanced the shared memory >> kernel option. Nothing that didn't want to use the new features needed >> to be recompiled. > > Spring (?) 2001 - January 2002. I don't know what those dates are supposed to refer to. BSD 4.3 was released in 1986. BSD 4.4 in 1994. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
On Thu, Dec 04, 2008 at 06:20:40PM -0500, Michael Wojcik wrote: > This has gone on far too long, and I'm not really interested in > arguing the point. When I am not really interested in arguing a point anymore, I just stop doing it. I don't consider that a bad habit. > [...] > So, for the record: > 16-bit Windows applications continued to run unchanged under Windows 3.0. Except for the ones that did not get enough main memory anymore thanks to the fatter system. Those simply would refuse to work... > [Win 1.0 - 3.0] > > So, at best, that's a > > period of 4.5 years of "API stability". That's close to a joke, > > especially when taking into account that < 3.11 was not usable for any > > reasonable practical purpose... > > Tell that to the hundreds of customers we sold development tools for > Windows 2.0. First, this leaves a few more developers whom you did _not_ sell your development tools. Second, selling someone a brush and a few buckets of paint does not necessarily mean that the house he's living in is in good shape. Etc. Anyway. That's subjective. > > [...] X11R3: End of 88, X11R4: End of 89. > > And clients continued to work. And they still work, under X11R5. New > releases came out and API compatibility was maintained. And still a lot of user code broke. Wasn't it even Motif++ that barely survived the jump from R3 to R4? [And where is it nowadays?] > Which was my point. And my point was that maintaining compatibility is possible, if the feature set is pretty much frozen and all new development is done in some kind of add-on. And even then it's not _easily_ possible. Remember the time when suddenly no Turbo Pascal program could start on new machines because the time calibration loop was executed too quickly causing a division by zero? Luckily people could use hex editors back then ;-} > > Pretty much around 1990 supposedly the last person died that used plain X. > > What's "plain X"? Everyone always ran windows managers on top of X11. > That's part of the architecture. "Plain X" as in "Xlib", possibly with Xt. In contrast to, say, Athena, Motif, Gtk or whatever toolkit of the day - with way shorter life cycles than the "basic library". > > [...] > > Spring (?) 2001 - January 2002. > > I don't know what those dates are supposed to refer to. BSD 4.3 was > released in 1986. BSD 4.4 in 1994. I already admitted that I indeed mixed up the BSD factions here. So you are right. _Something_ was factual incorrect. Andre'
Re: lyx2lyx script broken (1.6.0 on Vista)
Jean-Marc Lasgouttes wrote: Completely infeasible on Windows. The loss of shared text would make the working set of the typical application mix grossly exceed even the absurd amounts of RAM available in typical machines today. The disk space problem would be even worse. I meant just for application which feel that they have to distribute their own version-of-the-day of whatever.dll. There is no reason to do it everywhere of course. Still not feasible, unfortunately, because that includes everything linked with any of the Microsoft C/C++ runtime DLLs. This is the central problem: if you build an application that uses anything in the MS C/C++ library (Microsoft combines the C and C++ standard libraries into a single DLL), which means pretty much anything built with a Microsoft C or C++ compiler, or with the Microsoft Platform SDK, you'll link against some specific version of one or more of the MSVC DLLs. You don't have much choice about which version you get - it depends on what version of the compiler or SDK you have installed, and what updates have been applied to it. For someone else to run that binary, they need that exact same version of the MSVC DLLs. In older versions of the Microsoft toolchain, you could just drop the MSVC DLLs into the same directory as your executable. That's no longer allowed (I think as of Visual Studio 2005 and Platform SDK 6.0). Now they have to be installed into the SxS tree. Microsoft's solution is for every application linked against any MSVC DLL to include the redistributable DLL package for that specific MSVC version as part of their installer package. So it's not the application developers who want you to install a dozen versions of the MSVC runtime. They don't know what versions you already have installed. There's no way to coordinate versions among unrelated applications. People build and distribute binaries, and they carry with them MSVC version requirements. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: On Tue, Nov 18, 2008 at 03:47:45PM -0500, Michael Wojcik wrote: Jean-Marc Lasgouttes wrote: What's wrong with static linking? At least it goes away when the application goes away. Completely infeasible on Windows. ... Many people have done back-of-the-envelope calculations to demonstrate this; I think I did some myself, in a post to alt.folklore.computers some time back. Some time back I was disputing the sheer possibility to catch a virus using email. Still ... environments ... came up that made _not catching one_ an art... So things done a while back do not count in IT. That's one of the silliest generalizations I've seen in some time. People who ignore the history of IT are doomed to repeat it. Usually poorly. In this specific case, the situation has only gotten worse. However, I have no particular interest in demonstrating it. If you think static linking is feasible on Windows, go ahead and build LyX that way. Mac OS X pretty much shows that _not_ sharing shared libraries on an application level is a feasible approach to DLL hell. I wouldn't take anything Apple does as a model. I've used too many Apple products. And avoiding shared code in applications is a solution to DLL hell (which is a system administration problem, not an application architecture one) in the same way that walking is a solution to airplane safety. It's a lousy idea in any case, as anyone who remembers compiling all of BSD 4.2 to switch from local-files resolution to DNS remembers. Dynamic linking lets you fix the bug or add the feature in one place. So why go from libstdc++.so.5 to libstdc++.so.6 at all, if incompatible changes can be, as you seem to say, avoided? Because there are many changes that *are* compatible? I'm not a libstdc++ maintainer, so I don't know offhand what the differences in those two releases are; and I'm not going to trawl through the release notes to find out. But it's very rare that a bug fix, or even a new feature, needs to alter an existing API, so there's no reason for it to introduce incompatibility. (Maintaining undefined behavior isn't a compatibility issue. Applications that rely on undefined behavior are broken.) Dynamic linking is a good thing. It's worked very well on a number of OSes. Examples? Most mainframe OSes - all of the MVS and VM family, for example. Also IBM's midrange OSes from S/38 through AS/400 to iOS. Many Unix variants, such as SVR4 and AIX. I believe dynamic linking in VMS wasn't bad, though I only ever looked at it briefly. Worked pretty well on OS/2. For that matter, it often works well on Windows, when DLL management is done properly. It would work on Windows if Microsoft could figure out 1) how to version properly, and 2) how to maintain backward compatibility. And it's not like those are unsolved problems. I am happy to have learned now that these problems are solved. They were solved decades ago. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote: Andre Poenitz wrote: On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: I've worked on many projects that maintained backward compatibility with new releases of the API, and seen a great many more. Just for my curiosity: Which projects, which scope? Hmm. Off the top of my head, in roughly chronological order: - Various IBM internal-only projects, such as the E editor. - Early versions of Windows. The Windows 1.x to Windows 2.0 and Windows/286 transition maintained compatibility in the Windows API; Windows 1.x applications ran unchanged in the 2.0 family. - X11R3. The X11 API was layered correctly: as long as the server follows the protocol spec, it doesn't matter what it does under the covers. I added support for new hardware to the ddx layer; wrote new window managers with completely different look-and-feel from the standard ones; added extensions to X11 itself. None of that interfered with existing clients one bit. - The 4.3 BSD kernel. Extended multihead support in the console driver and wrote some drivers for new hardware. Enhanced the shared memory kernel option. Nothing that didn't want to use the new features needed to be recompiled. - A number of Micro Focus commercial products and components thereof: AAI, CSB, CCI, MFCC ... These are commercial APIs used by paying customers to build in-house and ISV commercial applications. Changing them and breaking existing mission-critical applications isn't good for business. But we release updates a few times a year for most of them. Take AAI, for example. AAI 1.0 came out in 1988, and had major new releases for the next 10 years. Typical AAI purchases were in the $10K to $300K range, with yearly maintenance fees. The 1998 release had a feature set probably five times as large as in the 1988 release and ran on a dozen more platforms (from 16-bit Windows to big iron). We still shipped, as one of the demos, the original 1988 demo source - unchanged. The *binaries* from 1988 still ran, unchanged. The 1988 AAI clients and servers interoperated with the 1998 ones, with no user intervention (just a bit of automatic protocol negotiation). Maintaining backward compatibility simply is not that hard. I am still pretty convinced that compatibility and progress are fairly incompatible notions when it comes to the development of _usable_ libraries. And I'll say that my experience as a professional software developer for 20 years, and as a hobbyist for a number of years prior to that, shows me otherwise. you try to provide everything and the kitchen sink, and end up with design and implementation decisions that need to be re-evaluated from time to time in the presence of new environments. Java and Python, or anything including a GUI comes to mind. I'll offer X11 as a counterexample. And in this case, we're talking C and C++ runtimes, which should conform to the ISO standard anyway. Ah... should they conform to the Standard or should they be compatible to older versions? To the standard. What is supposed to happen if an existing version does _not_ conform to the Standard? Since the standards attempt to codify existing practice, that rarely happens. The only case that comes to mind of an incompatible change in the C standard, between C90 (ISO 9899-1990) and C99, is the choice of return code semantics for snprintf when it was added to the standard. There were two implementations with different semantics; the committee chose the sensible one. The only significant broken implementations by that point were HP's and Microsoft's, and Microsoft's doesn't really count because 1) the canonical name of the function in the Microsoft libraries was _sprintf, an identifier reserved to the implementation, and 2) Microsoft wasn't inclined to follow the standard anyway. Also: What am I supposed to do in case there is no obvious standard to adhere to? I have e.g. a few hundred kLOC of pre-1998 C++ code (done well before 1998...) around that's uncompilable with todays compilers. Who is to blame here? Should g++ have sticked to 2.95's view of the world? That's not a dynamic-runtime issue, which is what we were discussing. It's another problem entirely - the overly large and loose definition of the C++ language. In particular that would mean not only source and binary but also behavioural compatibility including keeping buggy behaviour. No it doesn't. Undefined behavior is undefined; an application that relies on it is broken. What is an application supposed to do when it lives in an environment where only buggy libraries are available? Suck it up? Might as well ask what a car is supposed to do in an environment with no roads. That's not a design failure in the car, nor a mistake on the part of the car's engineers; and neither does it mean that cars are a bad idea. And for the rare application that does, there are other Windows mechanisms
Re: lyx2lyx script broken (1.6.0 on Vista)
On Sun, Nov 23, 2008 at 10:26:30AM -0500, Michael Wojcik wrote: Jean-Marc Lasgouttes wrote: Completely infeasible on Windows. The loss of shared text would make the working set of the typical application mix grossly exceed even the absurd amounts of RAM available in typical machines today. The disk space problem would be even worse. I meant just for application which feel that they have to distribute their own version-of-the-day of whatever.dll. There is no reason to do it everywhere of course. Still not feasible, unfortunately, because that includes everything linked with any of the Microsoft C/C++ runtime DLLs. *cough* We were _not_ talking about statically linking _everything_. We were talking about things like Qt which are not a typical part of a Windows system. This is the central problem: if you build an application that uses anything in the MS C/C++ library (Microsoft combines the C and C++ standard libraries into a single DLL), which means pretty much anything built with a Microsoft C or C++ compiler, or with the Microsoft Platform SDK, you'll link against some specific version of one or more of the MSVC DLLs. You don't have much choice about which version you get - it depends on what version of the compiler or SDK you have installed, and what updates have been applied to it. [...] [...] [...] You are fighting windmills. Andre'
Re: lyx2lyx script broken (1.6.0 on Vista)
On Sun, Nov 23, 2008 at 11:21:27AM -0500, Michael Wojcik wrote: Andre Poenitz wrote: On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote: Andre Poenitz wrote: On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: I've worked on many projects that maintained backward compatibility with new releases of the API, and seen a great many more. Just for my curiosity: Which projects, which scope? Hmm. Off the top of my head, in roughly chronological order: - Various IBM internal-only projects, such as the E editor. - Early versions of Windows. The Windows 1.x to Windows 2.0 and Windows/286 transition maintained compatibility in the Windows API; Windows 1.x applications ran unchanged in the 2.0 family. Windows 2.0 was released pretty exactly two years after 1.0, Windows 3.0 completely broke the API 2 1/2 years later. So, at best, that's a period of 4.5 years of API stability. That's close to a joke, especially when taking into account that 3.11 was not usable for any reasonable practical purpose... - X11R3. The X11 API was layered correctly: as long as the server follows the protocol spec, it doesn't matter what it does under the covers. I added support for new hardware to the ddx layer; wrote new window managers with completely different look-and-feel from the standard ones; added extensions to X11 itself. None of that interfered with existing clients one bit. X11R3: End of 88, X11R4: End of 89. In any case, this is a nice example for something that is finished at some point of time. Nobody changed 7 bit ASCII for a while for that matter. If a feature set is closed at some point of time it is easy to outsource the problems to extensions and toolkits. Pretty much around 1990 supposedly the last person died that used plain X. [No, that was not me *cough*] SCNR ;-) - The 4.3 BSD kernel. Extended multihead support in the console driver and wrote some drivers for new hardware. Enhanced the shared memory kernel option. Nothing that didn't want to use the new features needed to be recompiled. Spring (?) 2001 - January 2002. I can't/won't comment on the others. Maintaining backward compatibility simply is not that hard. We are _not_ talking about _two_ years here. I can maintain compatibility over two years by simply ignoring advancements in the outside world for that long and release incompatible version x+1 after that. I am still pretty convinced that compatibility and progress are fairly incompatible notions when it comes to the development of _usable_ libraries. And I'll say that my experience as a professional software developer for 20 years, and as a hobbyist for a number of years prior to that, shows me otherwise. Fine. My experience so far shows that one has a choice between stagnation and breaking compatibility. And making that choice is neither obvious nor easy. you try to provide everything and the kitchen sink, and end up with design and implementation decisions that need to be re-evaluated from time to time in the presence of new environments. Java and Python, or anything including a GUI comes to mind. I'll offer X11 as a counterexample. X11 has certainly its merits and is time proven. Still it puts a lot of burden on the application developer, or, at the very least, on the toolkit developer. Lots of the initial design decisions that do not scale well into the 21st century are only bearable because of the outsourcing mentioned above. Plain X11 does _not_ come with kitchen sinks. And in this case, we're talking C and C++ runtimes, which should conform to the ISO standard anyway. Ah... should they conform to the Standard or should they be compatible to older versions? To the standard. That rules out fixing bugs, and it also breaks compatibility. I do not say that's a bad choice - in fact that's what I'd do in most cases - but it is incompatible with your statement that maintaining compatibility is possible _and easy_. What is supposed to happen if an existing version does _not_ conform to the Standard? Since the standards attempt to codify existing practice, that rarely happens. Hear, hear. How come ISO 14882 codifies export for templates when not a single compiler was able to handle that in 1998 (and for a few years after that)? Apart from that the point is not how often it happens but that it happens at all. You just admit that it happens. The only case that comes to mind of an incompatible change in the C standard, between C90 (ISO 9899-1990) and C99, is the choice of return code semantics for snprintf when it was added to the standard. There were two implementations with different semantics; the committee chose the sensible one. The only significant broken implementations by that point were HP's and Microsoft's, and Microsoft's doesn't really count because 1) the canonical name of the function in the Microsoft libraries was _sprintf, an identifier reserved to the
Re: lyx2lyx script broken (1.6.0 on Vista)
On 23/11/2008 16:26, Michael Wojcik wrote: In older versions of the Microsoft toolchain, you could just drop the MSVC DLLs into the same directory as your executable. That's no longer allowed (I think as of Visual Studio 2005 and Platform SDK 6.0). Now they have to be installed into the SxS tree. FYI, unless I'm misunderstanding you, that's not really true, many open source (or not) programs distribute the C and C++ runtime along the executable and the manifest file. We do that for LyX for example. So the old method still stands. Abdel.
Re: lyx2lyx script broken (1.6.0 on Vista)
- The 4.3 BSD kernel. Extended multihead support in the console driver and wrote some drivers for new hardware. Enhanced the shared memory kernel option. Nothing that didn't want to use the new features needed to be recompiled. Spring (?) 2001 - January 2002. Sorry to jump into your thread. But the dates are many years off. 4.3BSD kernel was released by CSRG in 1986.
Re: lyx2lyx script broken (1.6.0 on Vista)
Jean-Marc Lasgouttes wrote: Completely infeasible on Windows. The loss of shared text would make the working set of the typical application mix grossly exceed even the absurd amounts of RAM available in typical machines today. The disk space problem would be even worse. I meant just for application which feel that they have to distribute their own version-of-the-day of whatever.dll. There is no reason to do it everywhere of course. Still not feasible, unfortunately, because that includes everything linked with any of the Microsoft C/C++ runtime DLLs. This is the central problem: if you build an application that uses anything in the MS C/C++ library (Microsoft combines the C and C++ standard libraries into a single DLL), which means pretty much anything built with a Microsoft C or C++ compiler, or with the Microsoft Platform SDK, you'll link against some specific version of one or more of the MSVC DLLs. You don't have much choice about which version you get - it depends on what version of the compiler or SDK you have installed, and what updates have been applied to it. For someone else to run that binary, they need that exact same version of the MSVC DLLs. In older versions of the Microsoft toolchain, you could just drop the MSVC DLLs into the same directory as your executable. That's no longer allowed (I think as of Visual Studio 2005 and Platform SDK 6.0). Now they have to be installed into the SxS tree. Microsoft's solution is for every application linked against any MSVC DLL to include the redistributable DLL package for that specific MSVC version as part of their installer package. So it's not the application developers who want you to install a dozen versions of the MSVC runtime. They don't know what versions you already have installed. There's no way to coordinate versions among unrelated applications. People build and distribute binaries, and they carry with them MSVC version requirements. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: On Tue, Nov 18, 2008 at 03:47:45PM -0500, Michael Wojcik wrote: Jean-Marc Lasgouttes wrote: What's wrong with static linking? At least it goes away when the application goes away. Completely infeasible on Windows. ... Many people have done back-of-the-envelope calculations to demonstrate this; I think I did some myself, in a post to alt.folklore.computers some time back. Some time back I was disputing the sheer possibility to catch a virus using email. Still ... environments ... came up that made _not catching one_ an art... So things done a while back do not count in IT. That's one of the silliest generalizations I've seen in some time. People who ignore the history of IT are doomed to repeat it. Usually poorly. In this specific case, the situation has only gotten worse. However, I have no particular interest in demonstrating it. If you think static linking is feasible on Windows, go ahead and build LyX that way. Mac OS X pretty much shows that _not_ sharing shared libraries on an application level is a feasible approach to DLL hell. I wouldn't take anything Apple does as a model. I've used too many Apple products. And avoiding shared code in applications is a solution to DLL hell (which is a system administration problem, not an application architecture one) in the same way that walking is a solution to airplane safety. It's a lousy idea in any case, as anyone who remembers compiling all of BSD 4.2 to switch from local-files resolution to DNS remembers. Dynamic linking lets you fix the bug or add the feature in one place. So why go from libstdc++.so.5 to libstdc++.so.6 at all, if incompatible changes can be, as you seem to say, avoided? Because there are many changes that *are* compatible? I'm not a libstdc++ maintainer, so I don't know offhand what the differences in those two releases are; and I'm not going to trawl through the release notes to find out. But it's very rare that a bug fix, or even a new feature, needs to alter an existing API, so there's no reason for it to introduce incompatibility. (Maintaining undefined behavior isn't a compatibility issue. Applications that rely on undefined behavior are broken.) Dynamic linking is a good thing. It's worked very well on a number of OSes. Examples? Most mainframe OSes - all of the MVS and VM family, for example. Also IBM's midrange OSes from S/38 through AS/400 to iOS. Many Unix variants, such as SVR4 and AIX. I believe dynamic linking in VMS wasn't bad, though I only ever looked at it briefly. Worked pretty well on OS/2. For that matter, it often works well on Windows, when DLL management is done properly. It would work on Windows if Microsoft could figure out 1) how to version properly, and 2) how to maintain backward compatibility. And it's not like those are unsolved problems. I am happy to have learned now that these problems are solved. They were solved decades ago. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote: Andre Poenitz wrote: On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: I've worked on many projects that maintained backward compatibility with new releases of the API, and seen a great many more. Just for my curiosity: Which projects, which scope? Hmm. Off the top of my head, in roughly chronological order: - Various IBM internal-only projects, such as the E editor. - Early versions of Windows. The Windows 1.x to Windows 2.0 and Windows/286 transition maintained compatibility in the Windows API; Windows 1.x applications ran unchanged in the 2.0 family. - X11R3. The X11 API was layered correctly: as long as the server follows the protocol spec, it doesn't matter what it does under the covers. I added support for new hardware to the ddx layer; wrote new window managers with completely different look-and-feel from the standard ones; added extensions to X11 itself. None of that interfered with existing clients one bit. - The 4.3 BSD kernel. Extended multihead support in the console driver and wrote some drivers for new hardware. Enhanced the shared memory kernel option. Nothing that didn't want to use the new features needed to be recompiled. - A number of Micro Focus commercial products and components thereof: AAI, CSB, CCI, MFCC ... These are commercial APIs used by paying customers to build in-house and ISV commercial applications. Changing them and breaking existing mission-critical applications isn't good for business. But we release updates a few times a year for most of them. Take AAI, for example. AAI 1.0 came out in 1988, and had major new releases for the next 10 years. Typical AAI purchases were in the $10K to $300K range, with yearly maintenance fees. The 1998 release had a feature set probably five times as large as in the 1988 release and ran on a dozen more platforms (from 16-bit Windows to big iron). We still shipped, as one of the demos, the original 1988 demo source - unchanged. The *binaries* from 1988 still ran, unchanged. The 1988 AAI clients and servers interoperated with the 1998 ones, with no user intervention (just a bit of automatic protocol negotiation). Maintaining backward compatibility simply is not that hard. I am still pretty convinced that compatibility and progress are fairly incompatible notions when it comes to the development of _usable_ libraries. And I'll say that my experience as a professional software developer for 20 years, and as a hobbyist for a number of years prior to that, shows me otherwise. you try to provide everything and the kitchen sink, and end up with design and implementation decisions that need to be re-evaluated from time to time in the presence of new environments. Java and Python, or anything including a GUI comes to mind. I'll offer X11 as a counterexample. And in this case, we're talking C and C++ runtimes, which should conform to the ISO standard anyway. Ah... should they conform to the Standard or should they be compatible to older versions? To the standard. What is supposed to happen if an existing version does _not_ conform to the Standard? Since the standards attempt to codify existing practice, that rarely happens. The only case that comes to mind of an incompatible change in the C standard, between C90 (ISO 9899-1990) and C99, is the choice of return code semantics for snprintf when it was added to the standard. There were two implementations with different semantics; the committee chose the sensible one. The only significant broken implementations by that point were HP's and Microsoft's, and Microsoft's doesn't really count because 1) the canonical name of the function in the Microsoft libraries was _sprintf, an identifier reserved to the implementation, and 2) Microsoft wasn't inclined to follow the standard anyway. Also: What am I supposed to do in case there is no obvious standard to adhere to? I have e.g. a few hundred kLOC of pre-1998 C++ code (done well before 1998...) around that's uncompilable with todays compilers. Who is to blame here? Should g++ have sticked to 2.95's view of the world? That's not a dynamic-runtime issue, which is what we were discussing. It's another problem entirely - the overly large and loose definition of the C++ language. In particular that would mean not only source and binary but also behavioural compatibility including keeping buggy behaviour. No it doesn't. Undefined behavior is undefined; an application that relies on it is broken. What is an application supposed to do when it lives in an environment where only buggy libraries are available? Suck it up? Might as well ask what a car is supposed to do in an environment with no roads. That's not a design failure in the car, nor a mistake on the part of the car's engineers; and neither does it mean that cars are a bad idea. And for the rare application that does, there are other Windows mechanisms
Re: lyx2lyx script broken (1.6.0 on Vista)
On Sun, Nov 23, 2008 at 10:26:30AM -0500, Michael Wojcik wrote: Jean-Marc Lasgouttes wrote: Completely infeasible on Windows. The loss of shared text would make the working set of the typical application mix grossly exceed even the absurd amounts of RAM available in typical machines today. The disk space problem would be even worse. I meant just for application which feel that they have to distribute their own version-of-the-day of whatever.dll. There is no reason to do it everywhere of course. Still not feasible, unfortunately, because that includes everything linked with any of the Microsoft C/C++ runtime DLLs. *cough* We were _not_ talking about statically linking _everything_. We were talking about things like Qt which are not a typical part of a Windows system. This is the central problem: if you build an application that uses anything in the MS C/C++ library (Microsoft combines the C and C++ standard libraries into a single DLL), which means pretty much anything built with a Microsoft C or C++ compiler, or with the Microsoft Platform SDK, you'll link against some specific version of one or more of the MSVC DLLs. You don't have much choice about which version you get - it depends on what version of the compiler or SDK you have installed, and what updates have been applied to it. [...] [...] [...] You are fighting windmills. Andre'
Re: lyx2lyx script broken (1.6.0 on Vista)
On Sun, Nov 23, 2008 at 11:21:27AM -0500, Michael Wojcik wrote: Andre Poenitz wrote: On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote: Andre Poenitz wrote: On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: I've worked on many projects that maintained backward compatibility with new releases of the API, and seen a great many more. Just for my curiosity: Which projects, which scope? Hmm. Off the top of my head, in roughly chronological order: - Various IBM internal-only projects, such as the E editor. - Early versions of Windows. The Windows 1.x to Windows 2.0 and Windows/286 transition maintained compatibility in the Windows API; Windows 1.x applications ran unchanged in the 2.0 family. Windows 2.0 was released pretty exactly two years after 1.0, Windows 3.0 completely broke the API 2 1/2 years later. So, at best, that's a period of 4.5 years of API stability. That's close to a joke, especially when taking into account that 3.11 was not usable for any reasonable practical purpose... - X11R3. The X11 API was layered correctly: as long as the server follows the protocol spec, it doesn't matter what it does under the covers. I added support for new hardware to the ddx layer; wrote new window managers with completely different look-and-feel from the standard ones; added extensions to X11 itself. None of that interfered with existing clients one bit. X11R3: End of 88, X11R4: End of 89. In any case, this is a nice example for something that is finished at some point of time. Nobody changed 7 bit ASCII for a while for that matter. If a feature set is closed at some point of time it is easy to outsource the problems to extensions and toolkits. Pretty much around 1990 supposedly the last person died that used plain X. [No, that was not me *cough*] SCNR ;-) - The 4.3 BSD kernel. Extended multihead support in the console driver and wrote some drivers for new hardware. Enhanced the shared memory kernel option. Nothing that didn't want to use the new features needed to be recompiled. Spring (?) 2001 - January 2002. I can't/won't comment on the others. Maintaining backward compatibility simply is not that hard. We are _not_ talking about _two_ years here. I can maintain compatibility over two years by simply ignoring advancements in the outside world for that long and release incompatible version x+1 after that. I am still pretty convinced that compatibility and progress are fairly incompatible notions when it comes to the development of _usable_ libraries. And I'll say that my experience as a professional software developer for 20 years, and as a hobbyist for a number of years prior to that, shows me otherwise. Fine. My experience so far shows that one has a choice between stagnation and breaking compatibility. And making that choice is neither obvious nor easy. you try to provide everything and the kitchen sink, and end up with design and implementation decisions that need to be re-evaluated from time to time in the presence of new environments. Java and Python, or anything including a GUI comes to mind. I'll offer X11 as a counterexample. X11 has certainly its merits and is time proven. Still it puts a lot of burden on the application developer, or, at the very least, on the toolkit developer. Lots of the initial design decisions that do not scale well into the 21st century are only bearable because of the outsourcing mentioned above. Plain X11 does _not_ come with kitchen sinks. And in this case, we're talking C and C++ runtimes, which should conform to the ISO standard anyway. Ah... should they conform to the Standard or should they be compatible to older versions? To the standard. That rules out fixing bugs, and it also breaks compatibility. I do not say that's a bad choice - in fact that's what I'd do in most cases - but it is incompatible with your statement that maintaining compatibility is possible _and easy_. What is supposed to happen if an existing version does _not_ conform to the Standard? Since the standards attempt to codify existing practice, that rarely happens. Hear, hear. How come ISO 14882 codifies export for templates when not a single compiler was able to handle that in 1998 (and for a few years after that)? Apart from that the point is not how often it happens but that it happens at all. You just admit that it happens. The only case that comes to mind of an incompatible change in the C standard, between C90 (ISO 9899-1990) and C99, is the choice of return code semantics for snprintf when it was added to the standard. There were two implementations with different semantics; the committee chose the sensible one. The only significant broken implementations by that point were HP's and Microsoft's, and Microsoft's doesn't really count because 1) the canonical name of the function in the Microsoft libraries was _sprintf, an identifier reserved to the
Re: lyx2lyx script broken (1.6.0 on Vista)
On 23/11/2008 16:26, Michael Wojcik wrote: In older versions of the Microsoft toolchain, you could just drop the MSVC DLLs into the same directory as your executable. That's no longer allowed (I think as of Visual Studio 2005 and Platform SDK 6.0). Now they have to be installed into the SxS tree. FYI, unless I'm misunderstanding you, that's not really true, many open source (or not) programs distribute the C and C++ runtime along the executable and the manifest file. We do that for LyX for example. So the old method still stands. Abdel.
Re: lyx2lyx script broken (1.6.0 on Vista)
- The 4.3 BSD kernel. Extended multihead support in the console driver and wrote some drivers for new hardware. Enhanced the shared memory kernel option. Nothing that didn't want to use the new features needed to be recompiled. Spring (?) 2001 - January 2002. Sorry to jump into your thread. But the dates are many years off. 4.3BSD kernel was released by CSRG in 1986.
Re: lyx2lyx script broken (1.6.0 on Vista)
Jean-Marc Lasgouttes wrote: >> Completely infeasible on Windows. The loss of shared text would make >> the working set of the typical application mix grossly exceed even the >> absurd amounts of RAM available in typical machines today. The disk >> space problem would be even worse. > > I meant just for application which feel that they have to distribute > their own version-of-the-day > of whatever.dll. There is no reason to do it everywhere of course. Still not feasible, unfortunately, because that includes everything linked with any of the Microsoft C/C++ runtime DLLs. This is the central problem: if you build an application that uses anything in the MS C/C++ library (Microsoft combines the C and C++ standard libraries into a single DLL), which means pretty much anything built with a Microsoft C or C++ compiler, or with the Microsoft Platform SDK, you'll link against some specific version of one or more of the MSVC DLLs. You don't have much choice about which version you get - it depends on what version of the compiler or SDK you have installed, and what updates have been applied to it. For someone else to run that binary, they need that exact same version of the MSVC DLLs. In older versions of the Microsoft toolchain, you could just drop the MSVC DLLs into the same directory as your executable. That's no longer allowed (I think as of Visual Studio 2005 and Platform SDK 6.0). Now they have to be installed into the SxS tree. Microsoft's solution is for every application linked against any MSVC DLL to include the redistributable DLL package for that specific MSVC version as part of their installer package. So it's not the application developers who want you to install a dozen versions of the MSVC runtime. They don't know what versions you already have installed. There's no way to coordinate versions among unrelated applications. People build and distribute binaries, and they carry with them MSVC version requirements. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: > On Tue, Nov 18, 2008 at 03:47:45PM -0500, Michael Wojcik wrote: >> Jean-Marc Lasgouttes wrote: >>> What's wrong with static linking? At least it goes away when the >>> application goes away. >> Completely infeasible on Windows. ... >> Many people have done >> back-of-the-envelope calculations to demonstrate this; I think I did >> some myself, in a post to alt.folklore.computers some time back. > > Some time back I was disputing the sheer possibility to catch a virus > using email. Still ... "environments" ... came up that made _not catching > one_ an art... So "things done a while back" do not count in IT. That's one of the silliest generalizations I've seen in some time. People who ignore the history of IT are doomed to repeat it. Usually poorly. In this specific case, the situation has only gotten worse. However, I have no particular interest in demonstrating it. If you think static linking is feasible on Windows, go ahead and build LyX that way. > Mac OS X pretty much shows that _not_ sharing shared libraries on an > application level is a feasible approach to DLL hell. I wouldn't take anything Apple does as a model. I've used too many Apple products. And avoiding shared code in applications is a solution to "DLL hell" (which is a system administration problem, not an application architecture one) in the same way that walking is a solution to airplane safety. >> It's a lousy idea in any case, as anyone who remembers compiling all >> of BSD 4.2 to switch from local-files resolution to DNS remembers. >> Dynamic linking lets you fix the bug or add the feature in one place. > > So why go from libstdc++.so.5 to libstdc++.so.6 at all, if > incompatible changes can be, as you seem to say, avoided? Because there are many changes that *are* compatible? I'm not a libstdc++ maintainer, so I don't know offhand what the differences in those two releases are; and I'm not going to trawl through the release notes to find out. But it's very rare that a bug fix, or even a new feature, needs to alter an existing API, so there's no reason for it to introduce incompatibility. (Maintaining undefined behavior isn't a compatibility issue. Applications that rely on undefined behavior are broken.) >> Dynamic linking is a good thing. It's worked very well on a number of >> OSes. > > Examples? Most mainframe OSes - all of the MVS and VM family, for example. Also IBM's midrange OSes from S/38 through AS/400 to iOS. Many Unix variants, such as SVR4 and AIX. I believe dynamic linking in VMS wasn't bad, though I only ever looked at it briefly. Worked pretty well on OS/2. For that matter, it often works well on Windows, when DLL management is done properly. >> It would work on Windows if Microsoft could figure out 1) how to >> version properly, and 2) how to maintain backward compatibility. And >> it's not like those are unsolved problems. > > I am happy to have learned now that these problems are solved. They were solved decades ago. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: > On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote: >> Andre Poenitz wrote: >>> On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: >> I've worked on many projects that maintained backward compatibility >> with new releases of the API, and seen a great many more. > > Just for my curiosity: Which projects, which scope? Hmm. Off the top of my head, in roughly chronological order: - Various IBM internal-only projects, such as the E editor. - Early versions of Windows. The Windows 1.x to Windows 2.0 and Windows/286 transition maintained compatibility in the Windows API; Windows 1.x applications ran unchanged in the 2.0 family. - X11R3. The X11 API was layered correctly: as long as the server follows the protocol spec, it doesn't matter what it does under the covers. I added support for new hardware to the ddx layer; wrote new window managers with completely different look-and-feel from the standard ones; added extensions to X11 itself. None of that interfered with existing clients one bit. - The 4.3 BSD kernel. Extended multihead support in the console driver and wrote some drivers for new hardware. Enhanced the shared memory kernel option. Nothing that didn't want to use the new features needed to be recompiled. - A number of Micro Focus commercial products and components thereof: AAI, CSB, CCI, MFCC ... These are commercial APIs used by paying customers to build in-house and ISV commercial applications. Changing them and breaking existing mission-critical applications isn't good for business. But we release updates a few times a year for most of them. Take AAI, for example. AAI 1.0 came out in 1988, and had major new releases for the next 10 years. Typical AAI purchases were in the $10K to $300K range, with yearly maintenance fees. The 1998 release had a feature set probably five times as large as in the 1988 release and ran on a dozen more platforms (from 16-bit Windows to big iron). We still shipped, as one of the demos, the original 1988 demo source - unchanged. The *binaries* from 1988 still ran, unchanged. The 1988 AAI clients and servers interoperated with the 1998 ones, with no user intervention (just a bit of automatic protocol negotiation). Maintaining backward compatibility simply is not that hard. > I am still pretty convinced that "compatibility" and "progress" are > fairly incompatible notions when it comes to the development of _usable_ > libraries. And I'll say that my experience as a professional software developer for 20 years, and as a hobbyist for a number of years prior to that, shows me otherwise. > you try to provide everything and the kitchen sink, and end up with > design and implementation decisions that need to be re-evaluated from > time to time in the presence of new environments. Java and Python, or > anything including a "GUI" comes to mind. I'll offer X11 as a counterexample. >> And in this case, we're talking C and C++ runtimes, which should >> conform to the ISO standard anyway. > > Ah... should they conform to the Standard or should they be compatible to > older versions? To the standard. > What is supposed to happen if an existing version does > _not_ conform to the Standard? Since the standards attempt to codify existing practice, that rarely happens. The only case that comes to mind of an incompatible change in the C standard, between C90 (ISO 9899-1990) and C99, is the choice of return code semantics for snprintf when it was added to the standard. There were two implementations with different semantics; the committee chose the sensible one. The only significant broken implementations by that point were HP's and Microsoft's, and Microsoft's doesn't really count because 1) the canonical name of the function in the Microsoft libraries was _sprintf, an identifier reserved to the implementation, and 2) Microsoft wasn't inclined to follow the standard anyway. > Also: What am I supposed to do in case there is no obvious standard to > adhere to? I have e.g. a few hundred kLOC of pre-1998 C++ code (done > well before 1998...) around that's uncompilable with todays compilers. > Who is to blame here? Should g++ have sticked to 2.95's view of the > world? That's not a dynamic-runtime issue, which is what we were discussing. It's another problem entirely - the overly large and loose definition of the C++ language. >>> In particular that would mean not only source and binary but also >>> behavioural compatibility including keeping buggy behaviour. >> No it doesn't. Undefined behavior is undefined; an application that >> relies on it is broken. > > What is an application supposed to do when it lives in an environment > where only buggy libraries are available? Suck it up? Might as well ask what a car is supposed to do in an environment with no roads. That's not a design failure in the car, nor a mistake on the part of the car's engineers; and neither does it mean that cars are a bad idea. >> And for the rare
Re: lyx2lyx script broken (1.6.0 on Vista)
On Sun, Nov 23, 2008 at 10:26:30AM -0500, Michael Wojcik wrote: > Jean-Marc Lasgouttes wrote: > >> Completely infeasible on Windows. The loss of shared text would make > >> the working set of the typical application mix grossly exceed even the > >> absurd amounts of RAM available in typical machines today. The disk > >> space problem would be even worse. > > > > I meant just for application which feel that they have to distribute > > their own version-of-the-day > > of whatever.dll. There is no reason to do it everywhere of course. > > Still not feasible, unfortunately, because that includes everything > linked with any of the Microsoft C/C++ runtime DLLs. *cough* We were _not_ talking about statically linking _everything_. We were talking about things like Qt which are not a typical part of a Windows system. > This is the central problem: if you build an application that uses > anything in the MS C/C++ library (Microsoft combines the C and C++ > standard libraries into a single DLL), which means pretty much > anything built with a Microsoft C or C++ compiler, or with the > Microsoft Platform SDK, you'll link against some specific version of > one or more of the MSVC DLLs. You don't have much choice about which > version you get - it depends on what version of the compiler or SDK > you have installed, and what updates have been applied to it. > [...] [...] [...] You are fighting windmills. Andre'
Re: lyx2lyx script broken (1.6.0 on Vista)
On Sun, Nov 23, 2008 at 11:21:27AM -0500, Michael Wojcik wrote: > Andre Poenitz wrote: > > On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote: > >> Andre Poenitz wrote: > >>> On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: > >> I've worked on many projects that maintained backward compatibility > >> with new releases of the API, and seen a great many more. > > > > Just for my curiosity: Which projects, which scope? > > Hmm. Off the top of my head, in roughly chronological order: > > - Various IBM internal-only projects, such as the E editor. > > - Early versions of Windows. The Windows 1.x to Windows 2.0 and > Windows/286 transition maintained compatibility in the Windows API; > Windows 1.x applications ran unchanged in the 2.0 family. Windows 2.0 was released pretty exactly two years after 1.0, Windows 3.0 completely broke the API 2 1/2 years later. So, at best, that's a period of 4.5 years of "API stability". That's close to a joke, especially when taking into account that < 3.11 was not usable for any reasonable practical purpose... > - X11R3. The X11 API was layered correctly: as long as the server > follows the protocol spec, it doesn't matter what it does under the > covers. I added support for new hardware to the ddx layer; wrote new > window managers with completely different look-and-feel from the > standard ones; added extensions to X11 itself. None of that interfered > with existing clients one bit. X11R3: End of 88, X11R4: End of 89. In any case, this is a nice example for something that is "finished" at some point of time. Nobody changed 7 bit ASCII for a while for that matter. If a feature set is closed at some point of time it is easy to "outsource" the problems to "extensions" and "toolkits". Pretty much around 1990 supposedly the last person died that used plain X. [No, that was not me *cough*] SCNR ;-) > - The 4.3 BSD kernel. Extended multihead support in the console driver > and wrote some drivers for new hardware. Enhanced the shared memory > kernel option. Nothing that didn't want to use the new features needed > to be recompiled. Spring (?) 2001 - January 2002. I can't/won't comment on the others. > Maintaining backward compatibility simply is not that hard. We are _not_ talking about _two_ years here. I can maintain compatibility over two years by simply ignoring advancements in the outside world for that long and release "incompatible version x+1" after that. > > I am still pretty convinced that "compatibility" and "progress" are > > fairly incompatible notions when it comes to the development of _usable_ > > libraries. > > And I'll say that my experience as a professional software developer > for 20 years, and as a hobbyist for a number of years prior to that, > shows me otherwise. Fine. My experience so far shows that one has a choice between stagnation and breaking compatibility. And making that choice is neither obvious nor easy. > > you try to provide everything and the kitchen sink, and end up with > > design and implementation decisions that need to be re-evaluated from > > time to time in the presence of new environments. Java and Python, or > > anything including a "GUI" comes to mind. > > I'll offer X11 as a counterexample. X11 has certainly its merits and is time proven. Still it puts a lot of burden on the application developer, or, at the very least, on the toolkit developer. Lots of the initial design decisions that do not scale well into the 21st century are only bearable because of the "outsourcing" mentioned above. Plain X11 does _not_ come with kitchen sinks. > >> And in this case, we're talking C and C++ runtimes, which should > >> conform to the ISO standard anyway. > > > > Ah... should they conform to the Standard or should they be compatible to > > older versions? > > To the standard. That rules out fixing bugs, and it also breaks compatibility. I do not say that's a bad choice - in fact that's what I'd do in most cases - but it is incompatible with your statement that maintaining compatibility is possible _and easy_. > > What is supposed to happen if an existing version does > > _not_ conform to the Standard? > > Since the standards attempt to codify existing practice, that rarely > happens. Hear, hear. How come ISO 14882 codifies "export" for templates when not a single compiler was able to handle that in 1998 (and for a few years after that)? Apart from that the point is not how often it happens but that it happens at all. You just admit that it happens. > The only case that comes to mind of an incompatible change in > the C standard, between C90 (ISO 9899-1990) and C99, is the choice of > return code semantics for snprintf when it was added to the standard. > There were two implementations with different semantics; the committee > chose the sensible one. The only significant broken implementations by > that point were HP's and Microsoft's, and Microsoft's doesn't really > count because 1) the
Re: lyx2lyx script broken (1.6.0 on Vista)
On 23/11/2008 16:26, Michael Wojcik wrote: In older versions of the Microsoft toolchain, you could just drop the MSVC DLLs into the same directory as your executable. That's no longer allowed (I think as of Visual Studio 2005 and Platform SDK 6.0). Now they have to be installed into the SxS tree. FYI, unless I'm misunderstanding you, that's not really true, many open source (or not) programs distribute the C and C++ runtime along the executable and the manifest file. We do that for LyX for example. So the old method still stands. Abdel.
Re: lyx2lyx script broken (1.6.0 on Vista)
> > - The 4.3 BSD kernel. Extended multihead support in the console driver > > and wrote some drivers for new hardware. Enhanced the shared memory > > kernel option. Nothing that didn't want to use the new features needed > > to be recompiled. > > Spring (?) 2001 - January 2002. Sorry to jump into your thread. But the dates are many years off. 4.3BSD kernel was released by CSRG in 1986.
Re: lyx2lyx script broken (1.6.0 on Vista)
On Mon, Nov 17, 2008 at 09:58:50PM +0100, Jean-Marc Lasgouttes wrote: Andre Poenitz [EMAIL PROTECTED] writes: In fact that's actually the most sensible behaviour since there are only very few cases where a new version indeed can replace an older one without any existing or imagined problem. What's wrong with static linking? Not much. But it's not very different from per-application shared objects. In the 'main application' in my previous job most we actually linked most of the stuff statically - including Qt... At least it goes away when the application goes away. That's a benefit. Andre'
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: I wonder if disk manufacturers are paying M$ to do this? I've got about 54MB of crap in %windir%\winsxs, with multiple versions of each set of files. Presumably there's no way for Windoze to know that something depending on an older version can use the newer version, so old versions never go away. In fact that's actually the most sensible behaviour since there are only very few cases where a new version indeed can replace an older one without any existing or imagined problem. I respectfully disagree. I've worked on many projects that maintained backward compatibility with new releases of the API, and seen a great many more. And in this case, we're talking C and C++ runtimes, which should conform to the ISO standard anyway. There's no need for them to change every other week. In particular that would mean not only source and binary but also behavioural compatibility including keeping buggy behaviour. No it doesn't. Undefined behavior is undefined; an application that relies on it is broken. And for the rare application that does, there are other Windows mechanisms for tying it to the old version of the DLL. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Jean-Marc Lasgouttes wrote: What's wrong with static linking? At least it goes away when the application goes away. Completely infeasible on Windows. The loss of shared text would make the working set of the typical application mix grossly exceed even the absurd amounts of RAM available in typical machines today. The disk space problem would be even worse. Many people have done back-of-the-envelope calculations to demonstrate this; I think I did some myself, in a post to alt.folklore.computers some time back. It's a lousy idea in any case, as anyone who remembers compiling all of BSD 4.2 to switch from local-files resolution to DNS remembers. Dynamic linking lets you fix the bug or add the feature in one place. We can't have millions of Windows users downloading a refresh of the entire OS every time a bug is fixed in one of the prominent DLLs. Dynamic linking is a good thing. It's worked very well on a number of OSes. It would work on Windows if Microsoft could figure out 1) how to version properly, and 2) how to maintain backward compatibility. And it's not like those are unsolved problems. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote: Andre Poenitz wrote: On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: I wonder if disk manufacturers are paying M$ to do this? I've got about 54MB of crap in %windir%\winsxs, with multiple versions of each set of files. Presumably there's no way for Windoze to know that something depending on an older version can use the newer version, so old versions never go away. In fact that's actually the most sensible behaviour since there are only very few cases where a new version indeed can replace an older one without any existing or imagined problem. I respectfully disagree. No need to show some special respect here. I believe I can stand ordinary disagreement rather well. I've worked on many projects that maintained backward compatibility with new releases of the API, and seen a great many more. Just for my curiosity: Which projects, which scope? I am still pretty convinced that compatibility and progress are fairly incompatible notions when it comes to the development of _usable_ libraries. Guaranteeing the behaviour of only a very limited set of property gives you the opportunity of changing/improving implementations, but reduces the utility of the library as such. That's the approach taken by e.g. standardized languages like C++ _or_ you try to provide everything and the kitchen sink, and end up with design and implementation decisions that need to be re-evaluated from time to time in the presence of new environments. Java and Python, or anything including a GUI comes to mind. And in this case, we're talking C and C++ runtimes, which should conform to the ISO standard anyway. Ah... should they conform to the Standard or should they be compatible to older versions? What is supposed to happen if an existing version does _not_ conform to the Standard? There's no need for them to change every other week. No. But if problems show up. Non-conformance is a problem for instance. Also: What am I supposed to do in case there is no obvious standard to adhere to? I have e.g. a few hundred kLOC of pre-1998 C++ code (done well before 1998...) around that's uncompilable with todays compilers. Who is to blame here? Should g++ have sticked to 2.95's view of the world? In particular that would mean not only source and binary but also behavioural compatibility including keeping buggy behaviour. No it doesn't. Undefined behavior is undefined; an application that relies on it is broken. What is an application supposed to do when it lives in an environment where only buggy libraries are available? And for the rare application that does, there are other Windows mechanisms for tying it to the old version of the DLL. I obviously dispute rare, otherwise Wikipedia would not know about DLL hell, and I have to admit that I am not aware of a lot of other Windows mechanisms that scale from, say, Win 3.11^H95 through Vista. What exactly are you refering to? Andre'
Re: lyx2lyx script broken (1.6.0 on Vista)
On Tue, Nov 18, 2008 at 03:47:45PM -0500, Michael Wojcik wrote: Jean-Marc Lasgouttes wrote: What's wrong with static linking? At least it goes away when the application goes away. Completely infeasible on Windows. The loss of shared text would make the working set of the typical application mix grossly exceed even the absurd amounts of RAM available in typical machines today. The disk space problem would be even worse. Many people have done back-of-the-envelope calculations to demonstrate this; I think I did some myself, in a post to alt.folklore.computers some time back. I only trust statistics I rigged myself. Some time back I was disputing the sheer possibility to catch a virus using email. Still ... environments ... came up that made _not catching one_ an art... So things done a while back do not count in IT. Mac OS X pretty much shows that _not_ sharing shared libraries on an application level is a feasible approach to DLL hell. It's a lousy idea in any case, as anyone who remembers compiling all of BSD 4.2 to switch from local-files resolution to DNS remembers. Dynamic linking lets you fix the bug or add the feature in one place. So why go from libstdc++.so.5 to libstdc++.so.6 at all, if incompatible changes can be, as you seem to say, avoided? We can't have millions of Windows users downloading a refresh of the entire OS every time a bug is fixed in one of the prominent DLLs. Dynamic linking is a good thing. It's worked very well on a number of OSes. Examples? It would work on Windows if Microsoft could figure out 1) how to version properly, and 2) how to maintain backward compatibility. And it's not like those are unsolved problems. I am happy to have learned now that these problems are solved. Now the only thing I miss is a Star Gate taking me to that parallel universe. Andre' PS: And don't get me wrong: I am painfully aware of what insufficient hardware means nowadays, and to my best knowledge I am usually not trying to defend any decision by MS... PPS: I cut a few smileys from the mail to avoid the embarassing ranking in the 1.7 smiley-per-mail statistics.
Re: lyx2lyx script broken (1.6.0 on Vista)
PPS: I cut a few smileys from the mail to avoid the embarassing ranking in the 1.7 smiley-per-mail statistics. Chicken! Does not even dare to be rude anymore. JMarc
Re: lyx2lyx script broken (1.6.0 on Vista)
Completely infeasible on Windows. The loss of shared text would make the working set of the typical application mix grossly exceed even the absurd amounts of RAM available in typical machines today. The disk space problem would be even worse. I meant just for application which feel that they have to distribute their own version-of-the-day of whatever.dll. There is no reason to do it everywhere of course. JMarc
Re: lyx2lyx script broken (1.6.0 on Vista)
PPS: I cut a few smileys from the mail to avoid the embarassing ranking in the 1.7 smiley-per-mail statistics. feel free to uncover yourself, users list is not evaluated... pavel
Re: lyx2lyx script broken (1.6.0 on Vista)
On Tue, Nov 18, 2008 at 11:43:34PM +0100, Pavel Sanda wrote: PPS: I cut a few smileys from the mail to avoid the embarassing ranking in the 1.7 smiley-per-mail statistics. feel free to uncover yourself, users list is not evaluated... Nobody expected the Spanish Inquisition... Andre'
Re: lyx2lyx script broken (1.6.0 on Vista)
On Tue, Nov 18, 2008 at 11:43:34PM +0100, Pavel Sanda wrote: PPS: I cut a few smileys from the mail to avoid the embarassing ranking in the 1.7 smiley-per-mail statistics. feel free to uncover yourself, users list is not evaluated... Nobody expected the Spanish Inquisition... of course the next ranking wont be based on emoticons but on the ratio between vowels and consonants. pavel
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: PPS: I cut a few smileys from the mail to avoid the embarassing ranking in the 1.7 smiley-per-mail statistics. Best to start now, eh? rh
Re: lyx2lyx script broken (1.6.0 on Vista)
On Mon, Nov 17, 2008 at 09:58:50PM +0100, Jean-Marc Lasgouttes wrote: Andre Poenitz [EMAIL PROTECTED] writes: In fact that's actually the most sensible behaviour since there are only very few cases where a new version indeed can replace an older one without any existing or imagined problem. What's wrong with static linking? Not much. But it's not very different from per-application shared objects. In the 'main application' in my previous job most we actually linked most of the stuff statically - including Qt... At least it goes away when the application goes away. That's a benefit. Andre'
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: I wonder if disk manufacturers are paying M$ to do this? I've got about 54MB of crap in %windir%\winsxs, with multiple versions of each set of files. Presumably there's no way for Windoze to know that something depending on an older version can use the newer version, so old versions never go away. In fact that's actually the most sensible behaviour since there are only very few cases where a new version indeed can replace an older one without any existing or imagined problem. I respectfully disagree. I've worked on many projects that maintained backward compatibility with new releases of the API, and seen a great many more. And in this case, we're talking C and C++ runtimes, which should conform to the ISO standard anyway. There's no need for them to change every other week. In particular that would mean not only source and binary but also behavioural compatibility including keeping buggy behaviour. No it doesn't. Undefined behavior is undefined; an application that relies on it is broken. And for the rare application that does, there are other Windows mechanisms for tying it to the old version of the DLL. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Jean-Marc Lasgouttes wrote: What's wrong with static linking? At least it goes away when the application goes away. Completely infeasible on Windows. The loss of shared text would make the working set of the typical application mix grossly exceed even the absurd amounts of RAM available in typical machines today. The disk space problem would be even worse. Many people have done back-of-the-envelope calculations to demonstrate this; I think I did some myself, in a post to alt.folklore.computers some time back. It's a lousy idea in any case, as anyone who remembers compiling all of BSD 4.2 to switch from local-files resolution to DNS remembers. Dynamic linking lets you fix the bug or add the feature in one place. We can't have millions of Windows users downloading a refresh of the entire OS every time a bug is fixed in one of the prominent DLLs. Dynamic linking is a good thing. It's worked very well on a number of OSes. It would work on Windows if Microsoft could figure out 1) how to version properly, and 2) how to maintain backward compatibility. And it's not like those are unsolved problems. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote: Andre Poenitz wrote: On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: I wonder if disk manufacturers are paying M$ to do this? I've got about 54MB of crap in %windir%\winsxs, with multiple versions of each set of files. Presumably there's no way for Windoze to know that something depending on an older version can use the newer version, so old versions never go away. In fact that's actually the most sensible behaviour since there are only very few cases where a new version indeed can replace an older one without any existing or imagined problem. I respectfully disagree. No need to show some special respect here. I believe I can stand ordinary disagreement rather well. I've worked on many projects that maintained backward compatibility with new releases of the API, and seen a great many more. Just for my curiosity: Which projects, which scope? I am still pretty convinced that compatibility and progress are fairly incompatible notions when it comes to the development of _usable_ libraries. Guaranteeing the behaviour of only a very limited set of property gives you the opportunity of changing/improving implementations, but reduces the utility of the library as such. That's the approach taken by e.g. standardized languages like C++ _or_ you try to provide everything and the kitchen sink, and end up with design and implementation decisions that need to be re-evaluated from time to time in the presence of new environments. Java and Python, or anything including a GUI comes to mind. And in this case, we're talking C and C++ runtimes, which should conform to the ISO standard anyway. Ah... should they conform to the Standard or should they be compatible to older versions? What is supposed to happen if an existing version does _not_ conform to the Standard? There's no need for them to change every other week. No. But if problems show up. Non-conformance is a problem for instance. Also: What am I supposed to do in case there is no obvious standard to adhere to? I have e.g. a few hundred kLOC of pre-1998 C++ code (done well before 1998...) around that's uncompilable with todays compilers. Who is to blame here? Should g++ have sticked to 2.95's view of the world? In particular that would mean not only source and binary but also behavioural compatibility including keeping buggy behaviour. No it doesn't. Undefined behavior is undefined; an application that relies on it is broken. What is an application supposed to do when it lives in an environment where only buggy libraries are available? And for the rare application that does, there are other Windows mechanisms for tying it to the old version of the DLL. I obviously dispute rare, otherwise Wikipedia would not know about DLL hell, and I have to admit that I am not aware of a lot of other Windows mechanisms that scale from, say, Win 3.11^H95 through Vista. What exactly are you refering to? Andre'
Re: lyx2lyx script broken (1.6.0 on Vista)
On Tue, Nov 18, 2008 at 03:47:45PM -0500, Michael Wojcik wrote: Jean-Marc Lasgouttes wrote: What's wrong with static linking? At least it goes away when the application goes away. Completely infeasible on Windows. The loss of shared text would make the working set of the typical application mix grossly exceed even the absurd amounts of RAM available in typical machines today. The disk space problem would be even worse. Many people have done back-of-the-envelope calculations to demonstrate this; I think I did some myself, in a post to alt.folklore.computers some time back. I only trust statistics I rigged myself. Some time back I was disputing the sheer possibility to catch a virus using email. Still ... environments ... came up that made _not catching one_ an art... So things done a while back do not count in IT. Mac OS X pretty much shows that _not_ sharing shared libraries on an application level is a feasible approach to DLL hell. It's a lousy idea in any case, as anyone who remembers compiling all of BSD 4.2 to switch from local-files resolution to DNS remembers. Dynamic linking lets you fix the bug or add the feature in one place. So why go from libstdc++.so.5 to libstdc++.so.6 at all, if incompatible changes can be, as you seem to say, avoided? We can't have millions of Windows users downloading a refresh of the entire OS every time a bug is fixed in one of the prominent DLLs. Dynamic linking is a good thing. It's worked very well on a number of OSes. Examples? It would work on Windows if Microsoft could figure out 1) how to version properly, and 2) how to maintain backward compatibility. And it's not like those are unsolved problems. I am happy to have learned now that these problems are solved. Now the only thing I miss is a Star Gate taking me to that parallel universe. Andre' PS: And don't get me wrong: I am painfully aware of what insufficient hardware means nowadays, and to my best knowledge I am usually not trying to defend any decision by MS... PPS: I cut a few smileys from the mail to avoid the embarassing ranking in the 1.7 smiley-per-mail statistics.
Re: lyx2lyx script broken (1.6.0 on Vista)
PPS: I cut a few smileys from the mail to avoid the embarassing ranking in the 1.7 smiley-per-mail statistics. Chicken! Does not even dare to be rude anymore. JMarc
Re: lyx2lyx script broken (1.6.0 on Vista)
Completely infeasible on Windows. The loss of shared text would make the working set of the typical application mix grossly exceed even the absurd amounts of RAM available in typical machines today. The disk space problem would be even worse. I meant just for application which feel that they have to distribute their own version-of-the-day of whatever.dll. There is no reason to do it everywhere of course. JMarc
Re: lyx2lyx script broken (1.6.0 on Vista)
PPS: I cut a few smileys from the mail to avoid the embarassing ranking in the 1.7 smiley-per-mail statistics. feel free to uncover yourself, users list is not evaluated... pavel
Re: lyx2lyx script broken (1.6.0 on Vista)
On Tue, Nov 18, 2008 at 11:43:34PM +0100, Pavel Sanda wrote: PPS: I cut a few smileys from the mail to avoid the embarassing ranking in the 1.7 smiley-per-mail statistics. feel free to uncover yourself, users list is not evaluated... Nobody expected the Spanish Inquisition... Andre'
Re: lyx2lyx script broken (1.6.0 on Vista)
On Tue, Nov 18, 2008 at 11:43:34PM +0100, Pavel Sanda wrote: PPS: I cut a few smileys from the mail to avoid the embarassing ranking in the 1.7 smiley-per-mail statistics. feel free to uncover yourself, users list is not evaluated... Nobody expected the Spanish Inquisition... of course the next ranking wont be based on emoticons but on the ratio between vowels and consonants. pavel
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: PPS: I cut a few smileys from the mail to avoid the embarassing ranking in the 1.7 smiley-per-mail statistics. Best to start now, eh? rh
Re: lyx2lyx script broken (1.6.0 on Vista)
On Mon, Nov 17, 2008 at 09:58:50PM +0100, Jean-Marc Lasgouttes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > In fact that's actually the most sensible behaviour since there are only > > very few cases where a new version indeed can replace an older one > > without any existing or imagined problem. > > What's wrong with static linking? Not much. But it's not very different from per-application shared objects. In the 'main application' in my previous job most we actually linked most of the stuff statically - including Qt... > At least it goes away when the application goes away. That's a benefit. Andre'
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: > On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: >> I wonder if disk manufacturers are paying M$ to do this? I've got about >> 54MB of crap in %windir%\winsxs, with multiple versions of each set of >> files. Presumably there's no way for Windoze to know that something >> depending on an older version can use the newer version, so old versions >> never go away. > > In fact that's actually the most sensible behaviour since there are only > very few cases where a new version indeed can replace an older one > without any existing or imagined problem. I respectfully disagree. I've worked on many projects that maintained backward compatibility with new releases of the API, and seen a great many more. And in this case, we're talking C and C++ runtimes, which should conform to the ISO standard anyway. There's no need for them to change every other week. > In particular that would mean > not only source and binary but also behavioural compatibility including > keeping buggy behaviour. No it doesn't. Undefined behavior is undefined; an application that relies on it is broken. And for the rare application that does, there are other Windows mechanisms for tying it to the old version of the DLL. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Jean-Marc Lasgouttes wrote: > > What's wrong with static linking? At least it goes away when the > application goes away. Completely infeasible on Windows. The loss of shared text would make the working set of the typical application mix grossly exceed even the absurd amounts of RAM available in typical machines today. The disk space problem would be even worse. Many people have done back-of-the-envelope calculations to demonstrate this; I think I did some myself, in a post to alt.folklore.computers some time back. It's a lousy idea in any case, as anyone who remembers compiling all of BSD 4.2 to switch from local-files resolution to DNS remembers. Dynamic linking lets you fix the bug or add the feature in one place. We can't have millions of Windows users downloading a refresh of the entire OS every time a bug is fixed in one of the prominent DLLs. Dynamic linking is a good thing. It's worked very well on a number of OSes. It would work on Windows if Microsoft could figure out 1) how to version properly, and 2) how to maintain backward compatibility. And it's not like those are unsolved problems. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote: > Andre Poenitz wrote: > > On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: > >> I wonder if disk manufacturers are paying M$ to do this? I've got about > >> 54MB of crap in %windir%\winsxs, with multiple versions of each set of > >> files. Presumably there's no way for Windoze to know that something > >> depending on an older version can use the newer version, so old versions > >> never go away. > > > > In fact that's actually the most sensible behaviour since there are only > > very few cases where a new version indeed can replace an older one > > without any existing or imagined problem. > > I respectfully disagree. No need to show some special respect here. I believe I can stand ordinary disagreement rather well. > I've worked on many projects that maintained backward compatibility > with new releases of the API, and seen a great many more. Just for my curiosity: Which projects, which scope? I am still pretty convinced that "compatibility" and "progress" are fairly incompatible notions when it comes to the development of _usable_ libraries. Guaranteeing the behaviour of only a very limited set of property gives you the opportunity of changing/improving implementations, but reduces the utility of the library as such. That's the approach taken by e.g. standardized languages like C++ _or_ you try to provide everything and the kitchen sink, and end up with design and implementation decisions that need to be re-evaluated from time to time in the presence of new environments. Java and Python, or anything including a "GUI" comes to mind. > And in this case, we're talking C and C++ runtimes, which should > conform to the ISO standard anyway. Ah... should they conform to the Standard or should they be compatible to older versions? What is supposed to happen if an existing version does _not_ conform to the Standard? > There's no need for them to change every other week. No. But if problems show up. Non-conformance is a problem for instance. Also: What am I supposed to do in case there is no obvious standard to adhere to? I have e.g. a few hundred kLOC of pre-1998 C++ code (done well before 1998...) around that's uncompilable with todays compilers. Who is to blame here? Should g++ have sticked to 2.95's view of the world? > > In particular that would mean not only source and binary but also > > behavioural compatibility including keeping buggy behaviour. > > No it doesn't. Undefined behavior is undefined; an application that > relies on it is broken. What is an application supposed to do when it lives in an environment where only buggy libraries are available? > And for the rare application that does, there are other Windows > mechanisms for tying it to the old version of the DLL. I obviously dispute "rare", otherwise Wikipedia would not know about "DLL hell", and I have to admit that I am not aware of a lot of "other Windows mechanisms" that scale from, say, Win 3.11^H95 through Vista. What exactly are you refering to? Andre'
Re: lyx2lyx script broken (1.6.0 on Vista)
On Tue, Nov 18, 2008 at 03:47:45PM -0500, Michael Wojcik wrote: > Jean-Marc Lasgouttes wrote: > > > > What's wrong with static linking? At least it goes away when the > > application goes away. > > Completely infeasible on Windows. The loss of shared text would make > the working set of the typical application mix grossly exceed even the > absurd amounts of RAM available in typical machines today. The disk > space problem would be even worse. Many people have done > back-of-the-envelope calculations to demonstrate this; I think I did > some myself, in a post to alt.folklore.computers some time back. I only trust statistics I rigged myself. Some time back I was disputing the sheer possibility to catch a virus using email. Still ... "environments" ... came up that made _not catching one_ an art... So "things done a while back" do not count in IT. Mac OS X pretty much shows that _not_ sharing shared libraries on an application level is a feasible approach to DLL hell. > It's a lousy idea in any case, as anyone who remembers compiling all > of BSD 4.2 to switch from local-files resolution to DNS remembers. > Dynamic linking lets you fix the bug or add the feature in one place. So why go from libstdc++.so.5 to libstdc++.so.6 at all, if incompatible changes can be, as you seem to say, avoided? > We can't have millions of Windows users downloading a refresh of the > entire OS every time a bug is fixed in one of the prominent DLLs. > > Dynamic linking is a good thing. It's worked very well on a number of > OSes. Examples? > It would work on Windows if Microsoft could figure out 1) how to > version properly, and 2) how to maintain backward compatibility. And > it's not like those are unsolved problems. I am happy to have learned now that these problems are solved. Now the only thing I miss is a Star Gate taking me to that parallel universe. Andre' PS: And don't get me wrong: I am painfully aware of what "insufficient" hardware means nowadays, and to my best knowledge I am usually not trying to defend any decision by MS... PPS: I cut a few smileys from the mail to avoid the embarassing ranking in the 1.7 smiley-per-mail statistics.
Re: lyx2lyx script broken (1.6.0 on Vista)
PPS: I cut a few smileys from the mail to avoid the embarassing ranking in the 1.7 smiley-per-mail statistics. Chicken! Does not even dare to be rude anymore. JMarc
Re: lyx2lyx script broken (1.6.0 on Vista)
Completely infeasible on Windows. The loss of shared text would make the working set of the typical application mix grossly exceed even the absurd amounts of RAM available in typical machines today. The disk space problem would be even worse. I meant just for application which feel that they have to distribute their own version-of-the-day of whatever.dll. There is no reason to do it everywhere of course. JMarc
Re: lyx2lyx script broken (1.6.0 on Vista)
> PPS: I cut a few smileys from the mail to avoid the embarassing ranking > in the 1.7 smiley-per-mail statistics. feel free to uncover yourself, users list is not evaluated... pavel
Re: lyx2lyx script broken (1.6.0 on Vista)
On Tue, Nov 18, 2008 at 11:43:34PM +0100, Pavel Sanda wrote: > > PPS: I cut a few smileys from the mail to avoid the embarassing ranking > > in the 1.7 smiley-per-mail statistics. > > feel free to uncover yourself, users list is not evaluated... Nobody expected the Spanish Inquisition... Andre'
Re: lyx2lyx script broken (1.6.0 on Vista)
> On Tue, Nov 18, 2008 at 11:43:34PM +0100, Pavel Sanda wrote: > > > PPS: I cut a few smileys from the mail to avoid the embarassing ranking > > > in the 1.7 smiley-per-mail statistics. > > > > feel free to uncover yourself, users list is not evaluated... > > Nobody expected the Spanish Inquisition... of course the next ranking wont be based on emoticons but on the ratio between vowels and consonants. pavel
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: PPS: I cut a few smileys from the mail to avoid the embarassing ranking in the 1.7 smiley-per-mail statistics. Best to start now, eh? rh
Re: lyx2lyx script broken (1.6.0 on Vista)
Uwe Stöhr wrote: Dominik Waßenhoven schrieb: On the Vista machine, I had no Python installed and the lyx2lyx script failed. I now installed Microsoft's VC++ redistributable package, as suggested by Paul Rubin, and now the lyx2lyx script works. So I think there is a problem with the python.exe and/or python26.dll which are in the bin directory of LyX 1.6. But I also had no Python installed on this Vista machine, only installed LyX using my installer and it worked. I also got feedback that it works for others too. It appears the bundled Python requires a particular release of Microsoft's C runtime. There are approximately a zillion releases of the MSVC runtime, all mutually incompatible. For years, Microsoft handled this by changing the name of the MSVC runtime DLLs with each release. More recently, when someone decided it'd be good to have more incompatible runtime versions than would fit in a single MSVC release cycle, they invented the Side by Side versioning method, which has the advantages of being a black box, completely different from previous Windows DLL versioning mechanisms, and entirely mysterious, opaque, and frustrating for users. Side-by-Side sticks various releases of the MSVC runtime in directories under %windir%\winsxs. Product installers are supposed to include the MSVC redistributable package for the particular MSVC version they need, which will get installed in Side-by-Side if it's not already present. Probably, people who don't have problems with the minimal Python included with Uwe's installer already have the necessary MSVC redistributable on their machine from some other product installation. The fix would be to include the appropriate MSVC redistributable in Uwe's LyX installer. Note that it may have to be updated any time the Python binaries are updated, since they might be linked with a different MSVC version. Sure makes SVR4 shared object versioning look good, doesn't it? -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Michael Wojcik wrote: Uwe Stöhr wrote: Dominik Waßenhoven schrieb: On the Vista machine, I had no Python installed and the lyx2lyx script failed. I now installed Microsoft's VC++ redistributable package, as suggested by Paul Rubin, and now the lyx2lyx script works. So I think there is a problem with the python.exe and/or python26.dll which are in the bin directory of LyX 1.6. But I also had no Python installed on this Vista machine, only installed LyX using my installer and it worked. I also got feedback that it works for others too. It appears the bundled Python requires a particular release of Microsoft's C runtime. There are approximately a zillion releases of the MSVC runtime, all mutually incompatible. For years, Microsoft handled this by changing the name of the MSVC runtime DLLs with each release. More recently, when someone decided it'd be good to have more incompatible runtime versions than would fit in a single MSVC release cycle, they invented the Side by Side versioning method, which has the advantages of being a black box, completely different from previous Windows DLL versioning mechanisms, and entirely mysterious, opaque, and frustrating for users. Side-by-Side sticks various releases of the MSVC runtime in directories under %windir%\winsxs. Product installers are supposed to include the MSVC redistributable package for the particular MSVC version they need, which will get installed in Side-by-Side if it's not already present. Probably, people who don't have problems with the minimal Python included with Uwe's installer already have the necessary MSVC redistributable on their machine from some other product installation. The fix would be to include the appropriate MSVC redistributable in Uwe's LyX installer. Note that it may have to be updated any time the Python binaries are updated, since they might be linked with a different MSVC version. Sure makes SVR4 shared object versioning look good, doesn't it? I wonder if disk manufacturers are paying M$ to do this? I've got about 54MB of crap in %windir%\winsxs, with multiple versions of each set of files. Presumably there's no way for Windoze to know that something depending on an older version can use the newer version, so old versions never go away. Kind of like that half gigabyte (and counting) of patch files that never gets deleted.
Re: lyx2lyx script broken (1.6.0 on Vista)
On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: I wonder if disk manufacturers are paying M$ to do this? I've got about 54MB of crap in %windir%\winsxs, with multiple versions of each set of files. Presumably there's no way for Windoze to know that something depending on an older version can use the newer version, so old versions never go away. In fact that's actually the most sensible behaviour since there are only very few cases where a new version indeed can replace an older one without any existing or imagined problem. In particular that would mean not only source and binary but also behavioural compatibility including keeping buggy behaviour. When you factor in that application also can depend on runtime characteristics even optimizations might have to be ruled out, so there's really not much left what could be done in a newer version... Andre'
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz [EMAIL PROTECTED] writes: In fact that's actually the most sensible behaviour since there are only very few cases where a new version indeed can replace an older one without any existing or imagined problem. What's wrong with static linking? At least it goes away when the application goes away. JMarc
Re: lyx2lyx script broken (1.6.0 on Vista)
Uwe Stöhr wrote: Dominik Waßenhoven schrieb: On the Vista machine, I had no Python installed and the lyx2lyx script failed. I now installed Microsoft's VC++ redistributable package, as suggested by Paul Rubin, and now the lyx2lyx script works. So I think there is a problem with the python.exe and/or python26.dll which are in the bin directory of LyX 1.6. But I also had no Python installed on this Vista machine, only installed LyX using my installer and it worked. I also got feedback that it works for others too. It appears the bundled Python requires a particular release of Microsoft's C runtime. There are approximately a zillion releases of the MSVC runtime, all mutually incompatible. For years, Microsoft handled this by changing the name of the MSVC runtime DLLs with each release. More recently, when someone decided it'd be good to have more incompatible runtime versions than would fit in a single MSVC release cycle, they invented the Side by Side versioning method, which has the advantages of being a black box, completely different from previous Windows DLL versioning mechanisms, and entirely mysterious, opaque, and frustrating for users. Side-by-Side sticks various releases of the MSVC runtime in directories under %windir%\winsxs. Product installers are supposed to include the MSVC redistributable package for the particular MSVC version they need, which will get installed in Side-by-Side if it's not already present. Probably, people who don't have problems with the minimal Python included with Uwe's installer already have the necessary MSVC redistributable on their machine from some other product installation. The fix would be to include the appropriate MSVC redistributable in Uwe's LyX installer. Note that it may have to be updated any time the Python binaries are updated, since they might be linked with a different MSVC version. Sure makes SVR4 shared object versioning look good, doesn't it? -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Michael Wojcik wrote: Uwe Stöhr wrote: Dominik Waßenhoven schrieb: On the Vista machine, I had no Python installed and the lyx2lyx script failed. I now installed Microsoft's VC++ redistributable package, as suggested by Paul Rubin, and now the lyx2lyx script works. So I think there is a problem with the python.exe and/or python26.dll which are in the bin directory of LyX 1.6. But I also had no Python installed on this Vista machine, only installed LyX using my installer and it worked. I also got feedback that it works for others too. It appears the bundled Python requires a particular release of Microsoft's C runtime. There are approximately a zillion releases of the MSVC runtime, all mutually incompatible. For years, Microsoft handled this by changing the name of the MSVC runtime DLLs with each release. More recently, when someone decided it'd be good to have more incompatible runtime versions than would fit in a single MSVC release cycle, they invented the Side by Side versioning method, which has the advantages of being a black box, completely different from previous Windows DLL versioning mechanisms, and entirely mysterious, opaque, and frustrating for users. Side-by-Side sticks various releases of the MSVC runtime in directories under %windir%\winsxs. Product installers are supposed to include the MSVC redistributable package for the particular MSVC version they need, which will get installed in Side-by-Side if it's not already present. Probably, people who don't have problems with the minimal Python included with Uwe's installer already have the necessary MSVC redistributable on their machine from some other product installation. The fix would be to include the appropriate MSVC redistributable in Uwe's LyX installer. Note that it may have to be updated any time the Python binaries are updated, since they might be linked with a different MSVC version. Sure makes SVR4 shared object versioning look good, doesn't it? I wonder if disk manufacturers are paying M$ to do this? I've got about 54MB of crap in %windir%\winsxs, with multiple versions of each set of files. Presumably there's no way for Windoze to know that something depending on an older version can use the newer version, so old versions never go away. Kind of like that half gigabyte (and counting) of patch files that never gets deleted.
Re: lyx2lyx script broken (1.6.0 on Vista)
On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: I wonder if disk manufacturers are paying M$ to do this? I've got about 54MB of crap in %windir%\winsxs, with multiple versions of each set of files. Presumably there's no way for Windoze to know that something depending on an older version can use the newer version, so old versions never go away. In fact that's actually the most sensible behaviour since there are only very few cases where a new version indeed can replace an older one without any existing or imagined problem. In particular that would mean not only source and binary but also behavioural compatibility including keeping buggy behaviour. When you factor in that application also can depend on runtime characteristics even optimizations might have to be ruled out, so there's really not much left what could be done in a newer version... Andre'
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz [EMAIL PROTECTED] writes: In fact that's actually the most sensible behaviour since there are only very few cases where a new version indeed can replace an older one without any existing or imagined problem. What's wrong with static linking? At least it goes away when the application goes away. JMarc
Re: lyx2lyx script broken (1.6.0 on Vista)
Uwe Stöhr wrote: > Dominik Waßenhoven schrieb: > >> On the Vista machine, I had no Python installed and the lyx2lyx script >> failed. I now installed Microsoft's VC++ redistributable package, as >> suggested by Paul Rubin, and now the lyx2lyx script works. So I think >> there is a problem with the python.exe and/or python26.dll which are in >> the bin directory of LyX 1.6. > > But I also had no Python installed on this Vista machine, only installed > LyX using my installer and it worked. I also got feedback that it works > for others too. It appears the bundled Python requires a particular release of Microsoft's C runtime. There are approximately a zillion releases of the MSVC runtime, all mutually incompatible. For years, Microsoft handled this by changing the name of the MSVC runtime DLLs with each release. More recently, when someone decided it'd be good to have more incompatible runtime versions than would fit in a single MSVC release cycle, they invented the "Side by Side" versioning method, which has the advantages of being a black box, completely different from previous Windows DLL versioning mechanisms, and entirely mysterious, opaque, and frustrating for users. Side-by-Side sticks various releases of the MSVC runtime in directories under %windir%\winsxs. Product installers are supposed to include the MSVC redistributable package for the particular MSVC version they need, which will get installed in Side-by-Side if it's not already present. Probably, people who don't have problems with the minimal Python included with Uwe's installer already have the necessary MSVC redistributable on their machine from some other product installation. The fix would be to include the appropriate MSVC redistributable in Uwe's LyX installer. Note that it may have to be updated any time the Python binaries are updated, since they might be linked with a different MSVC version. Sure makes SVR4 shared object versioning look good, doesn't it? -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Michael Wojcik wrote: Uwe Stöhr wrote: Dominik Waßenhoven schrieb: On the Vista machine, I had no Python installed and the lyx2lyx script failed. I now installed Microsoft's VC++ redistributable package, as suggested by Paul Rubin, and now the lyx2lyx script works. So I think there is a problem with the python.exe and/or python26.dll which are in the bin directory of LyX 1.6. But I also had no Python installed on this Vista machine, only installed LyX using my installer and it worked. I also got feedback that it works for others too. It appears the bundled Python requires a particular release of Microsoft's C runtime. There are approximately a zillion releases of the MSVC runtime, all mutually incompatible. For years, Microsoft handled this by changing the name of the MSVC runtime DLLs with each release. More recently, when someone decided it'd be good to have more incompatible runtime versions than would fit in a single MSVC release cycle, they invented the "Side by Side" versioning method, which has the advantages of being a black box, completely different from previous Windows DLL versioning mechanisms, and entirely mysterious, opaque, and frustrating for users. Side-by-Side sticks various releases of the MSVC runtime in directories under %windir%\winsxs. Product installers are supposed to include the MSVC redistributable package for the particular MSVC version they need, which will get installed in Side-by-Side if it's not already present. Probably, people who don't have problems with the minimal Python included with Uwe's installer already have the necessary MSVC redistributable on their machine from some other product installation. The fix would be to include the appropriate MSVC redistributable in Uwe's LyX installer. Note that it may have to be updated any time the Python binaries are updated, since they might be linked with a different MSVC version. Sure makes SVR4 shared object versioning look good, doesn't it? I wonder if disk manufacturers are paying M$ to do this? I've got about 54MB of crap in %windir%\winsxs, with multiple versions of each set of files. Presumably there's no way for Windoze to know that something depending on an older version can use the newer version, so old versions never go away. Kind of like that half gigabyte (and counting) of patch files that never gets deleted.
Re: lyx2lyx script broken (1.6.0 on Vista)
On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: > I wonder if disk manufacturers are paying M$ to do this? I've got about > 54MB of crap in %windir%\winsxs, with multiple versions of each set of > files. Presumably there's no way for Windoze to know that something > depending on an older version can use the newer version, so old versions > never go away. In fact that's actually the most sensible behaviour since there are only very few cases where a new version indeed can replace an older one without any existing or imagined problem. In particular that would mean not only source and binary but also behavioural compatibility including keeping buggy behaviour. When you factor in that application also can depend on runtime characteristics even optimizations might have to be ruled out, so there's really not much left what could be done in a newer version... Andre'
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz <[EMAIL PROTECTED]> writes: > In fact that's actually the most sensible behaviour since there are only > very few cases where a new version indeed can replace an older one > without any existing or imagined problem. What's wrong with static linking? At least it goes away when the application goes away. JMarc
Re: lyx2lyx script broken (1.6.0 on Vista)
Uwe Stöhr wrote: Dominik Waßenhoven schrieb: In the bin directory is a python26.dll file. Oh -- I just saw that I have a full Python installed on the WinXP machine (I didn't realize that, sorry...). It's Python 2.5.1 This means that you have Python 2.5.1 installed but the installer didn't recognize it. No, I think I was not clear enough. The second sentenc you cited above bear on my insallation on a WinXP system, where your installer worked perfectly. On the Vista machine, I had no Python installed and the lyx2lyx script failed. I now installed Microsoft's VC++ redistributable package, as suggested by Paul Rubin, and now the lyx2lyx script works. So I think there is a problem with the python.exe and/or python26.dll which are in the bin directory of LyX 1.6. I'm currently also on a Vista machine but cannot reproduce the problem. I installed here also Python 2.5.1 and then LyX using my installer. LyX correctly recognized Python 2.5.1 and therefore not installed Python 2.6. As I said, the scenario was different for me, as I had /no/ Python installed. Thanks for your effort, Dominik.-
Re: lyx2lyx script broken (1.6.0 on Vista)
Paul A. Rubin wrote: Dominik Waßenhoven wrote: Should I try to install Python on Vista and try to convert from LyX 1.5 to 1.6 again? That would likely work. Alternatively, you might install the M$ VC++ redistributable package (http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BFdisplaylang=de) and see if that does the trick. Indeed, it does! Thanks a lot. Regards, Dominik.-
Re: lyx2lyx script broken (1.6.0 on Vista)
Dominik Waßenhoven schrieb: On the Vista machine, I had no Python installed and the lyx2lyx script failed. I now installed Microsoft's VC++ redistributable package, as suggested by Paul Rubin, and now the lyx2lyx script works. So I think there is a problem with the python.exe and/or python26.dll which are in the bin directory of LyX 1.6. But I also had no Python installed on this Vista machine, only installed LyX using my installer and it worked. I also got feedback that it works for others too. regards Uwe
Re: lyx2lyx script broken (1.6.0 on Vista)
Uwe Stöhr wrote: Dominik Waßenhoven schrieb: In the bin directory is a python26.dll file. Oh -- I just saw that I have a full Python installed on the WinXP machine (I didn't realize that, sorry...). It's Python 2.5.1 This means that you have Python 2.5.1 installed but the installer didn't recognize it. No, I think I was not clear enough. The second sentenc you cited above bear on my insallation on a WinXP system, where your installer worked perfectly. On the Vista machine, I had no Python installed and the lyx2lyx script failed. I now installed Microsoft's VC++ redistributable package, as suggested by Paul Rubin, and now the lyx2lyx script works. So I think there is a problem with the python.exe and/or python26.dll which are in the bin directory of LyX 1.6. I'm currently also on a Vista machine but cannot reproduce the problem. I installed here also Python 2.5.1 and then LyX using my installer. LyX correctly recognized Python 2.5.1 and therefore not installed Python 2.6. As I said, the scenario was different for me, as I had /no/ Python installed. Thanks for your effort, Dominik.-
Re: lyx2lyx script broken (1.6.0 on Vista)
Paul A. Rubin wrote: Dominik Waßenhoven wrote: Should I try to install Python on Vista and try to convert from LyX 1.5 to 1.6 again? That would likely work. Alternatively, you might install the M$ VC++ redistributable package (http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BFdisplaylang=de) and see if that does the trick. Indeed, it does! Thanks a lot. Regards, Dominik.-
Re: lyx2lyx script broken (1.6.0 on Vista)
Dominik Waßenhoven schrieb: On the Vista machine, I had no Python installed and the lyx2lyx script failed. I now installed Microsoft's VC++ redistributable package, as suggested by Paul Rubin, and now the lyx2lyx script works. So I think there is a problem with the python.exe and/or python26.dll which are in the bin directory of LyX 1.6. But I also had no Python installed on this Vista machine, only installed LyX using my installer and it worked. I also got feedback that it works for others too. regards Uwe
Re: lyx2lyx script broken (1.6.0 on Vista)
Uwe Stöhr wrote: > Dominik Waßenhoven schrieb: >> In the bin directory is a python26.dll file. >> Oh -- I just saw that I have a full Python installed on the WinXP >> machine (I didn't realize that, sorry...). It's Python 2.5.1 > This means that you have Python 2.5.1 installed but the installer didn't > recognize it. No, I think I was not clear enough. The second sentenc you cited above bear on my insallation on a WinXP system, where your installer worked perfectly. On the Vista machine, I had no Python installed and the lyx2lyx script failed. I now installed Microsoft's VC++ redistributable package, as suggested by Paul Rubin, and now the lyx2lyx script works. So I think there is a problem with the python.exe and/or python26.dll which are in the bin directory of LyX 1.6. > I'm currently also on a Vista machine but cannot reproduce the problem. > I installed here also Python 2.5.1 and then LyX using my installer. LyX > correctly recognized Python 2.5.1 and therefore not installed Python 2.6. As I said, the scenario was different for me, as I had /no/ Python installed. Thanks for your effort, Dominik.-
Re: lyx2lyx script broken (1.6.0 on Vista)
Paul A. Rubin wrote: > Dominik Waßenhoven wrote: >> Should I try to install Python on Vista and try to convert >> from LyX 1.5 to 1.6 again? > That would likely work. Alternatively, you might install the M$ VC++ > redistributable package > (http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF=de) > and see if that does the trick. Indeed, it does! Thanks a lot. Regards, Dominik.-
Re: lyx2lyx script broken (1.6.0 on Vista)
Dominik Waßenhoven schrieb: On the Vista machine, I had no Python installed and the lyx2lyx script failed. I now installed Microsoft's VC++ redistributable package, as suggested by Paul Rubin, and now the lyx2lyx script works. So I think there is a problem with the python.exe and/or python26.dll which are in the bin directory of LyX 1.6. But I also had no Python installed on this Vista machine, only installed LyX using my installer and it worked. I also got feedback that it works for others too. regards Uwe
Re: lyx2lyx script broken (1.6.0 on Vista)
Paul A. Rubin wrote: Dominik Waßenhoven wrote: Dominik »Ingrid« Waßenhoven wrote: I installed LyX 1.6.0 on WinXP without problems and can open lyx files of the 1.5.x series. But on Windows Vista, the same installation cannot read 1.5.x files. I forgot: I used Uwe's AltInstaller. Opening a 1.5.x doc requires that lyx2lyx, a Python script, be run. Do you have the same installation of Python on both boxes (just the subset that Uwe bundles, or a full install on both)? I have only the Python that Uwe bundles, on both machines. I used Uwe's full installer. Also, you might check try converting a file manually on the Vista box, using a DOS shell. I will try that, but I have no permanent access to the Vista machine... I will report later if this works. Thanks so far, Dominik.-
Re: lyx2lyx script broken (1.6.0 on Vista)
Paul A. Rubin wrote: Also, you might check try converting a file manually on the Vista box, using a DOS shell. This would look something like C:\Program Files\LyX16\python\python.exe C:\Program Files\LyX16\Resources\lyx2lyx\lyx2lyx doc.lyx where doc.lyx is the old document. If it works, the converted file will be written on screen. This doesn't work either. I get the following error message: ,---. ¦ line 23, in module import unicodedata ¦ ¦ DLL load failed: Diese Anwendung konnte nicht gestartet werden, ¦ ¦ da die Side-by-Side-Konfiguration ungültig ist. Weitere Informationen ¦ ¦ finden Sie im Anwendungsereignisprotokoll.¦ `---´ In the bin directory is a python26.dll file. Oh -- I just saw that I have a full Python installed on the WinXP machine (I didn't realize that, sorry...). It's Python 2.5.1 Any ideas? Should I try to install Python on Vista and try to convert from LyX 1.5 to 1.6 again? TIA, Dominik.-
Re: lyx2lyx script broken (1.6.0 on Vista)
Dominik Waßenhoven wrote: Paul A. Rubin wrote: Also, you might check try converting a file manually on the Vista box, using a DOS shell. This would look something like C:\Program Files\LyX16\python\python.exe C:\Program Files\LyX16\Resources\lyx2lyx\lyx2lyx doc.lyx where doc.lyx is the old document. If it works, the converted file will be written on screen. This doesn't work either. I get the following error message: ,---. ¦ line 23, in module import unicodedata ¦ ¦ DLL load failed: Diese Anwendung konnte nicht gestartet werden, ¦ ¦ da die Side-by-Side-Konfiguration ungültig ist. Weitere Informationen ¦ ¦ finden Sie im Anwendungsereignisprotokoll.¦ `---´ In the bin directory is a python26.dll file. Oh -- I just saw that I have a full Python installed on the WinXP machine (I didn't realize that, sorry...). It's Python 2.5.1 Any ideas? Should I try to install Python on Vista and try to convert from LyX 1.5 to 1.6 again? That would likely work. Alternatively, you might install the M$ VC++ redistributable package (http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BFdisplaylang=de) and see if that does the trick. I googled the side-by-side configuration error message (rather unusual, which is fortunate from a search standpoint), and it appears to occur in other contexts, the common theme being that some piece of software is missing. HTH, Paul
Re: lyx2lyx script broken (1.6.0 on Vista)
Dominik Waßenhoven schrieb: In the bin directory is a python26.dll file. Oh -- I just saw that I have a full Python installed on the WinXP machine (I didn't realize that, sorry...). It's Python 2.5.1 This means that you have Python 2.5.1 installed but the installer didn't recognize it. I'm currently also on a Vista machine but cannot reproduce the problem. I installed here also Python 2.5.1 and then LyX using my installer. LyX correctly recognized Python 2.5.1 and therefore not installed Python 2.6. To solve your problems, I propose to uninstall Python 2.5.1, uninstall LyX, install Python 2.6 and afterwards LyX again. regards Uwe p.s. I'll provide a new installer version within the next 2 hours that fixes some Vista-specific bugs.
new LyX installer for Vista was: Re: lyx2lyx script broken (1.6.0 on Vista)
I wrote: p.s. I'll provide a new installer version within the next 2 hours that fixes some Vista-specific bugs. You can now download this version from: https://developer.berlios.de/project/showfiles.php?group_id=5117release_id=15417 That fixes the following bugs: - fix a bug in the Romanian translation of the installer - fix installation of Aspell dictionaries in Win Vista - fix uninstallation of the file extensions .lyx14 and the like You would do me a big favour when you give it a try and report back if it works for you. thanks and regards Uwe
Re: lyx2lyx script broken (1.6.0 on Vista)
Paul A. Rubin wrote: Dominik Waßenhoven wrote: Dominik »Ingrid« Waßenhoven wrote: I installed LyX 1.6.0 on WinXP without problems and can open lyx files of the 1.5.x series. But on Windows Vista, the same installation cannot read 1.5.x files. I forgot: I used Uwe's AltInstaller. Opening a 1.5.x doc requires that lyx2lyx, a Python script, be run. Do you have the same installation of Python on both boxes (just the subset that Uwe bundles, or a full install on both)? I have only the Python that Uwe bundles, on both machines. I used Uwe's full installer. Also, you might check try converting a file manually on the Vista box, using a DOS shell. I will try that, but I have no permanent access to the Vista machine... I will report later if this works. Thanks so far, Dominik.-
Re: lyx2lyx script broken (1.6.0 on Vista)
Paul A. Rubin wrote: Also, you might check try converting a file manually on the Vista box, using a DOS shell. This would look something like C:\Program Files\LyX16\python\python.exe C:\Program Files\LyX16\Resources\lyx2lyx\lyx2lyx doc.lyx where doc.lyx is the old document. If it works, the converted file will be written on screen. This doesn't work either. I get the following error message: ,---. ¦ line 23, in module import unicodedata ¦ ¦ DLL load failed: Diese Anwendung konnte nicht gestartet werden, ¦ ¦ da die Side-by-Side-Konfiguration ungültig ist. Weitere Informationen ¦ ¦ finden Sie im Anwendungsereignisprotokoll.¦ `---´ In the bin directory is a python26.dll file. Oh -- I just saw that I have a full Python installed on the WinXP machine (I didn't realize that, sorry...). It's Python 2.5.1 Any ideas? Should I try to install Python on Vista and try to convert from LyX 1.5 to 1.6 again? TIA, Dominik.-
Re: lyx2lyx script broken (1.6.0 on Vista)
Dominik Waßenhoven wrote: Paul A. Rubin wrote: Also, you might check try converting a file manually on the Vista box, using a DOS shell. This would look something like C:\Program Files\LyX16\python\python.exe C:\Program Files\LyX16\Resources\lyx2lyx\lyx2lyx doc.lyx where doc.lyx is the old document. If it works, the converted file will be written on screen. This doesn't work either. I get the following error message: ,---. ¦ line 23, in module import unicodedata ¦ ¦ DLL load failed: Diese Anwendung konnte nicht gestartet werden, ¦ ¦ da die Side-by-Side-Konfiguration ungültig ist. Weitere Informationen ¦ ¦ finden Sie im Anwendungsereignisprotokoll.¦ `---´ In the bin directory is a python26.dll file. Oh -- I just saw that I have a full Python installed on the WinXP machine (I didn't realize that, sorry...). It's Python 2.5.1 Any ideas? Should I try to install Python on Vista and try to convert from LyX 1.5 to 1.6 again? That would likely work. Alternatively, you might install the M$ VC++ redistributable package (http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BFdisplaylang=de) and see if that does the trick. I googled the side-by-side configuration error message (rather unusual, which is fortunate from a search standpoint), and it appears to occur in other contexts, the common theme being that some piece of software is missing. HTH, Paul
Re: lyx2lyx script broken (1.6.0 on Vista)
Dominik Waßenhoven schrieb: In the bin directory is a python26.dll file. Oh -- I just saw that I have a full Python installed on the WinXP machine (I didn't realize that, sorry...). It's Python 2.5.1 This means that you have Python 2.5.1 installed but the installer didn't recognize it. I'm currently also on a Vista machine but cannot reproduce the problem. I installed here also Python 2.5.1 and then LyX using my installer. LyX correctly recognized Python 2.5.1 and therefore not installed Python 2.6. To solve your problems, I propose to uninstall Python 2.5.1, uninstall LyX, install Python 2.6 and afterwards LyX again. regards Uwe p.s. I'll provide a new installer version within the next 2 hours that fixes some Vista-specific bugs.
new LyX installer for Vista was: Re: lyx2lyx script broken (1.6.0 on Vista)
I wrote: p.s. I'll provide a new installer version within the next 2 hours that fixes some Vista-specific bugs. You can now download this version from: https://developer.berlios.de/project/showfiles.php?group_id=5117release_id=15417 That fixes the following bugs: - fix a bug in the Romanian translation of the installer - fix installation of Aspell dictionaries in Win Vista - fix uninstallation of the file extensions .lyx14 and the like You would do me a big favour when you give it a try and report back if it works for you. thanks and regards Uwe
Re: lyx2lyx script broken (1.6.0 on Vista)
Paul A. Rubin wrote: > Dominik Waßenhoven wrote: >> Dominik »Ingrid« Waßenhoven wrote: >>> I installed LyX 1.6.0 on WinXP without problems and can open lyx files >>> of the 1.5.x series. But on Windows Vista, the same installation cannot >>> read 1.5.x files. >> I forgot: I used Uwe's AltInstaller. > Opening a 1.5.x doc requires that lyx2lyx, a Python script, be run. Do > you have the same installation of Python on both boxes (just the subset > that Uwe bundles, or a full install on both)? I have only the Python that Uwe bundles, on both machines. I used Uwe's full installer. > Also, you might check try converting a file manually on the Vista box, > using a DOS shell. I will try that, but I have no permanent access to the Vista machine... I will report later if this works. Thanks so far, Dominik.-
Re: lyx2lyx script broken (1.6.0 on Vista)
Paul A. Rubin wrote: > Also, you might check try converting a file manually on the Vista box, > using a DOS shell. This would look something like >> "C:\Program Files\LyX16\python\python.exe" "C:\Program >> Files\LyX16\Resources\lyx2lyx\lyx2lyx" doc.lyx > where doc.lyx is the old document. If it works, the converted file will > be written on screen. This doesn't work either. I get the following error message: ,---. ¦ line 23, in import unicodedata ¦ ¦ DLL load failed: Diese Anwendung konnte nicht gestartet werden, ¦ ¦ da die Side-by-Side-Konfiguration ungültig ist. Weitere Informationen ¦ ¦ finden Sie im Anwendungsereignisprotokoll.¦ `---´ In the bin directory is a python26.dll file. Oh -- I just saw that I have a full Python installed on the WinXP machine (I didn't realize that, sorry...). It's Python 2.5.1 Any ideas? Should I try to install Python on Vista and try to convert from LyX 1.5 to 1.6 again? TIA, Dominik.-
Re: lyx2lyx script broken (1.6.0 on Vista)
Dominik Waßenhoven wrote: Paul A. Rubin wrote: Also, you might check try converting a file manually on the Vista box, using a DOS shell. This would look something like "C:\Program Files\LyX16\python\python.exe" "C:\Program Files\LyX16\Resources\lyx2lyx\lyx2lyx" doc.lyx where doc.lyx is the old document. If it works, the converted file will be written on screen. This doesn't work either. I get the following error message: ,---. ¦ line 23, in import unicodedata ¦ ¦ DLL load failed: Diese Anwendung konnte nicht gestartet werden, ¦ ¦ da die Side-by-Side-Konfiguration ungültig ist. Weitere Informationen ¦ ¦ finden Sie im Anwendungsereignisprotokoll.¦ `---´ In the bin directory is a python26.dll file. Oh -- I just saw that I have a full Python installed on the WinXP machine (I didn't realize that, sorry...). It's Python 2.5.1 Any ideas? Should I try to install Python on Vista and try to convert from LyX 1.5 to 1.6 again? That would likely work. Alternatively, you might install the M$ VC++ redistributable package (http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF=de) and see if that does the trick. I googled the side-by-side configuration error message (rather unusual, which is fortunate from a search standpoint), and it appears to occur in other contexts, the common theme being that some piece of software is missing. HTH, Paul
Re: lyx2lyx script broken (1.6.0 on Vista)
Dominik Waßenhoven schrieb: In the bin directory is a python26.dll file. Oh -- I just saw that I have a full Python installed on the WinXP machine (I didn't realize that, sorry...). It's Python 2.5.1 This means that you have Python 2.5.1 installed but the installer didn't recognize it. I'm currently also on a Vista machine but cannot reproduce the problem. I installed here also Python 2.5.1 and then LyX using my installer. LyX correctly recognized Python 2.5.1 and therefore not installed Python 2.6. To solve your problems, I propose to uninstall Python 2.5.1, uninstall LyX, install Python 2.6 and afterwards LyX again. regards Uwe p.s. I'll provide a new installer version within the next 2 hours that fixes some Vista-specific bugs.
new LyX installer for Vista was: Re: lyx2lyx script broken (1.6.0 on Vista)
I wrote: p.s. I'll provide a new installer version within the next 2 hours that fixes some Vista-specific bugs. You can now download this version from: https://developer.berlios.de/project/showfiles.php?group_id=5117_id=15417 That fixes the following bugs: - fix a bug in the Romanian translation of the installer - fix installation of Aspell dictionaries in Win Vista - fix uninstallation of the file extensions ".lyx14" and the like You would do me a big favour when you give it a try and report back if it works for you. thanks and regards Uwe
Re: lyx2lyx script broken (1.6.0 on Vista)
Dominik »Ingrid« Waßenhoven wrote: I installed LyX 1.6.0 on WinXP without problems and can open lyx files of the 1.5.x series. But on Windows Vista, the same installation cannot read 1.5.x files. I forgot: I used Uwe's AltInstaller. Regards, Dominik.-
Re: lyx2lyx script broken (1.6.0 on Vista)
Dominik Waßenhoven wrote: Dominik »Ingrid« Waßenhoven wrote: I installed LyX 1.6.0 on WinXP without problems and can open lyx files of the 1.5.x series. But on Windows Vista, the same installation cannot read 1.5.x files. I forgot: I used Uwe's AltInstaller. Opening a 1.5.x doc requires that lyx2lyx, a Python script, be run. Do you have the same installation of Python on both boxes (just the subset that Uwe bundles, or a full install on both)? Also, you might check try converting a file manually on the Vista box, using a DOS shell. This would look something like C:\Program Files\LyX16\python\python.exe C:\Program Files\LyX16\Resources\lyx2lyx\lyx2lyx doc.lyx where doc.lyx is the old document. If it works, the converted file will be written on screen. I'm wondering if perhaps there's a permission problem accessing Python? /Paul
[Fwd: Re: lyx2lyx script broken (1.6.0 on Vista)]
I have the same problem in Windows Vista with the Uwe's AltInstaller. Sergio Dominik Waßenhoven escribió: Dominik »Ingrid« Waßenhoven wrote: I installed LyX 1.6.0 on WinXP without problems and can open lyx files of the 1.5.x series. But on Windows Vista, the same installation cannot read 1.5.x files. I forgot: I used Uwe's AltInstaller. Regards, Dominik.-
Re: lyx2lyx script broken (1.6.0 on Vista)
Dominik »Ingrid« Waßenhoven wrote: I installed LyX 1.6.0 on WinXP without problems and can open lyx files of the 1.5.x series. But on Windows Vista, the same installation cannot read 1.5.x files. I forgot: I used Uwe's AltInstaller. Regards, Dominik.-
