Due to a number of constraints that I won't get into, I have to create a self-extracting ZIP archive on a linux box. The resulting archive should be executable on Windows only. Is this at all possible? If so, what tools would do the job?
Background: when the user downloads a setup package from my linux box, I need that setup package to be pre-populated with a certain key. I only know that key at runtime; my idea was to write a simple .xml file with that key, then zip up the .msi installer with that xml file into a self-extracting archive, and send that file to the browser. If you have alternative ideas on how to make it happen, I'd love to hear those, too
Your answer can be found at the following page: http://ubuntuforums.org/showthread.php?t=847329 Please note that I do not take credit for anything other than using Google and finding something that sounds logically like it would work. I do not guarantee that this information will work, or that you will be able to find the mentioned materials online anymore. I'm just a fan of Google. I hope this helps.
The problem A few days back I had to
create a Win32 compatible
self-extracting ZIP file for a friend.
Sounds easy, right. The problem was
that I didn't have a Windows machine
nearby and I didn't want to install
any archiving programs under Wine.
NOTE: A freeware ZIP program such as
IZArc under Wine can be used to create
a Win32 self-extracting ZIP file too.
That will not be covered by this
howto, sorry.
The "research" Googling around I found
this forum post dated August 2003.
Reading it I found out that
self-extracting ZIP files are nothing
more but a suitable unzip binary
followed by a normal ZIP file. I used
the unzipsfx.exe included in Info-ZIP
UnZip 5.52.
The link on that post worked a few
days ago so I got my hands on the
unzipsfx.exe that I was looking for.
Today, 2nd July 2008 I found the link
dead. After some googling I didn't
find a working link anywhere. I read
the licence a few times and understood
that I can redistribute the original
unzipsfx.exe with a license included.
Please note that the
unzipsfx-552_win32.tar.gz (80 kB) is
not an official Info-ZIP package and
it includes copyrighted software that
I take no credit for. More info in the
Info-ZIP license that is also included
in the tarball. The source code for
the binaries included can be found
here.
The solution
Step one, getting the unzipsfx.exe and
zip package:
* open the Terminal (in Ubuntu press alt+f2 and type gnome-terminal)
* type in the following commands Code:
wget
http://kolmoskone.homelinux.org/~kaja/kamaa/unzipsfx-552_win32.tar.gz
tar zxf unzipsfx-552_win32.tar.gz sudo
apt-get install zip
Step two, creating a ZIP file in
Ubuntu:
* open the file manager (nautilus) and select the files you want to have
zipped
* right click and select Create an archive (or similar). Select a
location for the ZIP file, using your
home directory is the easiest. Select
type .zip. See man zip for information
on how to create a ZIP file in command
line.
Step three, making the ZIP file
self-extracting
* type in the following commands Code:
cat unzipsfx-552_win32/unzipsfx.exe
MYZIPFILE.zip > mysfxfile.exe zip -A
mysfxfile.exe
mysfxfile.exe can now be opened in any
Win32 compatible system (including for
example Windows XP/2000/Vista and even
Wine in Linux) or ANY ZIP COMPATIBLE
archive program such as file-roller in
Ubuntu.
I was able to make this work with unzipsfx. There's a newer version of it available - just came out in April 2009 - version 6.0. Version 5.52 didn't support the critical functionality that I needed - launching a particular setup file after the extraction is completed.
So I downloaded the source files for 6.0. I then modified them to exclude the "prompt to launch stuff" check that is there by default. I recompiled using Visual Studio 2008, tried the steps described in the tutorial above, and it all works like a charm now.
Related
In the past, Ghostscript used to incorporate these Apple Imagewriter devices: iwhi, iwlo, and iwlq. The version I had been using is gs 8.7 which is not 64-bit compliant. macOS Catalina cannot use it or any other 32 bit code, so printing to those devices fails.
More recent versions including the most recent Ghostscript 9.27 omit those devices. I don't know when they were omitted or why but it seems to be a while ago. Worse, I don't know how they get incorporated in Ghostscript. Other than building gs from its source code, which I have done, I don't know where to begin. The new Ghostscript 9.27 itself works fine in macOS Catalina. It includes many "built-in" devices but the ImageWriter devices I need are absent.
The drivers and Ghostscript were originally obtained from the Linux Foundation's Open Printing website: https://openprinting.org/printer/Apple/Apple-ImageWriter_II, but they were bundled and distributed in a package form that recent macOS versions cannot handle. That web page also indicates the drivers are "Type: Ghostscript built-in" which it no longer is in recent versions.
Here is gs -h using the installed 32 bit version:
GPL Ghostscript 8.71 (2010-02-10)
Copyright (C) 2010 Artifex Software, Inc. All rights reserved.
Usage: gs [switches] [file1.ps file2.ps ...]
Most frequently used switches: (you can use # in place of =)
-dNOPAUSE no pause after page | -q `quiet', fewer messages
-g<width>x<height> page size in pixels | -r<res> pixels/inch resolution
-sDEVICE=<devname> select device | -dBATCH exit after last file
-sOutputFile=<file> select output file: - for stdout, |command for pipe,
embed %d or %ld for page #
Input formats: PostScript PostScriptLevel1 PostScriptLevel2 PostScriptLevel3 PDF
Default output device: bbox
Available devices:
alc1900 <snip> inferno iwhi iwlo iwlq jetp3852 jj100 <many other devices> <snip>
Search path:
. : %rom%Resource/Init/ : %rom%lib/ :
/usr/local/share/ghostscript/8.71/Resource/Init :
/usr/local/share/ghostscript/8.71/lib :
/usr/local/share/ghostscript/8.71/Resource/Font :
/usr/local/share/ghostscript/fonts :
/usr/local/share/fonts/default/ghostscript :
/usr/local/share/fonts/default/Type1 :
/usr/local/share/fonts/default/TrueType : /usr/lib/DPS/outline/base :
/usr/openwin/lib/X11/fonts/Type1 : /usr/openwin/lib/X11/fonts/TrueType :
/usr/share/cups/fonts
Initialization files are compiled into the executable.
For more information, see /usr/local/share/ghostscript/8.71/doc/Use.htm.
Please report bugs to bugs.ghostscript.com.
iMac4:ghostscript-9.27 john$
The obvious sticking point is right there in front of me: "Initialization files are compiled into the executable." I know that, but what initialization files (if any) need to be included or modified to ensure their incorporation in the build? I have printer PPDs for the ImageWriter. They're just text files, and I think they would be required. Should they? How?
The only way I have attempted to build gs from source is to use ./configure followed by make That begins a long compilation process that takes a few minutes, and results in an executable gs that works fine in Catalina. The problem is it does not include the drivers I want. Attempting to print to that printer results in it printing "Unknown device: iwhi" in straight ASCII text (not bitmapped).
By now it ought to be painfully obvious I'm well over my head and don't know where to turn. Can anyone point me in the right direction from here?
Some background can be found here: Apple ImageWriter printer installation in… - Apple Community
. I wrote it. Some of its links are dead. If a picture doesn't load and you want to see it, click on it (it's a site problem).
A recent Discussion describing this dilemma is here: 32-bit ghostscript, required for ImageWriter and other printers using CUPS
The devices quoted were removed in this commit If you need them then you should be able to :
Clone our git repository, help on this is here
git checkout a87e380acd5e326f7d4e4380348bac393fac3058
copy the ghostpdl/devices/gdevadmp.c file somewhere convenient
git checkout master (or if you want a tagged release rather than the bleeding-edge code, git checkout ghostpdl-9.27 for example)
copy the saved file back to ghostpdl/devices/gdevadmp.c
Undo the changes in contrib.mak, configure.ac and unix-gcc.mak
(using the link to the gitweb you can see the diffs, they are not
extensive)
In the ghostpdl directory: ./autogen.sh then make
That all assumes you have a working C compiler (gcc, make etc) and development environment, but you say you've already built GS from source so that should be fine. The end result should be a woking Ghostscript with the additional device built in.
This:
Initialization files are compiled into the executable.
refers to the PostScript initialisation files, and won't help you with devices which are written in C and have to be compiled. While the line above is technically correct, you can use the -I switch to override the ROM file syatem (which is what that refers to) and have the initialisation files stored on disk instead.
PPD files aren't going to help you with Ghostscript, these are PostScript Printer Description files and they are used by applications which generate PostScript to customise the PostScript program for the specific printer. These are (I think) used by CUPS, but not by Ghostscript.
I think THIS is the commit to remove gdevadmp.
I think this was removed in a flurry of activity removing stuff referred to as "moribund" MacOS and classic Mac stuff, and I think this specific removal was unwarranted and unwise, as these drivers are still in use today Using foomatic-rip:
http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=a87e380acd5e326f7d4e4380348bac393fac3058
I am another Mac User and ImageWriter and ImageWriterLQ owner, I do not speak for Artifex.
at version 9.05, the file gdevadmp containing appledmp, iwhi, and iwlo, and iwlq was MOVED into the 'devices' folder. It survived there until version 9.20.
After version 9.20 it was removed in an operation that included only gdevadmp and its supporting files. The note does not say WHY it was removed.
So a 64-bit build of ghostscript 9.20 has some potential.
The files available at:
https://wiki.linuxfoundation.org/openprinting/macosx/foomatic#ghostscript_for_mac_os_x_103x_panther_-_mac_os_x_109x_mavericks
are still good, but gs and the filters need to be moved to a directory that remains accessible after the lockdown of sandboxing (about Mavericks) Suggested directory is noted in the apple support community discussion you posted earlier.
Links on the Ghostscript web site say that THIS (StackOverflow) is the official forum for discussing issues related to Ghostscript.
If that is not appropriate, what do Artifex and Ghostscript developers suggest is the "official" forum for Ghostscript issues?
I stumbled across this thread while working on a shelter-in-place project to resurrect my ImageWriter II by building Ghostscript and cups-filters for Catalina. My solution isn’t quite there yet; I can get 75% of the CUPS printer test page printed before silently crashing.
The solution for defeating sandboxing is to compile Ghostscript with dynamic linking disabled. Otherwise, even if you move the gs executable into a sandbox blessed location, the gs process will get killed as soon as it tries to link in the drivers. From my notes:
Download Ghostscript 9.20, the last gs with the Apple dot matrix drivers: https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/tag/gs920
Build Ghostscript with the drivers statically linked in (otherwise sandboxing gets you): ./configure --disable-dbus --disable-dynamic --disable-gtk --with-drivers=APPLE,PS --prefix=/usr/local/ghostscript-9.20
I have not yet tried to forward-port the iwhi drivers and such into the Ghostscript; that’s my next task, in the hope that it fixes the silent crash.
I need some help, I have some .hlp files and I want to convert it to .chm files, as .hlp files don't run on Windows 10.
How can I do that?
I see two or more solutions depending on your requirements:
Converting WinHelp (HLP) to HTMLHelp (CHM) or PDF
Running WinHelp files on Windows10
Convert WinHelp (HLP) to HTMLHelp (CHM):
A tutorial on my site gives a step-by-step description how to convert WinHelp (HLP) to HTMLHelp (CHM) on a freeware/shareware and "low budget" level. The conversion project example from the download section includes a working structure and example files.
You can of course use a helpauthoring tool (HAT) like Help+Manual, HelpScribble or any other HAT to convert existing WinHelp projects to HTMLHelp.
Run WinHelp on Windows 10:
WinHlp32 for Windows 10 restores the ability to open and view .hlp files on Windows 10.
WinHlp32 for Windows 10 6.3.9600.16411 (MajorGeeks) OR
see further information and the man's way below.
The WinHelp (.hlp) format has been around since the very early 1990s and is superseded by HTML Help 1.x (.chm). Microsoft strongly advise you move away from WinHelp about ten years ago. But for a test application it's running on my Windows10 machine like a charm.
But some heavy steps to fix the bygone WinHelp Viewer. Please note I don't speak of the HTMLHelp Viewer for *.chm help files here.
Following the solution steps depends on your Windows 10 Version (32 bit or 64 bit). To find out your system type (32 bit or 64 bit), Hold the Windows+R. Type msinfo32 in the Run dialog box that appears and Press Enter.
You know, trying to open a help file (*.hlp) results on a Microsoft Support page.Error opening Help in Windows-based programs: "Feature not included" or "Help not supported".
You'll find a download link for Windows 8.1 but you have to install in a special way for Windows 10 (Windows8.1-KB917607-x64.msu).
Start your command prompt as Administrator (Please NOTE - samples for German here)!
Extract the downloaded .msu file to a temp directory
md msu-extracted
expand Windows8.1-KB917607-x64.msu /f:* .\msu-extracted
Extract the contained CAB-File with 279 files in it.
cd msu-extracted
md cab-extracted
expand Windows8.1-KB917607-x64.cab /f:* .\cab-extracted
Depending on your language settings locate the matching MUI-File e.g. use "cs-", “de-” or "en-". People using the x86 variant need to run “dir x86de-.”
cd cab-extracted
Navigate to the given path for your language "... de-de ..." e.g.:
cd amd64_microsoft-windows-winhstb.resources_31bf3856ad364e35_6.3.9600.20470_de-de_1ab8cd412c1028d0
Here we'll find “winhlp32.exe.mui”. Now we need to replace e.g.
%SystemRoot%\de-de\winhlp32.exe.mui with our new file:
takeown /f "%SystemRoot%\de-de\winhlp32.exe.mui"
icacls "%SystemRoot%\de-de\winhlp32.exe.mui" /grant "%UserName%":f
ren %SystemRoot%\de-de\winhlp32.exe.mui winhlp32.exe.mui.w10
copy winhlp32.exe.mui %SystemRoot%\de-de\winhlp32.exe.mui
takeown /f "%SystemRoot%\winhlp32.exe"
icacls "%SystemRoot%\winhlp32.exe" /grant "%UserName%":f
ren %SystemRoot%\winhlp32.exe winhlp32.exe.w10
cd ..
dir *.exe /s
Find the right path starting either with amd64 or x86 and navigate
to it:
cd "amd64_microsoft-windows-winhstb_31bf3856ad364e35_6.3.9600.20470_none_1a54d9f2f676f6c2"
copy winhlp32.exe %SystemRoot%\winhlp32.exe
Edit:
You don't need to replace _none_ in the last cd command step (all single steps tested 2017-09-01 and 2018-08-24 and working on Windows 10).
There is a reset of the workaround described above after a main Microsoft Windows update.
Edit: (copied form comments, thanks to #dxiv)
An alternative to the last couple of steps is to copy the winHlp32 files entirely elsewhere, like C:\etc[\de-de], then re-associate ftype hlpfile=C:\etc\winHlp32 %1 at an elevated command prompt. This avoids clashes with sfc and future windows updates, and HLPs would still work when opened by association (double-click in explorer, or start old.hlp at the cmd prompt).
You can convert HLP to HTML, using a Chrome extension:
<< CHM, HLP Viewer and Extractor >>
Proposed by : https://ehubsoft.herokuapp.com/chmviewer
Well people, after a long time searching, my conclusion was: .HLP files can't be executed by Windows 8 and 10, just in Windows 7 and lower. .CHM files can be executed by Windows 8 and windows 10. SO, I had to create my new .chm file in Help Development Studio on Windows 10 to be executed by it. My old files .HLP became obsolete. It took so much time to do this but I learned so much about this type of files.
Finally, thank you for your contribution to my question.
You are a hero sir! I ended up using HelpScribble and using its Decompiler linked here.
Quoting their website:
If you have an existing WinHelp file without the HPJ and RTF source files, you can download the WinHelp decompiler to recreate the HPJ and RTF sources from the HLP file. Extract the files inside helpdc21.zip into a new folder. Then you can easily decompile any .hlp file from the command prompt, by typing: helpdeco helpfile.hlp where helpfile.hlp is the help file you want to decompile. The decompiler will generate the HPJ and RTF files, along with a series of bitmap files if the help file contains images. Use Project|Import Help Project in HelpScribble to import the help file.
That will extract the source files for the hlp file.
Lastly, simply import the resulting hpj file in HelpScribble. From there you can simply export to a html file with the option Make Flat Manual.
Boom. Done.
I've been searching all day for a solution to unzip a file with AutoIt Script. I would like to unzip a file called full.zip to a folder.
This is my last place to turn since I can't find a solution of my own. I have found many solutions made by others; AutoIt3 files containing functions, but the code has issues of which I do not understand, and I'm unable to them copy here because I'm using a screen reader and it doesn't seem to format properly. This is why I can not copy code here.
Does anyone know of a method, tutorial or resource that I can use to unzip a file with AutoIt?
Thanks for any help,
josh.
There are a lot of solutions people have coded. A few examples are the 7zip UDF, Zip.au3, zipfldr UDF. If those are not working for you it is most likely because of small changes to AutoIt, which is usually just #incudes being restructured.
I usually just keep 7za.exe (7-zip's standalone executable, 7-zip can be downloaded from here, and then after installing you can copy the 7za.exe from its program directory).
Then it becomes as simple as a call to RunWait to create the archive:
RunWait("7za.exe a MyNewArchive.zip file1.ext file2.ext ...")
And then to unzip:
RunWait('7za.exe x MyArchive.zip -o"Path\To\MyOutputFolder"')
The 7-zip FAQ also mentions that you can use this exe in your own applications (including commercial ones) provided you mention it in the documentation and provide a link. That means you are ok to use FileInstall(...) to include 7za.exe in the compiled .exe.
I write project where I need to identify certain file formats.
For some formats I have found signatures that I use for identifying easily (mp3, ogg), with another formats I have a big problem (like MPEG ADTS) - I just cannot find what kind of signature can be used for it.
I found out that File utility for Linux environment can do it.
I tried to search it in source code, but I've found nothing.
I found that file utility holds its database in magic.mgc file. But it's hold in binary form.
It looks like:
Does someone perhaps know how to find that database in plain text format?
That utility isn't a Linux-specific utility; it's the version of the UN*X file command originally written by Ian Darwin. The binary .mgc file is generated from a bunch of source files.
Your Linux distribution probably has a source code package for it; where you get that package, and how you install it, depends on which distribution you're using.
The source files from which the .mgc file was generated might also be available on your distribution without installing the source package for file; if so, you could use the file command to generate it, using the -C flag. I don't see them anywhere obvious on my Ubuntu 12.04 virtual machine, so that might require some other package to be installed (file itself is installed). (On OS X, they're in the directory /usr/share/file/magic.)
Alternatively, you could download the standard version of that file (which might have been modified by your distribution, so you might not want that version) and modify and build it.
Note that, on some versions of UN*X systems, the bulk of the work done by the file command is done in library routines in the "libmagic" library; see whether your distribution has that or can install it (try, for example, man libmagic) and whether it can do the job for you.
I am having problem with implementing LibSVM to MATLAB.
I am using MATLAB R2009a (I also have the latest version, R2012b, but I dont use that one)
I downloaded LibSVM package, libsvm-3.14 to my Windows 7 PC, which MATLAB and OCTAVE interface come together.
I extracted the folder I downloaded. Which, below, you can see the printscreen of what the folder has in.
Where should I put my libsvm-3.14 extracted folder ? Should I put it under "bin" folder of my MATLAB installed in the directory?
C:\Program Files\MATLAB\R2009a\bin
I did that, however, it didn't work out. I will be grateful if you help me clearly. I just read README file, but it's not clear to understand and there is no other instructions online on the internet.
For the time being, it does not matter where you put that folder. You'll have to compile the Matlab-MEX files, from the source code that resides in the matlab subfolder of your extracted libsvm package.
Below, I will call the libsvm-3.14 (for example: C:\libsvm-3.14) extracted folder ROOT (so replace ROOT wilth C:\libsvm-3.14 below).
So, fire up Matlab and, then, at its command prompt, type:
cd ROOT
cd matlab
make
Now, in the ROOT/matlab folder, you should have obtained two MEX files (with the .mexw32 or .mexw64 extension). These are the files that you will use from now on. You can discard the rest, except those files (and, maybe, some other generated libraries).
According to the Makefile (that is ROOT/matlab/make.m), the MEX files are called svmtrain and svmpredic (+ the extension).
So, next step would be to create a subfolder called libsvm/ under your's Matlab/toolbox folder, copy the two MEX files therein and, then, add that libsvm/ folder to the Matlab Path (not the Path of your system, but of your Matlab installation).
Then, by typing:
svmtrain
and
svmpredict
you should have the help (usage) of these two functions.
With the aid of #axeoth, here is the solution. I followed instruction files in matlab subfolder of extracted libsvm package. I downloaded and installed Microsoft Visual Studio 2010 and wrote 'mex -setup' on command window of MATLAB to choose a suitable compiler for mex (I use MATLAB R2012b in 32-bit PC, so I found supported compilers in this link http://www.mathworks.com/support/compilers/R2012b/win64.html) After then, I followed #axeoth's instructions. I changed the name of the folder to ROOT and moved it to Documents/MATLAB. I started MATLAB and on command window, I wrote these below "one by one"
>> cd C:\Users\HUstat\Documents\MATLAB\ROOT\matlab
>> cd matlab
>> make
then I copied everything obtained in ROOT/matlab subfolder. I created a new folder named libsvm under MATLAB/toolbox folder and pasted everything there. and then, I added that libsvm/ folder to the Matlab Path by using "Set Path" button on MATLAB R2012b. After then I wrote "svmtrain" and "svmpredict" so I got the helps of these two commands.
For those having major compiler problems I thought I'd leave some extra information on the subject of installing compilers. This was a frustrating problem I had an ended up contacted MATLAB for help. I would have commented in the above posts but I do not have enough "rep" so here it is:
I was unable to install Microsoft Windows SDK 7.1, whether via Microsoft Visual Studio 2010 or otherwise. I found out that this was because I had a certain version of Microsoft Visual installed (version 10.0.04... was the cause of the problem for me). The work around was to uninstall Visual, install SDK 7.1 independently and then re-install Visual after. The process is written up in greater detail in the link below:
http://www.mathworks.com/matlabcentral/answers/95039-why-does-the-sdk-7-1-installation-fail-with-an-installation-failed-message-on-my-windows-system
It may also be that you have the compiler installed but that it wasn't recognised until MATLAB "found" it. This happened to me after the re-install. To check if you have the correct compiler and "find" it run mex.getCompilerConfigurations('Any','Installed') to get a full list. Then do mex -setup using the SDK 7.1 choosing the C/C++ version over FORTRAN.
I know the question is answered already but hopefully this may help someone the same predicament I had.