Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: orange on October 02, 2015, 12:44:11 PM
-
Is there a way to extract graphics.library version 37 from ROM ?
-
Is there a way to extract graphics.library version 37 from ROM ?
That depends upon how you are intending to use it. Figuring out where the module starts and where it ends is not that hard (well, I can look it up in certain build protocol files, so that's probably not a fair assessment). Extracting and relocating it would be the difficult bit.
Are you sure you want V37? That's in Kickstart 2.04, not in Kickstart 1.3 (V34).
-
That depends upon how you are intending to use it. Figuring out where the module starts and where it ends is not that hard (well, I can look it up in certain build protocol files, so that's probably not a fair assessment). Extracting and relocating it would be the difficult bit.
Are you sure you want V37? That's in Kickstart 2.04, not in Kickstart 1.3 (V34).
I see. Thanks. Yes, I'd like v37, didn't know where it was, sorry.
I'm trying to run lha (almost any version) in vamos, linux. For some reason, lha seems to need that library. Older lha nedds arp.library (found it) and older graphics.library.
here is output from ./vamos lha_68k:
14:19:32.326 path:WARNING: ami_command_to_sys_path: ami_path='libs:utility.library' not found!
14:19:32.333 path:WARNING: ami_command_to_sys_path: ami_path='libs:intuition.library' not found!
14:19:32.338 path:WARNING: ami_command_to_sys_path: ami_path='libs:graphics.library' not found!
14:19:32.338 libmgr: ERROR: [create_lib] can't create auto lib without FD file: graphics.library
14:19:32.339 path:WARNING: ami_command_to_sys_path: ami_path='PROGDIR:graphics.library' not found!
14:19:32.340 libmgr: ERROR: [create_lib] can't create auto lib without FD file: graphics.library
Cannot open "graphics.library", version 37.
-
Besides... Just by extracting it you do gain not much. Graphics is a rather weird mixture of C and assembly code, and the latter makes heavy use of macros.
-
Besides... Just by extracting it you do gain not much. Graphics is a rather weird mixture of C and assembly code, and the latter makes heavy use of macros.
so, is there no way to run Amiga lha in vamos?
-
so, is there no way to run Amiga lha in vamos?
lha is a command line program. It does not require graphics. It requires the interface to the console. Thus, it will just read and write arguments the standard way, and in addition, uses a bit GetDeviceProc() to play with the console. No gfx there.
Unless you're talking about some other lha than what I'm thinking about...
-
lha is a command line program. It does not require graphics. It requires the interface to the console. Thus, it will just read and write arguments the standard way, and in addition, uses a bit GetDeviceProc() to play with the console. No gfx there.
Unless you're talking about some other lha than what I'm thinking about...
Thanks. Perhaps its trying to open some requester window because of missing lib?
I'll try to get a list of used libs on real amiga.
-
Thanks. Perhaps its trying to open some requester window because of missing lib?
I'll try to get a list of used libs on real amiga.
Hard to say, I'm at the wrong end for reproducing this. I would actually believe it is really using some "less frequent" calls of the dos.library.
-
My guess is something else that lha is using is calling the gfx library for some reason. I wanted to play around with vamos myself, but I don't have time to figure out Python and specifically the c-Python bridge.
If only someone would port vamos to C ;-)
-
Vamos doesn't emulate all of the AmigaOS functionality that lha requires, and there's no way of just giving vamos a Kickstart ROM or AmigaOS libraries to make it work.
The original Unix lha doesn't know about Amiga-specific file flags, but other than that it works well enough to create and extract Amiga compatible archives. If you have GCC and GNU Make installed, then you can build lha by just running "./configure" and "make":
https://osdn.jp/projects/lha/releases/22231
-
graphics.library_37.41
https://goo.gl/UH2lrC
:)
-
@Leffmann
thanks, but I need Amiga version of lha (long story), does anyone have a source code of it?
-
lha Amiga version is on aminet.. but without the source code..
edit : if you're missing any library : Amiga Libraries FTP : http://amiga.foul.fr/ ;)
-
@Leffmann
thanks, but I need Amiga version of lha (long story), does anyone have a source code of it?
Take the Unix sources, recompile. Why is that a problem?
-
Take the Unix sources, recompile. Why is that a problem?
problem is, Unix version doesn't seem to produce the identical output and its missing some options. compressed size is slightly different with some files.
-
problem is, Unix version doesn't seem to produce the identical output and its missing some options. compressed size is slightly different with some files
Could you provide some context as to why this is a show-stopper for you?
As far as I know the "original" LhA (MS-DOS) and the Unix version evolved on different paths. The Amiga version is more closely related to the original version, hence the difference in performance and output.
If I remember correctly, the Unix version stores more information in the file headers than the original MS-DOS version, and it supports compression methods which were not available at the time when the Amiga version was created.
-
problem is, Unix version doesn't seem to produce the identical output and its missing some options. compressed size is slightly different with some files.
Why is that a problem? As soon as the output is compatible and can be read by both versions, everything is fine.
-
I'm trying to re-pack all the lha archives with zero compression, using a script. So that they can be better packed with 7z solid. But, I'd like to keep all the metadata, and find good compress algorithm, to recreate original identical archive one day, if need be.
-
I'm trying to re-pack all the lha archives with zero compression, using a script. So that they can be better packed with 7z solid. But, I'd like to keep all the metadata, and find good compress algorithm, to recreate original identical archive one day, if need be.
For the unix command line, "lha az output.lha input" does that.
-
For the unix command line, "lha az output.lha input" does that.
thanks, but, if you delete input file how can you re-create it from output.lha in unix?
-
thanks, but, if you delete input file how can you re-create it from output.lha in unix?
Same as under AmigaOs of course. "lha x input.lha"
-
I'm trying to re-pack all the lha archives with zero compression, using a script. So that they can be better packed with 7z solid. But, I'd like to keep all the metadata, and find good compress algorithm, to recreate original identical archive one day, if need be.
If I understand you correctly you are using LhA to create archives which preserve the contents and the Amiga-specific metadata (comment, protection flags, owner ID and group ID), so that these may be restored properly when the archive is unpacked.
Is there any other reason for using LhA in this context? I am asking because you might get the same effect (Amiga-specific metadata being preserved) if you use the "zip" command. When "zip" was still under active development as "PKZIP" in the late 1980'ies "AmigaOS" was a well-supported platform.
If I remember correctly, the "zip" archive format preserves Amiga-specific metadata. I'll have to check first, though.
-
If I understand you correctly you are using LhA to create archives which preserve the contents and the Amiga-specific metadata (comment, protection flags, owner ID and group ID), so that these may be restored properly when the archive is unpacked.
Is there any other reason for using LhA in this context? I am asking because you might get the same effect (Amiga-specific metadata being preserved) if you use the "zip" command. When "zip" was still under active development as "PKZIP" in the late 1980'ies "AmigaOS" was a well-supported platform.
If I remember correctly, the "zip" archive format preserves Amiga-specific metadata. I'll have to check first, though.
well I prefer LhA. I'm creating uncompressed lha (-lh0-). Metadata (headers) are kept in a special small file. I'd like to write a script that can later re-create identical compressed .lha, without having to use real Amiga or UAE. Problem is not in metadata, but compressed data.
-
well I prefer LhA. I'm creating uncompressed lha (-lh0-). Metadata (headers) are kept in a special small file. I'd like to write a script that can later re-create identical compressed .lha, without having to use real Amiga or UAE. Problem is not in metadata, but compressed data.
You can tell "zip" not to compress the files ("zip -0 archive.zip file1 file2 ..."), which would give you in about the same functionality as with LhA. The source code to zip is available, there is at least one Amiga port which is fully compatible with the open source version and which is not 20 years old.
Even if you prefer LhA, by now it seems inevitable that you will not be able to perfectly reproduce the archive file format.
So maybe zip would not be such a bad alternative after all.
-
7-Zip can handle lha archive too ;)
a simple :
7z x archive.lha
do the job...