Broken pre-System 7 disk I/O

[autc04]

Broken pre-System 7 disk I/O

[autc04]

Surprising.
There is a test case in AutomatedTests/StdIO.c which does exactly that, and which I have successfully run on minivmac + System 6 more than once. Is there anything else different about your program?

StdIO.c contains:

#include <stdio.h>

int main()
{
    FILE *f = fopen("out", "w");
    fprintf(f, "OK\n");
    fclose(f);
}

[ryandesign]

BTW, the call to SFPutFile shouldn't center the dialog? It is the case with System 7 but not with System 6.

System 7 contains automatic dialog centering routines that can be chosen by the application programmer if desired. System 6 and earlier never did; it is up to the application programmer to specify dialog positions, including performing any math to compute the centering. (That's your where parameter to SFPutFile.)

[autc04]

That's true. There should be a check for the system version there (protected by an #ifdef for 68K, as PowerPC always implies at least System 7).
Not sure if a check for the initial period is necessary - was the behavior for HOpen to always fail on dotfiles, or just to open a driver if one existed by that name? We might as well call HOpen on System 6 and ignore the problem...

[craigbaker]

That sounds reasonable to me, you're right there's no need for the dot check.

I just tried writing to a filename .test.txt in 6.0.8 using fopen() and write() through Retro68 (modified to use HOpen) and it worked fine. TeachText also reads the file with no complaints, and it shows up in the Finder. Maybe you're right that it's only a problem when there's a conflicting INIT or something, but I don't have any on my system at the moment to try it.

By the way, is there an easy way to build and run the AutomatedTests?

[autc04]

To run the AutomatedTests, you need to set up LaunchAPPL to work with the emulators or real macs that you happen to have. It's documented in the README, but so far only the minivmac route is reasonably simple and does not depend on having the right hardware. If you run into trouble, just ask, and if you have any suggestions for other options to add to LaunchAPPL, tell me.

If you can open .test.txt, this means that the forbidden file names are really only the DRVRs in the ROM, in the system file (and probably in INITs). In my system file, I can see .AppleSoundInput, .Print, .XPP, .AFPTranslator and .Display_Video_Apple_TFB, and I seem to remember that the ROM has at least .Sony (floppy disk), .Sound, and some things for the serial ports. I'd say it's safe to cut corners here.

[craigbaker]

Confirmed in ResEdit that my System's DRVR contains .AppleSoundInput; attempting to open .AppleSoundInput for reading with HOpen returns -21, badUnitErr. Renaming a file to this in the Finder works fine, but then opening it in TeachText results in the system hanging. I guess they weren't very careful with error checking.

The Apple Technical Note below suggests a way of handling multiple system versions:

Technical Note TN1041:
"If the HOpenDF or PBHOpenDF function fail with a paramErr result code (indicating that the HOpenDF or PBHOpenDF function is not available), you should retry your request passing the same parameters to HOpen or PBHOpen. For example:"

    error = HOpenDF(vRefNum, dirID, fileName, permission, &refNum);
    if ( error == paramErr )
    {
        /* HOpenDF not supported, so try HOpen */
        error = HOpen(vRefNum, dirID, fileName, permission, &refNum);
    }

I can confirm that my system does always return paramErr (-50) from HOpenDF as described.

Thanks for the note about AutomatedTests, don't know how I missed that.

[autc04]

Sounds like a plan.

[DarwinNE]

Hello,
I'm trying to compile a piece of code that is supposed to run on System 6 Macs.
I noticed that this code hangs the machine (but works perfectly on System 7):

    FILE *f=fopen("test","w");
    fprintf(f,"test");
    fclose(f);

(reading on a file seems to work)

In my understanding, libretro/syscalls.c still employs HOpenDF without checking if System 7 is running. If I understand correctly the process, when run on System 6 machines, the code should not at all call HOpenDF as it is not available and would crash the system.

Cheers,
D.

EDIT: after further investigation, it seems that the application crashes not when the file is opened, but when the first write operation is done (i.e. on the fprintf command). It is probably something different from the call to HOpenDF that generates the issue.

[DarwinNE]

I just compiled StdIO.c and it works!
Mine is a larger program, of course, the only difference I can see is that I let the user choose where the file must be placed with

I think I can reproduce the issue with this code. Maybe it's an error I am doing, but it works very well on Basilisk and System 7 and hangs vMac with System 6.0.6.

#include <Events.h>
#include <Quickdraw.h>

#include <stdio.h>
#include <string.h>

char fname[255];

int main()
{
    WindowPtr theWindow;
    Rect windowRect;
    EventRecord eventRec;
    InitGraf (&qd.thePort);
    InitWindows ();
    InitFonts ();
    InitCursor ();
    FlushEvents (everyEvent, 0);

    SFReply reply;

    Point where = (Point){-1,-1};
    
    SFPutFile(where, "\p", "\p", NULL, &reply);
    
    if(reply.good) {
        SetVol("\p", reply.vRefNum);
        strncpy(fname, &reply.fName[1], (int) reply.fName[0]);
        fname[reply.fName[0]]='\0';
        FILE *f = fopen(fname, "w");
        fprintf(f, "OK\n");
        fclose(f);
    }
}

It worked once, when I overwrote a file already present on the disk image. If I erase the fprintf command, the file is created as expected.

BTW, the call to SFPutFile shouldn't center the dialog? It is the case with System 7 but not with System 6.