fadden / nulib2 Goto Github PK

Hi there,

Please, forgive my ignorance. Is nulib2 an improvement over this johnsonjh/nulib? I believe you have developed both, right?

Since most of files has a copyright notice like this:

/*
 * nublu.h - declarations for nublu.c
 *
 * NuLib v3.2  March 1992  Freeware (distribute, don't sell)
 * By Andy McFadden ([email protected])
 */

nulib development stopped in version NuLib v3.24 (January 1993) then you started nulib2?

I read your website (nulib.com) and I liked the historical information. I just want to know about the relationship between this repository and the one linked above (v3.24)

I think as of 3.1.0a1, if you use nulib2 -x SHRINKIT.SDK, it now says "expanding SHRINKIT" and then "extracting SHRINKIT", and the latter file, which is zero-length, overwrites the former. Does not occur in 3.0.0.

If you use -e, then you get both the disk image file ending in "i", and a zero-length file with just the file name. I think this latter empty file was being skipped before, but now it's being extracted, and with the same name as the real thing, overwriting it.

Perhaps it's a result of more widespread Miranda threads or something.

Silly question: On Linux is there a command line incantation that would take a ShrinkIt archive and extract it into a disk image format suitable for loading into an emulator? It looks like nulib2 has the tools, but in reviewing documentation I don't see a clear example of how to accomplish something like this (imgconv is giving me an error that indicates it only works if the original files were part of a disk image... and even then only applies to SHK files).

(From Hugh Hood, via comp.sys.apple2.)

The file type conversion implementation is incomplete. A table on page 336 of the Programmer Reference for System 6.0 lists the conversions.

ProDOS to Macintosh conversion:

   ProDOS              Macintosh 
File     Auxiliary    Creator File 

$00       $0000       “pdos” “BINA” 
$04 (TXT) $0000       “pdos” “TEXT” 
$FF (SYS) (any)       “pdos” “PSYS” 
$B3 (S16) $Dbyz       “pdos”  “p” $B3 $DB $yz 
$B3 (S16) (any)       “pdos” “PS16” 
$D7       $0000       “pdos” “MIDI” 
$D8       $0000       “pdos” “AIFF” 
$D8       $0001       “pdos” “AIFC” 
$E0       $0005       “dCpy” “dImg” 
$FF (SYS) (any)       “pdos” “PSYS” 
$uv       $wxyz       “pdos” “p” $uv $wx $yz 


Macintosh to ProDOS conversion: 

 Macintosh              ProDOS 
Creator File            File      Auxiliary 
“pdos” “PSYS”           $FF (SYS) $0000 
“pdos” “PS16”           $B3 (S16) $0000 
“pdos” “XY∆∆”†          $XY       $0000 
“pdos” “p” $uv $wx $yz  $uv       $wxyz 
“dCpy” “dImg”           $E0       $0005 
(any) “BINA”            $00       $0000 
(any) “TEXT”            $04 (TXT) $0000 
(any) “MIDI”            $D7       $0000 
(any) “AIFF”            $D8       $0000 
(any) “AIFC”            $D8       $0001 
(any) (any)             $00       $0000 

† Where X,Y are hexadecimal digits (i.e. ‘0’-‘9’ or ‘A’-‘F’), and ∆ is a space.

The current algorithm handles pdos/PSYS, pdos/PS16, and pdos/p[uv][wx][yz], but not pdos/XY∆∆. The big problem is that instead of allowing any creator for BINA, TEXT, and so on, it uses an "else" clause that only handles them when the creator is not pdos.

The conversion from ProDOS to Mac file types always uses pdos/p[uv][wx][yz]. It might be more convenient to access the files on the Mac if we supported some of the other types, such as "pdos/TEXT" for text files with auxtype=$0000.

This would also be an opportunity to update gRecognizedExtensions to match CiderPress, which has a couple of additional entries (.text, .cpp).

Pi 400 64-bit (Manjaro, but probably same case for the default 64-bit Raspberry Pi Linux)

./configure doesn't know what to do with 'aarch64' platform. The configuration script (especially the config.guess) is pretty dense. Any tips for getting this script to do its magic?

On recent Mac OS we get this:

duplicate symbol _Nu_UpdateCRC16 in:
../libnufx.a(Entry.o)
../libnufx.a(Archive.o)
duplicate symbol _Nu_GetThread in:
../libnufx.a(Entry.o)
../libnufx.a(Archive.o)

This is probably due to the use of "extern inline", which used to tell gcc "don't generate an actual function", but in C99 means "make the generated function visible externally", i.e. the exact opposite.

Full details are at http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00119.html
Recommendations are at http://www.greenend.org.uk/rjk/tech/inline.html

The simplest thing to do is just make the two functions not be inline, since CRCing a few megabytes of data doesn't take as long as it used to.

Just to you know, your software was included in Debian repositories:
https://packages.debian.org/search?suite=default&section=all&arch=any&searchon=names&keywords=nulib2

sudo aptitude install nulib2 and include manual pages man nulib2 very cool

NuLib2 is single-threaded, and CiderPress only runs under windows, but ideally we'd wrap the interruptible I/O calls with TEMP_FAILURE_RETRY to prevent EINTR failures.

I fixed my local version to build in VS2015. I did not submit it since my C++ skills are somewhat limited and may a better way to address this.
btw: I ran into this issue while after pulling down the latest CiderPress which contains this lib.

Building in VS2015 works fine with the following change (aside from upgrading the project).

Project: nufxlib, File: SysDefs.h, Lines 70 and 71 are replaced by;

/*
Char27 2015-11-01 - Fix for MSC >= 1900 (Visual Studio 2015)
// # define snprintf _snprintf
// # define vsnprintf _vsnprintf
*/
#if _MSC_VER <= 1800 )
# define snprintf _snprintf
#endif
#if _MSC_VER <= 1800 )
# define vsnprintf _vsnprintf
#endif

Repro steps (Linux):

1. Get an archive with a locked forked file. For example:
   • Create a forked file using the file preservation extensions. You can do this by creating files called "ReadMe#505445" and "ReadMe#505445r". (You can also just extract a forked file from an archive with "nulib2 xe ...".)
   • "Lock" the files with "chmod 444 ReadMe*".
   • Create a new archive using "nulib2 ae foo.shk ReadMe*". The archive should have a single, forked entry.
2. In an empty directory, extract the archive with "nulib2 xe foo.shk". You should get two files, matching the originals.
3. In that same directory, extract the archive again.

NuLib2 will not overwrite the existing entry. This may or may not be considered a bug, as the existing file is "locked" and should not be casually overwritten. However, if NuLib2 is prompting the user for permission to overwrite, there's no reason not to continue if permission is given.

If you elect to rename the file, or not to extract it at all, NuLib2 will move on to the resource fork, which it will attempt to extract regardless of what you choose for the data fork, and without prompting for help when it encounters the existing file. It just fails. NuLib2 should rename or skip the resource fork according to the requested handling of the data fork. At the very least it should re-prompt for rename or skip when the resource fork extraction fails.

(reported by Ivan Drucker)

Given an extended file with a zero-length resource fork, GSHK will create an entry that doesn't have a data_thread for the resource fork, relying on the StorageType value to identify the file as extended. NufxLib has some code for dealing with "missing" fork data, but doesn't appear to handle this situation (even with MaskDataless=true).

Right now, your Makefile.in for nufxlib doesn't work for building a library. The reason is that while you include -shared when linking, the code to be linked has not been compiled with position independent code, and thus cannot be linked into a shared library. You're depending on a GNU make feature to compile object files, an implicit rule that looks something like this:

%.o: %.c
	$(CC) $(CPPFLAGS) $(CFLAGS) -c $@

The problem there is that nowhere in CFLAGS do you set anything to produce position-independent code (nor should you directly since CFLAGS also gets used for static library code.) With gcc (or clang in gcc emulation), -fPIC will always generate position-independent code, however within certain constraints you may be able to get smaller/faster code out of -fpic. I don't think anybody is producing hundred megabyte ShrinkIt archives, however, so it probably doesn't matter if the code's a little bigger to choose the compatible option.

Options for building both often include the use of object directories and name transformations so that you have one rule to build static objects without -fPIC and one to build shared objects with -fPIC, and you specify both rules to control which flags get used for which.