Menu

hp2xx fails in windows 7

Help
2011-03-23
2013-01-07
  • shinysurfer

    shinysurfer - 2011-03-23

    hp2xx is failing to run on Windows 7. I believe it is this line in hp2xx.c
    that fails:

    if ((pg->td = tmpfile()) == NULL)

    The temp file IS actually created (this is NOT the problem with creating the
    file in the root dir), but I believe W7 is returning a less than perfect
    return causing the failure. Anyway, we are trying to make a temporary fix and
    recompile. We are finding it very difficult to recompile with the GUI
    environment or makefiles. Can anyone provide guidance on a fix or more precise
    recompile instructions on a windows compile of hp2xx?

    Thanks

    Tom de Castro

     
  • Jay Satiro

    Jay Satiro - 2011-03-25

    Compiling hp2xx in mingw required some changes if I remember right. I had to
    make a makefile for it. My version had png support but not tiff. It's old
    though like two years. I'll probably write a replacement tmpdir(). Really a
    big issue is we should have temporary files first in temp tmp tmpdir if
    possible. I'll look into it this weekend.

     
  • shinysurfer

    shinysurfer - 2011-03-28

    Jay,

    On my version of W7 the tmpdir() function does obey the temp variable for
    location for creating the temp files. In fact, it does successfully create the
    files, but still apparently returns an error to the program.

    Anyway, I downloaded mingw C compiler and make utility. If you have a makefile
    that is close, I would apprectiate the help.

    Thanks

    Tom

     
  • Jay Satiro

    Jay Satiro - 2011-03-28

    I started writing a tmpfile() replacement. I didn't have a chance yet to look
    into why hp2xx might be failing on Windows 7 x64. What you can do is try
    changing the source to use hp2xx.$$$ as your tempfile. Refer to hp2xx.c:659
    HPGL_to_TMP().

    For now I've uploaded the modified source I use and included the libpng/zlib
    binaries for png support.

    You should be able to compile from rxvt or the command prompt, however hp2xx
    has output problems in rxvt.

    Read the README-FIRST.txt and png14/README.txt

    [http://sourceforge.net/projects/getgnuwin32/files/getgnuwin32/test%20builds/]
    (http://sourceforge.net/projects/getgnuwin32/files/getgnuwin32/test%20builds/)

    My make was successful, I used tdm build of gcc to test the make.

    gcc.exe (tdm-1) 4.5.1
    Copyright (C) 2010 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    

    I only had one warning for deprecated jmpbuf, you can ignore that

     
  • Allan

    Allan - 2011-04-02

    For now I've uploaded the modified source I use and included the libpng/zlib
    binaries for png support.

    You should be able to compile from rxvt or the command prompt, however hp2xx
    has output problems in rxvt.

    Read the README-FIRST.txt and png14/README.txt

    [http://sourceforge.net/projects/getgnuwin32/files/getgnuwin32/test%20builds/]
    (http://sourceforge.net/projects/getgnuwin32/files/getgnuwin32/test%20builds/)

    Thanks for uploading the test version; I don't need this package but I was
    curious anyway. I built this test version with the official mingw32 gcc 4.5.2
    but first I installed libpng 1.4.5 and zlib 1.2.5 (which I wanted to do
    anyway). I then compiled with the included png support modules but linked with
    my self-built zlib and libpng binaries. I received the same warning about
    `jmpbuf' when compiling png.c. It passed the tests essentially. I am using
    Windows XP SP3.

     
  • shinysurfer

    shinysurfer - 2011-04-05

    jay,

    I have downloaded your files and I am attempting a compile with tif support. I
    have to_tif.c but it is referencing "tiffio.h", which I can't seem to find
    anywhere. Any suggestions?

    Thanks

    tom

     
  • Allan

    Allan - 2011-04-05

    I have the Gnuwin tiff package installed (version 3.8.2) but you may want to
    build the latest version (3.9.4) yourself. The development header files are
    included in the Windows installer version of the Gnuwin package. Then you
    could edit the Makefile to build against the Gnuwin tiff binaries.

     
  • shinysurfer

    shinysurfer - 2011-04-05

    thanks Allan. I just found tiff-3.7.2-src.zip. This matches the version of the
    tiff dll we are using on XP

    (libtiff3.dll ver .7.2.1953).

    Anyway, I was able to compile and link a new hp2xx.exe that works for us on
    W7.

    Thanks all

    Tom

     
  • claus

    claus - 2011-09-03

    hello shinysurfer, hello all,

    I am also having troubles getting hp2xx to run on win7 64 bit (hp2xx --
    opening temporary file: Invalid argument). Unfortunately I am not very
    familiar with c++ and compiling, so I'm asking whether you were so kind as to
    provide the working hp2xx.exe or giving a brief description what you changed
    and how you compiled it to make it run under win7.

    thanks,

    claus

     
  • claus

    claus - 2011-09-15

    hey all,

    got a bit of time today to look into this and I successfully compiled it using
    the source and description provided by raysatiro (BIG THANKS). did the png
    support, works; also got the jmpbuf warning but ignored this. in hp2xx.c,
    changed

    line 693 from

    if ((pg->td = tmpfile()) == NULL)
    

    to

    if ((pg->td = fopen("hp2xx.$$$", "w+b")) == NULL)
    

    . so.. works now for me too.

    thanks for this thread guys.

    claus

     
  • Allan

    Allan - 2011-09-16

    Using a fixed file name for a temp file can raise security concerns but maybe
    you should submit this to the package author anyway. His name is Martin Kröker
    mk@daveg.com or martin@ruby.chemie.uni-freiburg.de . I am not clear about
    your build platform details or your Windows 7 (?) version.

     
  • claus

    claus - 2011-09-16

    Thanks for your response. I just dropped Martin Kröker a few lines about this
    issue.

    As I said, it works for me at least, but it would be a pity if this great tool
    would just stop working because of this.

    Of course I am still interested in finding a better way to solve this issue,
    maybe I'll take a look at tmpfile() when I got some time.

    I used make and mingw on win7 x64 by the way.

     
  • Allan

    Allan - 2011-09-19

    The problem as I understand it is that MS interprets the ANSI C99 standard to
    say that tmpfile should create the file in the root directory `C:\'. I am
    afraid the burden is on the programmer to be aware of this issue, including
    for Windows XP limited users, not just Vista and Windows 7. You may want to
    download a copy of glibc version 2.14 and look at <libio stdio.h=""> . You
    probably compiled using mingw <stdio.h> . If the author publishes an updated
    version you could start a new thread as this one is getting stale.</stdio.h></libio>

     
  • Keith Marshall

    Keith Marshall - 2011-09-27

    The problem as I understand it is that MS interprets the ANSI C99 standard
    to say that tmpfile should create the file in the root directory `C:\'.

    No, that isn't strictly correct.

    Microsoft's tmpfile() implementation has always been -- to say the least
    -- "odd". It will usually prefix a single backslash to the generated unique
    file name. However, this does not imply that the file should be created in
    the root (C:) directory; according to the MS documentation on MSDN, it
    indicates that the file may be safely created in the current working
    directory
    , but the onus is placed on the programmer, to adjust the returned
    path name accordingly.

    I am afraid the burden is on the programmer to be aware of this issue,
    including for Windows XP limited users, not just Vista and Windows 7.

    That burden applies for all MS-Windows versions, from the dawn of MS-
    Windows time, not just to XP and later. There are many -- myself among them --
    who have been bitten by this quirky behaviour, and consider it to be broken.
    However, it is "as documented", so technically it isn't a bug; we just have to
    live with and work around it.

    You may want to download a copy of glibc version 2.14 and look at
    <libio stdio.h="">. You probably compiled using mingw <stdio.h></stdio.h></libio>

    Well, that's standard behaviour for MinGW -- it uses Microsoft's runtime
    services by design. A study of the glibc implementation (as used by
    Linux?) may be instructive, but it's hardly relevant in the MinGW context.

     
  • shinysurfer

    shinysurfer - 2011-10-13

    I do not believe the problem is because windows is trying to create the
    tempfile in the root directory c:. My tests have shown that the temp file is
    created in the current working directory. The file is created even when the
    program fails. I think the OS is just returning a less then perfect return
    code and triggering the error. I suspect we may need to switch to tmpfile_s()

     
  • Code Majster

    Code Majster - 2011-11-23

    Hi all,

    Claus,

    Can you post your hp2xx binary? I think your modification for fixed temp file
    name is fine. Since you made a change to hp2xx.c, is your fix generic for all
    file types? If not can you tell me how you managed MinGW to compile? For some
    reason "mingw32-make all" gives me an error. Here is the output:

    D:\Temp\hp2xx-3.4.4\sources>mingw32-make all

    gcc -ggdb3 -DPNG -I../png14/include -c -O3 -Wall -Wextra -Wno-unused-parameter
    hp2xx.c

    process_begin: CreateProcess(NULL, gcc -ggdb3 -DPNG -I../png14/include -c -O3
    -W

    all -Wextra -Wno-unused-parameter hp2xx.c, ...) failed.

    make (e=2): The system cannot find the file specified.

    mingw32-make: *** Error 2

    I was not sure how to point mingw32-make.exe to the sources directory and
    execute "all" command, so I just dumped it with the dlls to this directory and
    executed it. But again, I got an error. I tried putting cp.exe into the
    directory as well, but I got the same thing.

    Did you get any response from Martin Kröker?

    Any help would be appreciated.

    Thanks,

    CodeMajster

     
  • Code Majster

    Code Majster - 2011-11-28

    Hello all,

    In the end I used MS Visual Studio 2010 and managed to convert Visual C 6.00
    project files included in makes directory. I had to re-add all header files to
    the project. I got lots of errors but this time they have been descriptive
    enough. Since, I only needed conversion to emf, I removed all "to_" files that
    caused errors and compiled without any problems. These files (to_pdf, to_png,
    to_tif, to_x11) seem to reference unix or other dependencies and I did not
    want to spend time on resolving/fixing them.

    Claus,

    Your solution to replace tmpfile() function with a specific file works great.
    I'm running hidden hp2xx program from .NET app. The location of the temp file
    can be easily controlled by setting working directory of the process (works
    with working directory field of the windows shortcuts too).

    Thanks again,

    CodeMajster

     
  • Adam

    Adam - 2013-01-07

    FWIW I was able to compile hp2xx w/MinGW on my Windows 7 machine using the same workaround as was proposed in

    http://cgit.freedesktop.org/cairo/commit/?id=4fa46e3caaffb54f4419887418d8d0ea39816092

    to get past the tmpfile() issue.

    I confirmed that my compiled executable can translate from .hgl to .png, .jpg and .tif without any obvious issues.

    I used the following external libraries:

    • libgw32c-0.4
    • jpeg-6b-4
    • zlib-1.2.3
    • tiff-3.8.2-1
    • libpng-1.2.37

    I simply searched for "gnuwin32 libjpeg", "gnuwin32 libtiff" etc. to get those libraries and headers, and merged them into my MinGW folder to get past the build errors. Inelegant, but it appears to have worked.

    I used hp2xx-3.4.4-2 as the baseline before adding the "cairo" modifications for overriding tmpfile().

    My MinGW installation was mingw-get-inst-20120426 and I allowed it to grab the latest libs on installation.

     
MongoDB Logo MongoDB