[Top][All Lists]

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

Re: Several problems with 2.5.27 version on Windows ME

From: Jan Nieuwenhuizen
Subject: Re: Several problems with 2.5.27 version on Windows ME
Date: Wed, 08 Jun 2005 11:00:30 +0200
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux)

Brynne and Russ Jorgensen writes:

> Thanks for the reply.  See below for specific stuff I've found.

Ok.  Please keep all lilypond-related communication on the lilypond
list (cc'd).

> I got the MS-WIN install program (
> through
> I agree with your suggestion to mention on the download page that 2.4
> is the stable release and 2.5 is in development.


> I've attached the modified

Thanks.  I think that some people have problems with this

    set address@hidden@\usr\etc\fonts\fonts.conf

because INSTDIR may contain spaces.  but we haven't gotten a useful
bug report about this yet.  See below.
> I didn't like the msdoss-ey path hack, either, but MS-WIN
> inconstency got me confused.  If you do
> set A="hi there"
> echo %A%
> you get
> "hi there"
> so I didn't think that putting in double quotes was the
> answer. HOWEVER, if you do
> set PATH="c:\program files\folder"
> echo %PATH%
> you get
> Surprisingly, MS-WIN treats double quotes in PATH differently from
> other environment variables.

What if you do

    set "a=hi there"
    echo %a%

that's what I tried for 2.5.28

> When I run ooes.exe, it pops up a dos box to run the ooes.bat, but the
> dos-box sticks around (title bar says 'Finished - ooes') rather than
> disappearing.
> Before fixing the global setting for amount of environment memory, the
> dos-box said 'Out of environment space', but ooes.exe said
> Environment space is fine'.  Looks like the exit code from ooes.bat
> isn't making it back to ooes.exe.

Thanks for testing this.  We need more elaborate testing, ie the value
of a variable and explicit exit code.  Something like

    set ooes=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx....
    [out of environment space]
    set foo=bar
    if not x%foo%=xbar got error
    exit 0
    exit 1

Could you test if that works?  It may be that the first set statement
causing the error is ignored, and a still gets the value foo.

> Globally increasing the amount environment memory to 4096 does make
> the shortcuts to lilypad.bat work without changing them individually.
> FYI -


> globally setting the amount of environment memory under Win-ME is more
> difficult under Win-ME than Win-95 and Win-98.  They've disabled a
> bunch of the old DOS stuff - in particular, I've never found ANYTHING
> that can go in config.sys.  Instead, I found instructions on the
> internet as follows:
>      add the following line to the SYSTEM.INI file (in c:\windows) under
>      CommandEnvSize=4096
> I used the msconfig tool to do this instead of editing by hand...

Do you have a Microsoft URL that we can present in the popup box?

>>>3) About the lilypond.bat shortcuts, I don't really get the point -
>> The point is that windows users expect to be able to click a
>> program.
>> I think that's a must.
> I agree that people expect it, and now that I realize that it's
> supposed to start LilyPad, of course it makes sense.

In time, we hope to offer something better, but that's probably more
than a yeaf off, still.

> There are a couple of things going on here, but it still isn't working...
> First off, even though lilypond.bat puts C:\Program
> Files\LilyPond\usr\bin in the PATH, the explorer association with .ly
> files points directly at lilypond.exe, so you're at the mercy of the
> default PATH.

Then that's a bug.  Can you try with 2.5.28?  The shell generate
command should say

    $ regtool get /root/LilyPond/shell/generate/command/
    "C:\Program Files\LilyPond\usr\bin\lilypond.exe" "%1"

> In my case, I have cygwin installed, so the default gs
> was the cygwin gs.exe rather than the lilypond gs.bat.

Can you double check?  What does lilypond.exe --verbose --help say?
LilyPond should prepend it's bindir to PATH.

> I tried adding C:\Program Files\LilyPond\usr\bin into my default PATH
> before cygwin to force it to use gs.bat, but when I double-click the
> .ly file to convert to PDF

Double-click to convert is a Cygwin thing.  The native version opens
lilypad by default.  The shell open command should say

    $ regtool get /root/LilyPond/shell/open/command/
   "C:\Program Files\LilyPond\usr\bin\lilypad.exe" "%1"

Just thinking, did you perchance update/refresh Cygwin's lilypond lately?

> , the verbose .log file says:
> Invoking `gs -dCompatibilityLevel#1.4  -sPAPERSIZE#"a4" -q -dNOPAUSE
> -dBATCH -sDEVICE#pdfwrite -sOutputFile#"example-1.pdf" -c .setpdfwrite
> -f ""'...
> but apparently gs.bat never actually gets run.

Why do you think that?

> So, I tried changing the .ly association to lilypond.bat instead of
> lilypond.exe, but that didn't work either.  For one thing, when
> lilypond.exe gets run, a dox-box pops up, and I get the "out of
> environment space" message a bunch, which is weird given that if I
> just run lilypond.bat from a short-cut, it doesn't do that.  But,
> regardless, the PDF file does not get created.
> I'm not sure how to proceed on this one.  Any ideas?

It appears to me af if you did not manage to actually globally
increase the environment space, but only did so for the destkop
shortcut.  Try running ooes.bat from 2.5.28 from the command line.

> (By the way, I'm
> not a big fan of solutions that require messing with the default
> PATH...)

No, it should work ootb.

> I ran it under gdb, still got no windows, but it exited normally - not
> a segv as I half expected.  So, I ran again, single stepping through
> WinMain, and figured out that the very first windows call
> (RegisterClassEx I think it was - I'm not looking at the src at this
> second) was failing, which resulted in WinMain() exiting immediately
> without doing anything.  I compiled the source, and found out it was
> error code 120: ERROR_CALL_NOT_IMPLEMENTED - "this function is not
> supported on this system".  Pretty weird - why wouldn't
> RegisterClassEx be supported?  I hacked around quite a while, and
> FINALLY figured out that it was the '#define UNICODE' in main.c and
> dialog.c.  I'd forgotten, but Win9X and WinME don't natively support

> Microsoft now offers something called MSLU - 'Microsoft Layer
> for Unicode on Windows 95/98/Me Systems' that you can download (part
> of it you need to get from the SDK) that might be used to rectify the
> situation.  There's also an open-source effort called "Opencow: Open
> Layer for Unicode" that might also be used.  I'm not sure whether
> unicode is necessary for LilyPad, so rather than go to a bunch of work
> right now with MSLU or Unicow, I just modified LilyPad to compile
> either unicode or non-unicode.  I made non-unicode the default, and
> included a tarball of the files I modified.

Wow, thanks a lot for finding this.  Actually, unicode is essential
for non-ascii characters.  So maybe, we should ship two versions of
lilypad (lilypad and lilypad-ascii), or instruct users of lesser
Windows versions to dowload that Unicode compatibility layer, or drop
official support for the lesser Windows versions, or maybe drop the
whole lilypad exercise again.  Or maybe we can all get together and
write a new, free operating system that does not suck.


> 1) When registering the "Generate PDF...", "Open", and "Edit
>    source..." explorer extensions associated with .ly files, putting
>    double quotes around the program path name causes explorer to pass
>    file names as regular long win32 filenames - otherwise explorer
>    decides to pass the crappy uppercase ms-dossey file names with
>    tildas and stuff.  I have no idea why - I just happened upon it.  I
>    think I ran into a case where this didn't work as described, but I
>    can't remember for sure.  It doesn't hurt anything, and by my
>    experiments usually helps...

Yes, I included that fix in 2.5.28.

> 2) When running the desktop and start menu LilyPond shortcuts, now
>    that LilyPad will actually execute, I get the following error:
> File '0:0 "C:/Program
> Files/LilyPond/usr/share/lilypond/2.5.27/ly/".ly'
> does not exist
> So, the command-line parsing in LilyPond looks to need some work.

This should be fixed in 2.5.28, or lilypad-0.0.4.

> I don't have time right now to debug it, though.  Whoever is adding
> that 0:0 onto the beginning (looks like an X-11 artifact) needs to
> be fixed as well.

No, that's the point and click marker.  The `+' got eaten, as Windows
not always includes argv[0] in the command line.

> 3) Maybe the biggest additional issue.  With LilyPond 2.4 on windows,
>    the resulting PS file could be viewed by gsview.  With this
>    version, even though I can run ghostscript by hand to convert to
>    PDF and view that way, if I instead use gsview on the PS file, I
>    get the following error:
> I verified the two '%%BeginFont: ..." files are in the given folders,
> I guess that's all for now.  If you have any ideas on further
> debugging why the PS isn't being converted to PDF, let me know!

This is hopefully fixed in 2.5.28, as we now use ttftool to embed the

Thanks a lot.


Jan Nieuwenhuizen <address@hidden> | GNU LilyPond - The music typesetter       |

reply via email to

[Prev in Thread] Current Thread [Next in Thread]