locked
usinng std::fstream in native dll for Windows Store App

    Question

  • Point: std::fstream cannot help me read/write file (Library folder, manifest is already enabled.)

    Detail:

    I have below native code, runs well in other environments. 
    ------------------------------------------------------------------------------------------
    if (_open) throw except(OWN_INVALID_STATE, "Already open");
    if (_filePath.empty()) throw except(OWN_INVALID_STATE, "File path is not set");

    // Check existence.
    _existed = false;
    try {
    std::fstream file;
    file.open(_filePath.c_str(), std::ios::in | std::ios::binary);
    _existed = !_file.fail();
    } catch (...) {
    throw except(OWN_FILE_OPEN, "Own file open failure.");
    }

    // Open falg.
    std::ios_base::openmode mode;
    switch (om) {
    case omRead:
    mode = std::ios::in | std::ios::binary;
    break;
    case omWrite: default:
    mode = std::ios::out | std::ios::binary | std::ios::trunc;
    break;
    }

    // Open.
    try {
    _file.open(_filePath.c_str(), mode);
    if (_file.fail()) throw except(OWN_FILE_OPEN, "Own file open failure.");
    _open = true;
    } catch (...) {
    throw except(OWN_FILE_OPEN, "Own file open failure.");
    }

    ------------------------------------------------------------------------------------------------------------

    But _file.open() failed.

    Flows:

      Windows Store App invoke the native dll via IF.

     Above native code is inside the native dll.

    My questions: 

    1. std::fstream cannot be used unless be wrapped in RT Commponent? How about if just native dll?

    2. What is the official way to reused Win32 native code?

    Thanks

    Viet


    Saturday, October 05, 2013 5:33 AM

Answers

  • The problem is that the app doesn't have access to the file system for the libraries. It can access them only through the brokered StorageItem objects. You can use standard file API calls for the app's install and data directories, where the app has permission to read (for install) and write (for data)

    I discussed this in more detail in Skip the path: stick to the StorageFile

    --Rob

    Saturday, October 05, 2013 6:39 AM
    Owner
  • A Windows Store app application has direct read-write access to two areas:

    Windows::Storage::ApplicationData::Current->LocalFolder
    
    Windows::Storage::ApplicationData::Current->TemporaryFolder
    You can use the ->Data() member to get a path/filename, use your Standard Library code to write there, and then use StorageFile to copy the data through a broker as you said.
    Tuesday, October 08, 2013 5:49 AM

All replies

  • The problem is that the app doesn't have access to the file system for the libraries. It can access them only through the brokered StorageItem objects. You can use standard file API calls for the app's install and data directories, where the app has permission to read (for install) and write (for data)

    I discussed this in more detail in Skip the path: stick to the StorageFile

    --Rob

    Saturday, October 05, 2013 6:39 AM
    Owner
  • Thanks Rod,

    What about if I use current native api to create a file in app's directories then use StorageFile to copy or move itto file system for the libraries.

    In Other words: fstream -> app's files  => use StorageFile to move it out.

    Regards

    Tuesday, October 08, 2013 3:16 AM
  • A Windows Store app application has direct read-write access to two areas:

    Windows::Storage::ApplicationData::Current->LocalFolder
    
    Windows::Storage::ApplicationData::Current->TemporaryFolder
    You can use the ->Data() member to get a path/filename, use your Standard Library code to write there, and then use StorageFile to copy the data through a broker as you said.
    Tuesday, October 08, 2013 5:49 AM