C++: open file for writing in the LocalStorage

[sensboston]

Hmm, it's exactly what I tried to tell you but I was much more laconic @mcosmin222, I know that stuff and already read documentation.

My initial question was very simple but nobody can provide a simple answer. Workarounds like you posed (using ::FileIO) or as I implemented, still require a lot of additional coding (if we are talking about porting "old style" apps).

OK, now my turn: if your app passed local store verificator, you are good to go and may be 99.99% sure - it will be published and distributed without any problems...

Nobody in Microsoft will disassemble or do a deep analysis of your app; 99.99% of tests are made by automatic verification procedure. So please stop telling us a scary fairytales. If you wanna believe - it's your personal business but don't mislead inexperienced people.

 

[mcosmin222]

Hmm, it's exactly what I tried to tell you but I was much more laconic @mcosmin222, I know that stuff and already read documentation.

My initial question was very simple but nobody can provide a simple answer. Workarounds like you posed (using ::FileIO) or as I implemented, still require a lot of additional coding (if we are talking about porting "old style" apps).

OK, now my turn: if your app passed local store verificator, you are good to go and may be 99.99% sure - it will be published and distributed without any problems...

Nobody in Microsoft will disassemble or do a deep analysis of your app; 99.99% of tests are made by automatic verification procedure. So please stop telling us a scary fairytales. If you wanna believe - it's your personal business but don't mislead inexperienced people.

Nobody will disassemble it indeed, but they do have automated tests and usage reports. They will catch up to you, eventually.

It all depends on what you do.
Yes, porting old style apps is a bit tricky when dealing with the file system, but we have to evolve at some point anyway...

Most old style C libraries I ported to winRT have had abstraction over FileIO, so you could provide your own implementation if the C-style one did not work. perhaps you should rethink your apps in the future to support such abstraction: it may be useful from a performance standpoint to use platform specific APIs when available.

 

[sensboston]

What do you mean by "usage reports"? Do you really think, MS hidden "spy" libs are monitoring every call from your app?

Could you tell me a real reason why your media player was banned in store? Also, according to your app rating, it's not popular or has many downloads; I'm surprised why MS even bothered...

As for FileIO calls: how you'll abstract formatted input/output? The only way I see it's how I implemented that - change file-based calls to string-based (4 example, fscanf to sscanf etc.) and use resulting stream as a argument of FileIO::WriteTextAsync (I prefer RoamingSettings).

 

[Useless guy]

Nobody will disassemble it indeed, but they do have automated tests and usage reports. They will catch up to you, eventually.

I'm pretty sure these automated tests just ensure that there's no restricted functions in the import table. In that case these can be easily bypassed with explicit runtime linking. LoadLibrary\GetProcAddress are restricted as well, but still the addresses can be found in run time. I guess @GoodDayToDie knows the proper way and can clarify it.

 

[G.moe]

Regardless of whether or not they're actively spying, the bottom line here is that @djamol's Root Tool made it into the Store, albeit being the easiest way to get a reg editor on a phone, and they DID eventually realize it was not appropriate for the Store.

 

[GoodDayToDie]

GetProcAddress is actually, oddly enough, supported in Windows Store and WP8.x apps. It's LoadLibrary that they ban.

There are multiple ways around that. One of the simplest is to just find the offset between LoadLibrary and another function call implemented in the same library, and then get a function pointer to the "legal" API and add the offset to it. Another is to start from the address of any "legal" API out of that library, then scan backwards through memory until you find the start of the DLL (it will begin with the bytes for "MZ" - Mark Zbikowski, who designed the PE binary format - as a magic number; you can find other strings, such as the "cannot run in DOS mode" thing, if you want o be more sure); the address of the start of the file is, in fact, the HMODULE.