[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

RE: [XaraXtreme-dev] Doesn't start on Suse

Charles,

--On 14 April 2006 12:19 +0100 Charles Moir <CharlesM@xxxxxxxx> wrote:


Alex said:

Whilst this one is probably possible to catch as it's late
loaded (pango is the font rendering stuff), most shared
library problems are not late-loaded and you would not have
this option. This is exactly the same as windows. If you just
copy a binary onto a windows platform, and expect it to work,
it won't.


That's not what I expect or am asking for. I'm just asking that I get
useful error messages, as a user, so I can tell or report what's gone
wrong. And Windows does do that. It will say 'can't find xxx.dll' or
words to that effect.


The app /does/ do that, it's just that the desktop you are using ignores
it. Given the missing library may be the one that puts up error boxes
etc, there is very little that the app can do except write to STDERR
and set an exit code indicating "execution of this app has failed".

From memory (and it's a long time ago) this is very similar to how

what a windows app does if a /load/ time DLL is missing (not one
subsequently opened).

There is every possibility for a desktop that launches applications
to report such errors, but many of them don't. This is (IMHO) a bug
in the desktop, rather than in the app. I think all error handling
ceases after fork() & execve() succeed (i.e. after the binary has
been given control). This is (IMHO) too early as the binary cannot
at this stage necessarily report any errors to the user.

You are correct that the app could be a bit more intelligent if it's
a run-time DLL that is dlopen'd (if we can display a splash screen,
we should be able to get an error box up). However, this should not
happen if the app has been properly installed. IE the problem should
have been picked up and either corrected or reported at the install
stage.

I'm prepared to bet windows programs with an installer do exactly
the same thing. Install a windows program, delete a required DLL,
and see to what extent you get useful error handling. To be fair
they may pick up load-time required DLLs better as I think this
causes the exec to fail.


As such Linux is incredibly user hostile and Windows is a lot more user
friendly (and I'm talking normal users here who just double click a file
and expect to see something, if only an error, happen.)


Sure, but that, it seems to me, is largely the desktop's problem. If
you click on a pogram that says "I can't run" and reports the
error as best it can, you get nothing back.


Hoping to
produce a binary that will just load and run, when it needs
shared libraries, is I think cloud cuckoo land.


I'm not asking for that, just that I get user-friendly alert like
'XaraLX can't find the Pango (version xyz) shared library'

Even that would enable most users to suss it out themselves rather than
involving customer support (which doesn't exist on Linux). Even those
user's who can't solve it themselves, if they report that error to
anyone, say on a Forum, it's instantly obvious to more experienced Linux
users what the problem is and how it can be solved easily (e.g. using
their package manager to get Pango for example).


Well the pango case is a bit different, because it's late-linked
(i.e. it's dl-opened) so our code has at least started to execute
by the time the error is produced (as per the splash screen appearing).
We thus could presumably do something useful. I suspect something
is producing a SEGV etc. because some error isn't being handled.

However, for early linked stuff (e.g. the missing C++ library
bug you opened re Ubuntu), our code hasn't even started running.
In this instance, it's difficult to see what more we can do
other than badger bugzilla.ubuntu.com.

But my point was, in BOTH instances, having an installer would not
only report the problem earlier, but most likely fix it. And ...


For a user to just report 'well it didn't start and didn't give any
helpful error message', is clearly not in the slightest useful or
helpful to the user or anyone trying to help that user.


... the answer then would be "deinstall and reinstall"


It may be unavoidable that we have an install, But installers are, I'm
afraid, disgusting things, a source of a great deal of pain and expense,
and the world appears to be moving away from them. (e.g. Mac). It is
undeniable that it's a lot, lot better for everyone if the program is
stand-alone runable, relies on no installers to create secret
incantations with registry setting or other hidden stuff (MS even have
been recommending not to use the registry and to use local settings
files for some years now for this very reason).  Install problems are
probably the single most expensive problem that most commercial software
vendors face (I know it is for Xara) and the single most frustrating
problems for users.

So the ideal solution is that the application is smart, able to test it
has the environment it requires, is able to report to the user when bits
are missing. It should self-register (things like file type
associations, thumbnail viewers, icons, registry entries etc) without
relying on someone else having done this for it.  That is the way the
world is moving and is what Microsoft are recommending is a goal as
well.


I agree that it is a good thing to minimize what is in an installer.
However, it's a bit hard to know what to do if you can't find your
shared C library. Equally, there are very good reasons (security)
why linux doesn't allow "normal" programs to install shared libraries
(security privileges) which is why you get to type your password
again when installing from synaptic. The MS view of "click on anything
and it will run" is exactly why MS machines are susceptible to viruses!

Equally, I note that you're not taking your own medicine here. It doesn't
seem to be impossible to install Xtreme by copying a binary. Or even
by a simple process of copying binaries and DLLs. Else both of us
would be able to run it in Crossover Office which we believe will
run Xtreme fine but just dislikes the installer. I presume (giving
it's clearly giving you so much grief) the Xtreme installer must
therefore also be doing something useful :-)


Note that on windows you wouldn't even get the option to type
a cryptic command line incantation. You'd just double click
on the icon and nothing would happen,


No, something would happen. I can't recall ever seeing a Windows program
just quit (or worse) not even start, with no message, error or anything.


I've seen that happen (indeed by leaking GDI resources I can get it to
happen repeatably with Xtreme), but you are right (on reflection), what you
describe below is indeed the general result.


Case in point. I just deleted a critical shared library on Xara Xtreme
for Windows and attempted to start it. I got this error message
"The application has failed to start because xaradraw.dll was not
found."  I'm not even sure Xara produced this error message. I suspect
it might have come from the OS.

And that's the simple point I'm trying to make - that is useful. Simply
disappearing-with-no-message is not useful.

Why, if it can output useful or semi-useful messages to the console when
it fails to start an application (from the console) can't it provide the
same info in a nice user-friendly pop-up alert when you double click to
start the application. Sending error messages, in effect, down the drain
is a pointless.


Agree - send bug report to SuSE!


And yes I agree we should also be providing OS packages to try and
resolve these problems, but we don't have them (or rather we're getting
near having a .deb I understand) but that doesn't help users on the
other distributions.

Perhaps a universal installer is what we require. The klik guys have
been chasing us to use that.
klik://xara-latest


There are a few of them about, but I don't know enough about them
to recommend one over the others.


For 0.5 we require that these problems be resolved. i.e. that I can
start the application on a plain vanilla Ubuntu and it works (it doesn't
right now) or Suse, or any other common Linux.


Well you are not going to be able, by an app code change, to solve the
problem that running the application with a load time shared library
doesn't report an error without patching your desktop. None of our code
even gets run. The solution here for "normal users" is to get Joachim's
.deb working.

The pango problem is (I would have thought) fixable - clearly
our code is running by the time this error occurs. Perhaps there is
some nasty interaction between wxWidgets (which tries to
dlopen() pango late IIRC) and the release build (which is probably
trying to static link it in). Having the same library (possibly
2 different versions) both static and dynamic linked in doesn't
seem fun.

Alex