Print

[friedgold]

CODE

int handle;
NTSTATUS status;
OBJECT_ATTRIBUTES objectAttributes;
IO_STATUS_BLOCK ioStatusBlock;
objectAttributes.RootDirectory = NULL;
objectAttributes.Attributes = OBJ_CASE_INSENSITIVE;
objectAttributes.ObjectName = "\\Device\\CdRom0\\file.png";
status = NtCreateFile(
        &handle,
        GENERIC_READ,
        &objectAttributes,
        &ioStatusBlock,
        NULL,
        FILE_ATTRIBUTE_NORMAL,
        0,
        OPEN_EXISTING,
        0);

You can then read / write /close the file through the handle. I haven't tested the above code but it should work.

[avelino]

Thanks for the answer. I run the default.xbe in the CDROM and I put the "file.png" in the same root directory as default.xbe of the CDROM. I have tested "d:\file.png", "file.png", "d:/file.png" and "\Device\CdRom0\file.png" with the IMG_Load() function to load the file but in all cases the function returns NULL and the SDL_GetError() returns "Cannot open file" (I escape the backslash correctly in C with "\\").
I don't know what am I doing wrong! :-(

[friedgold]

QUOTE(avelino @ Sep 12 2006, 07:59 PM)

Thanks for the answer. I run the default.xbe in the CDROM and I put the "file.png" in the same root directory as default.xbe of the CDROM. I have tested "d:\file.png", "file.png", "d:/file.png" and "\Device\CdRom0\file.png" with the IMG_Load() function to load the file but in all cases the function returns NULL and the SDL_GetError() returns "Cannot open file" (I escape the backslash correctly in C with "\\").
I don't know what am I doing wrong! :-(

Hmmm... that should work. Does it work if both the XBE and the image file are in a subdirectory on the Xbox HDD? If it works on the HDD but not on the CDROM something rather strange is going on.

[d0wnlab]

This probably has to do with a problem I've been trying to address.  Right now when a user uses something like "d:/" in a file path, the OpenXDK layer does a static replace instead of asking the kernel where the d: is actually mounted.  I've been trying to research the kernel API to find out how to query the kernel for "what is the real path for mount point d:" but haven't figured it out yet.

Among other things, this prevents us from booting XBE's that are located in subdirectories below the currently running XBE.

[fghjj]

CODE

DWORD dwStatus;
    ULONG len;
    char buf[128];
    HANDLE hObject;
    UNICODE_STRING strLinkName = {0, sizeof(buf), &buf[0]};
    ANSI_STRING strDrive = {6, 7, "\\??\\D:"};
    OBJECT_ATTRIBUTES objectAttributes = {NULL, &strDrive, OBJ_OPENLINK};        

    dwStatus = NtOpenSymbolicLinkObject(&hObject, &objectAttributes);
    if (dwStatus == ERROR_SUCCESS) {
        dwStatus = NtQuerySymbolicLinkObject(hObject, &strLinkName, &len);
        if (dwStatus == ERROR_SUCCESS) {
            buf[len] = 0x0;
             //see buf
        }
        else {
             //NtQuerySymbolicLinkObject failed
        }
    } else {
         //NtOpenSymbolicLinkObject (invalid symlink)
    }

[friedgold]

CODE

ANSI_STRING a1, a2;
RtlInitAnsiString(&a1, "\\??\\D:");
RtlInitAnsiString(&a2, "\\Device\\CdRom0");
IoCreateSymbolicLink(&a1, &a2);

You would have thought this would mean the XBE would no longer run from the HDD. However this isn't the case. When running the XBE from the HDD the directory containing the XBE is mounted to D. Since an existing symbolic link is already set up the call to IoCreateSymbolicLink() silently fails leaving the correct path for D intact. So with the above code your XBE should work both from the DVD drive and the HDD.

[d0wnlab]

fghjj: Thanks.  Although you say "too ugly", I say "perfect for OpenXDK CVS"

friedgold: Good thinking!  I'll add that to OpenDash CVS when I get a chance.

[friedgold]

QUOTE(friedgold @ Sep 14 2006, 10:27 AM)

I've discovered that the path of the current XBE can be read from XeImageFileName. I think the best thing to do would be to change OpenXDK so the path from XeImageFileName is used to resolve relative paths.

This approach seems to work well so I've commited the necessary changes to CVS. You should now always be able to use relative paths to access files in the same directory.

The way paths are handled in OpenXDK could probably do with a few more changes. At the moment it's inconsistent. Paths beginning "d:" will repect where D is mapped to by the Xbox kernel but the partitions for other paths are hardcoded will not respect the Xbox kernel's mappings. There is currently no easy way to access files on the DVD drive if the XBE is running from the HDD.

I think it would be better if the necessary symbolic links were setup automatically by OpenXDK and all paths respected these links. This way people could continue to use the paths as they have been doing, with the option of remapping drives using the IoDeleteSymbolicLink() IoCreateSymbolicLink() if they wanted to. I also think it would be best if D was initially mapped to the DVD drive regardless of where the XBE is started from. The mapping of D to the current directory seems to be hack used get XBEs which expected to run from a DVD to run from the HDD. This isn't necessary for OpenXDK apps as we can resolve relative paths more reliably using XeImageFileName.

If using D for the current directory is too entrenched then we should decide upon a new drive letter for the DVD drive (H?) so XBEs run from the HDD can access files on the DVD drive. What do other people think?

[openxdkman]

Sounds good to me.
Don't hesitate to write long comments in source to explain it...

[d0wnlab]

QUOTE(friedgold @ Sep 14 2006, 06:18 AM)

I also think it would be best if D was initially mapped to the DVD drive regardless of where the XBE is started from. The mapping of D to the current directory seems to be hack used get XBEs which expected to run from a DVD to run from the HDD. This isn't necessary for OpenXDK apps as we can resolve relative paths more reliably using XeImageFileName.

If using D for the current directory is too entrenched then we should decide upon a new drive letter for the DVD drive (H?) so XBEs run from the HDD can access files on the DVD drive. What do other people think?

I think setting up a new symbolic link (mapped to a new letter) for the DVD drive would be the best.  My reasoning is that it is common knowledge among xbox developers that D:\ references your working directory, so to speak.

but can OpenXDK do that during init?  What happens if there's no DVD drive / the DVD is changed?  Is creating the symbolic link not akin to mounting the drive?  Or are you just suggesting we add an API function "MountDVDToH"?

Cheers,
Tom

[openxdkman]

If you are looking for ideas, for your information, ps2dev requires this syntax :
"cdrom0:\myfile.ext"

[avelino]

Thanks all people for the answers. I am ussing the temporary solution posted by friedgold an the results are ok   . I expect the next OpenXDK release to support this.

Thanks again