Database Users

Render-To-Texture with HTC Diamond 2

Hi everyone,
I have a small technical problem to solve and hopefully someone knows an answer for it. Someone gave me a HTC Diamond 2 (very nice toy I think). I don’t know which hardware is exactly inside the phone but I assume it’s an ATI ImageOn 2300 which fully supports OpenGL ES 1.0 + Extension Pack (that’s what GL_EXTENSION is saying). And all of these extensions are doing fine. As everyone knows HTC is not providing a D3D driver for their phones and all other drivers I have seen are just a wrapper around OpenGL ES. So using D3D is currently not an option.
I have to write an application which requires some render-to-texture functionality in realtime and here my problems are starting to grow.
[1] glCopyTexImage2D:
I recognized that glCopyTexImage2D() is very slow. My framerate is dropping dramatically from >100 frames down to ~20 frames. Somehow this is done in software by the driver and not hardware- accelerated. glCopyTexSubImage2D() is even more slow (down to ~10 frames per second), but both functions are working. I tried to move it into a different thread, but the driver is not supporting shared contexts. Also it’s not supporting two bound contexts at the same time with two different windows and threads. So this can’t be improved or I’m doing something wrong.
[2]PBuffers:
PBuffer are working fine. But PBuffers which can be bound to a texture are not supported by OpenGL ES 1.0. And that’s what happens also on this ATI card.
[3]GL_OES_framebuffer_object:
This was my preferred choice. But framebuffers are not officially supported by the installed OpenGL driver. But the libgles_cm.dll on the HTC is exporting these functions so I tried them and recognized that they are not working correctly. Somehow the vertex pipeline is allowing only triangles in the center of the viewport. All others will be discarded. When I turn it off it renders correct. Using glDrawTexiOES() will be ignored while using framebuffers. I assume that either the current implementation of the framebuffers is just waste of some development guys or the functionality is locked in some way.
[4]D3D:
Normally D3DM is supporting to switch between different rendertargets. But we are all know the D3D problem. I tested some other D3D drivers but they are not usable. Also I can’t imagine how render-to-texture will be implemented in these drivers while it’s not working in OpenGL.
I’m wondering what TouchFlow3D is using internally, whether they are using render-to-texture or not. The only thing I know is that they are using OpenGL ES and some extensions. But Manila.exe is querying the functions of libgles_cm.dll during runtime. So I have to write a few proxy dlls first and need to hook into the system to track what they are doing. And I don’t want to spend time on this.
Does someone knows an alternative to do some render-to-texture on the ATI or knows some secrets of the libgles_cm.dll which I don’t know? There are a lot of private functions inside but can’t find some documentation about it. Also ATI and Qualcomm are not very helpful to me.
Thanks.

Maybe, glReadPixels and then glTexSubImage2D (what probably glCopyTexImage2D is doing)?
(I know that this goes two times over the graphics bus, but you never know...)
What kind of scene (number of triangles, lights, textures) are you rendering with > 100fps?

glReadPixels() + glTexImage2D() is even more slow than glCopyTexImage2D...
Also this can't be parallized. I thought using AHI2DATI.dll instead to do the same thing, but I don't know how to get a surface handle from a OpenGL texture id.
>>>What kind of scene?
A very simple scene yet. Only a few depth sorted + material sorted objects (via VBO) with some textures (backed lighting) on it. Textures are compressed. Currently no lighting, no skinning or other things. While the render thread is waiting for glFinish() to return, a second thread prepares the next frame. Also the rendering thread is not redrawing the entire viewport each time.

The OpenGL texture id is the handle. There's nothing more you can do with it. PBuffers or framebuffer objects are the only way I know for doing performant render to texture in OpenGL.

No...I mean the surface handle of the AHI2DATI library. Here you have access to the raw data of the surface. Somehow the libgles_cm.dll uses these surfaces for it own buffers and/or textures or not?!
But this is not really useful unless someone tells us whats going on inside libgles_cm.dll.
See:http://greengalaxy.wordpress.com/2009/04/18/ati-direct-access-to-hardware/

Hi jeansmsixer, I don't think there is no efficient way to do it. Have you tried eglCopyBuffers?
Aren't all textures stored in system memory? - they surely have to be because the device reports no available video mem.
Even if you get a pointer to the color buffer, it's impossible to wrap the memory in a HBITMAP to select onto a HDC and use GDI fonts for instance. (which is what I need to do).
If you do write the proxy dll like you were suggesting, can you please let me know what TF3D does for fonts? Are they textures or have they somehow mixed 3D with GDI?

Hi jeansmsixer, something else you could try is what is described here:
http://brewforums.qualcomm.com/showthread.php?t=10668
Looking on glbenchmark.com it looks like HTC devices support the extension. You should be able to get a pointer directly to the color buffer (which I presume is in normal system memory) so you could copy off pixels fairly efficiently with your own memcpy(). However, you will need to eglWaitGL() etc to ensure 3d stuff is complete before attempting to access it.
I love the irony of the only helpful information for WM opengl being found on a brew site for symbian. If WM7 is as terrible as the current mess, then I'm moving to iPhone.

[UNDER DEVELOPMENT]Windows Mobile 6 Bluetooth and Wiimote

I am currently trying to develop some software that allows to use a wiimote or a ps3 controller (ex. for fpsece).
all in vb.net
I currently discovered that I am unable to connect. I have already found a similar project that stopped because of the same problem!
I have read that the problem is the missing HID/S2CAP support of 32feet.net
The other software uses BlueTools so there may be the same problem!.
Does anyone know something that allows me to connect to my wiimote?! Maybe some SDK with HID/S2CAP support?!
You own an HD2 and another WinMob device and want to help? Take a look here: http://forum.xda-developers.com/showpost.php?p=5553883&postcount=10

Sorry, i cant help you but i will love control a wii with my HD...

I am speaking of the other way round , but I could also try that ^^.
I am talking about to control your HD with a Wiimote
It would be easy, if there is any idea how succesfull connect to the wiimote

I have found something here: http://www.eggheadcafe.com/software/aspnet/31158420/big5bxf276hrqkrnsut.aspx
I will see if it helps

Mhh, to bad, I cannot find the source files I would need
They maybe in the "Windows CE 5 platform builder" But the Online Setup I was able to get doesn't work anymore

scilor said:
I am speaking of the other way round , but I could also try that ^^.
I am talking about to control your HD with a Wiimote
It would be easy, if there is any idea how succesfull connect to the wiimote
Click to expand...
Click to collapse
Control your Wii with HD... It would be a great app.. if you can write it...
Thanks my Friend.

I was looking at doing this at one point. The HD2 with its Widcomm bluetooth stack supports BT HID, and the later WM6.5.X builds have Bth_HID in the SYS.
Pairing doesn't get you very far though. I found some C++ code for using the Wiimotes, but I haven't transfered it yet.

@l3v5y Why you have always the same ideas I do
The Bluetooth Stack of the HD2 seems to be a little bit buggy:
If I try to use a Bluetooth chat, it just works from my HD2 to my Kaiser, not the other way round. It is as my HD2 blocks all incoming Bluetooth connections
Any idea?

please setup a team , winmo need you
cheer

Ok, I have attached the Bluetooth Chat here.
It would be nice if other HD2 users could test it(You will need the HD2 and another WinMob Phone with a Widcomm Stack). Please always post the Roms of the devices, especailly the HD2's.
If it is only occurs on some ROMS, it would be fine, so I will do a Rom upgrade for further testing
My results where:
HD2 - T-Mobile ROM 1.43.11.2 (70315) Ger
Kaiser - Custom Rom WinMob 6.5
Message HD2 to Kaiser: Works fine, but takes a second.
Message Kaiser to HD2: Connection error, no message!

I found following in the thread of WiiMöb: http://wiimob.codeplex.com/Thread/View.aspx?ThreadId=10953
"But it seems likely that any purely bluetooth work was a red herring, and we just need to tackle BTHHID.DLL and devise a P/Invoke library that will get us a Filehandle to the device through the HID stack."

Hi everybody,
I'm also looking for a solution for that.
As I had similar problems with my Notebook (Widcomm-BT-Stack), I could solve it with a different BT stack. But I don't want to part with the Widcomm on my HD2.
I think the main problem is that the OK softbutton is disabled as long as there is no passcode in the inputbox. It only gets enabled if you enter somthing, which would never match up with the empty passcode of the WiiMote (somthing <> nothing ;-).
If the OK softbutton was enabled even with empty passcode box, the codeless pairing might actually work.
Is there anybody capable of unlocking this OK button?
Please
ScruffR

The problem is that the WM Devices misses a special HID driver . You may connect it with out a passcode with some tricks but this won't help because you cannot connect to the device

Look at this Symbian project http://www.symbianresources.com/projects/wiirider.php - maybe that will help. I got the same problem like everybody - can't pair device :s

We cannot connect the WiMote low-level easily, that is the big problem. If we could it would be easy.

...I'm assuming this has been abandoned? :/

Until someone finds a way to get a stream, the development is stopped

There is a way to connect to the Wii Remote with a WM 6 device.
The driver you want to look for should come with WM 5 and 6 devices. It has the prefix "BHI" it is not meant for production use, and it somewhat bare-bones, however you can successfully connect to the Wii Remote with it.
The registry path for this driver is:
HKLM\Software\Microsoft\Bluetooth\Hid\Hid_Class
and
HKLM\Software\Microsoft\Bluetooth\Hid\Instance
If you activate these drivers using the Win32 ActivateDeviceEx command (upon hard reset you don't have to do this), you should be able to open up a file stream to the driver.
Code:
HANDLE read_test = CreateFile(L"BHI0:", 0, 0, NULL, OPEN_EXISTING, 0, NULL);
Code:
unsigned __int64 wii_addr = 0x002659F4EEEDL; // BT_ADDR, 64 bits (8 bytes)
Then, I call the DeviceIoControl function to connect to the Wii Remote:
Code:
bool device_io_success = DeviceIoControl(read_test, 1, &wii_addr, sizeof(wii_addr), NULL, 0, NULL,NULL);
e = GetLastError();
Just replace the wii_addr with your Wii Remote's Bluetooth address.
The source code for this driver can be found by googling:
"bthhid.cxx source code" it should be the first link.
The set of APIs it provides is minimal, and I was not able to get any other function to work besides HIDConnect.
I'm still working on getting some sort of data from it.
Let me know if this works for you,
Mike

Could you send me a link to the source? I am finding any
I will take a look later, maybe we get it running

Unfortunately, I can't post the link due to spam restrictions (I just joined the forums recently). However, I have attached the folder that includes all the source files with this post.
This folder comes with Windows CE Platform Builder. It is located here (if you have Platform Builder installed):
C:\WINCE500\PRIVATE\WINCEOS\COMM\BLUETOOTH\PROFILES\HID
If you navigate to the BASE folder, you will find bthid.cpp. This is the main source that contains the stream driver implementation.
The main section of this file to examine is around line 2500 on down. These are the functions that are exposed when you create a file handle to the driver.
Let me know how it works out,
Mike

Samsung Ativ 500T. Android dual boot? Upscaling?

I believe the best hackers/minds/tinkerers in the internet are typically found in these forums, so I like to post the most intricate questions that all other forums failed to answer as my last resort. As they say, save the best for last. (No pressure, lol)
Issue 1:
Upscaling. Atom Clovertrail Z2760 does not have any upscaling option built into its Intel Graphics Control Panel. It is a known issue with all atom 2760 devices including my own tablet Samsung Ativ 500t, as well HP Envy X2, Asus Vivotab Smart, Asus Vivotab tf810c. etc.
The problem presents itself when attempting to run an old game designed for a resolution of 800 x 600, for example. When you go into "full screen" mode, what you get is a still tiny window with huge black bars all around. Somebody suggested using the windows magnifier, but that cuts off some of the game screen.
So, is there any third party mods to the Intel drivers, third party upscaler software, or anything of the sort I can use to solve this situation? Intel did not develop official drivers, and people contacting Samsung were pretty much told "screw you, we dont care"
Issue 2:
Android:
Research found that Bluestacks does not seem to work with my particular tablet. I encountered an interesting thing called Android X86, which Im sure you guys already know about. While going through their website, my head exploded. I do not have the savvy to reconfigure a kernel, or make a bootable USB drive using Linux without..well..Linux. I was just hoping that somebody has successfully installed Android x86 in a more recent Windows 8 tablet. I have found instances of people who did in older Windows 7 tablets, like the Acer w500 for example, but no one yet with specific information no how to install this on a clovertrail tablet.
I was hoping could help me out getting this done. Being able to dual boot the Sammy Ativ 500 would be a dream come true.
Thank you very much for your time.

There's a thread literally right next to this one that talks about installing Android-x86 on a Win8 tablet. You might start there...
The usual solution to the options for display scaling not appearing in the driver control screen is to put Windows into a lower resolution (for example, 1024x768 or 800x600) and then usually (though I haven't tried on Clover Trail) the option you're looking for (display scaling) will appear.

GoodDayToDie said:
There's a thread literally right next to this one that talks about installing Android-x86 on a Win8 tablet. You might start there...
The usual solution to the options for display scaling not appearing in the driver control screen is to put Windows into a lower resolution (for example, 1024x768 or 800x600) and then usually (though I haven't tried on Clover Trail) the option you're looking for (display scaling) will appear.
Click to expand...
Click to collapse
Yeah I tried that. I also tried the whole f11 thing. Nothing. Did not notice that other thread. will go check into it.

GoodDayToDie said:
There's a thread literally right next to this one that talks about installing Android-x86 on a Win8 tablet. You might start there...
The usual solution to the options for display scaling not appearing in the driver control screen is to put Windows into a lower resolution (for example, 1024x768 or 800x600) and then usually (though I haven't tried on Clover Trail) the option you're looking for (display scaling) will appear.
Click to expand...
Click to collapse
Im sorry if Im blind but..which thread are you referring to? I assumed it was the Iconia w700 one but saw no mention of Android X86

Near the end of the w700 thread its become a android-ia discussion not android-x86.
Anyway. The clovertrail CPU used in the 500t ONLY supports windows and will likely refuse to boot anything but windows. It might well be possible to male it boot the Linux kernel eventually but only with that kernel configuration you mentioned not wanting to do. Basically its not possible right now, but if it is possible one day there are 2 solutions to your making a usb drive in Linux without Linux. Firstly, ubuntu is free if you are willing to install it on another machine first (I think you can buy ubuntu DVDs or burn one yourself from windows). Secondly you can make bootable usbs in windows.
Android on clovertrail could eventually work, probably easier job than the surface RT guys have. The clovertrail replacement will be back to normal and support any x86 OS, I don't know why clovertrail has such a restriction, it just does.
Bluestacks for surface pro apparently works fine on clovertrail as does jar of beans. I haven't tried either one myself but have heard the various complaints about bluestacks working or not working.

The driver does not support upscaling.
I'm not sure if there is a hardware upscaler in the PowerVR SGX545 core or not.
but it can be done with software, like upscaling a lowres framebuffer to a highres framebuffer (f.e 640x480 -> 1366x768) and using opengl or directX for filtering or interpolation.
It has to be either done by the driver or as a dll hooked into a directdraw/directX/opengl application.
Driver would be the best option because it would be universal and work with all applications.

darkleafar said:
I believe the best hackers/minds/tinkerers in the internet are typically found in these forums, so I like to post the most intricate questions that all other forums failed to answer as my last resort. As they say, save the best for last. (No pressure, lol)
Issue 1:
Upscaling. Atom Clovertrail Z2760 does not have any upscaling option built into its Intel Graphics Control Panel. It is a known issue with all atom 2760 devices including my own tablet Samsung Ativ 500t, as well HP Envy X2, Asus Vivotab Smart, Asus Vivotab tf810c. etc.
The problem presents itself when attempting to run an old game designed for a resolution of 800 x 600, for example. When you go into "full screen" mode, what you get is a still tiny window with huge black bars all around. Somebody suggested using the windows magnifier, but that cuts off some of the game screen.
So, is there any third party mods to the Intel drivers, third party upscaler software, or anything of the sort I can use to solve this situation? Intel did not develop official drivers, and people contacting Samsung were pretty much told "screw you, we dont care"
Issue 2:
Android:
Research found that Bluestacks does not seem to work with my particular tablet. I encountered an interesting thing called Android X86, which Im sure you guys already know about. While going through their website, my head exploded. I do not have the savvy to reconfigure a kernel, or make a bootable USB drive using Linux without..well..Linux. I was just hoping that somebody has successfully installed Android x86 in a more recent Windows 8 tablet. I have found instances of people who did in older Windows 7 tablets, like the Acer w500 for example, but no one yet with specific information no how to install this on a clovertrail tablet.
I was hoping could help me out getting this done. Being able to dual boot the Sammy Ativ 500 would be a dream come true.
Thank you very much for your time.
Click to expand...
Click to collapse
I made a post about this, and i was able to make it boot to ''chose your language screen'' also it boots in safe mode.

Good News People!
I got android x86 installation to boot perfectly, going to install now. posting instructions when i can.

Good news. bad news.
With a program called easyuefi you are able to get it to boot to android x86 installation, however keyboard is not working when choosing an hard drive partition. in grub screen it works fine.
make a new partition, extract android x86 iso there.
Now open up easyuefi and click add entry
When choosing a boot file, In your extracted android x86 files there is a folder called efi.
choose 32bit efi file and click ok. well add to description android so it wont whine about missin description. Now at the easyuefi boot entry screen click on the entry you just created and choose one time boot, now click on power and choose reboot and then click yes.

Cyanogen based android x86 boots fine in live mode but the resolution is ''out of range'' the cyanogen bootlogo is really wide and bugged out, welcome screen is pixeled out.

Not working my friend. Any other suggestions or updates
justanpotato said:
With a program called easyuefi you are able to get it to boot to android x86 installation, however keyboard is not working when choosing an hard drive partition. in grub screen it works fine.
make a new partition, extract android x86 iso there.
Now open up easyuefi and click add entry
When choosing a boot file, In your extracted android x86 files there is a folder called efi.
choose 32bit efi file and click ok. well add to description android so it wont whine about missin description. Now at the easyuefi boot entry screen click on the entry you just created and choose one time boot, now click on power and choose reboot and then click yes.
Click to expand...
Click to collapse
not working

Ghalilo said:
not working
Click to expand...
Click to collapse
Posted to remixos section of xda, asking help with pictures that remix os actually boots but i still have some problems with it.
Remember to install android files to its own partition on your 500t hard drive / preinstall it there. You can add, modify and remove partitions from Disk Management.
I got remix os to boot with their own installer and cyanogenmod based android x86 android image with easyuefi.
remember to disable from bios the boot protection.
https://forum.xda-developers.com/remix/remix-os/samsung-ativ-500t-boot-remix-os-t3500257

Raspberry Pi 2, now with Windows 10 support

Raspberry Pi 2 spec:
A 900MHz quad-core ARM Cortex-A7 BCM2836 CPU (up from a single-core 700Mhz part)
1GB LPDDR2 SDRAM (up from 512MB)
Complete compatibility with Raspberry Pi 1 (software will need to be recompiled to take advantage of the new multi-core processor)
Identical form factor to the existing Raspberry Pi, which means it can fit into existing enclosures
10/100 Ethernet port
40-pin extended GPIO
4 x USB 2.0 ports
4 pole Stereo output and Composite video port
Full size HDMI
CSI camera port for connecting the Raspberry Pi camera
DSI display port for connecting the Raspberry Pi touch screen display
Micro SD slot
Micro USB power source

Its not going to be a full Win 10 like on a PC, its Win 10 IoT.

Well yeah it can not be full version still there is a windows support, I'm still waiting for Android support

Wonder if they will have proper display drivers with Win 10... Those are the reason Android hasn't been 100% successful in being ported over

Nypan sr said:
Its not going to be a full Win 10 like on a PC, its Win 10 IoT.
Click to expand...
Click to collapse
But hopefully it will be more like more like the x86 Windows version without any dumb restrictions, as opposed to the Windows on ARM SKUs we've seen so far (Windows RT and phone) that have too many restrictions. I believe the current IoT version is prrety stripped down and runs win32 executables, but I guess it remains to be seen exactly what the Windows 10 IoT SKUs (x86 or ARM) will be like.
Either way this is good news, and especially as it's the first Windows on ARM release (that I'm aware of) that isn't pre-installed on a device, and can be installed and removed at will (again, unlike Windows RT/Phone device with a locked bootloader). So that at least is encouraging.

I know it is a silly question, apart from the company news, has anyone independently managed to get a developer copy to work? I scoured all over the web and have not been able to see any info with regards to that.

vulcanize said:
I know it is a silly question, apart from the company news, has anyone independently managed to get a developer copy to work? I scoured all over the web and have not been able to see any info with regards to that.
Click to expand...
Click to collapse
There is no copy anywhere. At least, I managed Windows RT to boot with hardware-accelerated Qemu(and a basic Tegra3 emulation) if I disable the graphics driver. Still no input but that should just be some boring code to write.

black_blob said:
There is no copy anywhere. At least, I managed Windows RT to boot with hardware-accelerated Qemu(and a basic Tegra3 emulation) if I disable the graphics driver. Still no input but that should just be some boring code to write.
Click to expand...
Click to collapse
That's sounds very interesting (maybe should have posted that on the Windows RT section)
as a couple of us would be interested in learning how you did that

xsoliman3 said:
That's sounds very interesting (maybe should have posted that on the Windows RT section)
as a couple of us would be interested in learning how you did that
Click to expand...
Click to collapse
I should clean the UEFI implementation and adapt the HalExtTegra3 to something cleaner without a hacked VersatilePB target. How to disassemble that lib?

A bluescreen is the result with the RTSM emulator. Does anyone have Windows RT BSP documentation or a disassembler?

Just noticed someone else who has done amazing things with Windows RT on generic ARM hardware
http://winocm.moe/projects/bringup/osports/2015/01/12/giving-windows-on-arm-a-hand/

I think Linux is much more important than windows support.

C++: open file for writing in the LocalStorage

Hi guys, could you tell me how to open file for writing in the phone app LocalStorage for the non-unlocked handset (regular app for store)?
Code below doesn't work
Code:
FILE *tmp;
auto tmpPath = Windows::Storage::ApplicationData::Current->LocalFolder->Path + "\\tmp.txt";
auto tmpErr = _wfopen_s(&tmp, tmpPath->Data(), L"w");
Any suggestions?

Try looking though msdn articles. I found it somewhere in there. But I have forgotten it now.
Sent from Board Express on my Nokia Lumia 1020. Best phone ever!!
Note to noobs: DON'T PM ME WITH QUESTIONS. POST IN THE FORUMS. THAT'S WHAT THEY ARE HERE FOR!

@wcomhelp, please keep your rtfm advices for yourself, OK? I'm not a noob and of course I've searched msdn, google, codeplex, github etc. and so on before posting here. If you don't know how, much better be silent (like others who read this post but have no idea what I'm talking about)
I've tried a few possible methods including ugly "MS-way" with task & lambda syntax (see below) but nothing worked as it should be (code below works if no file exist and fails if file already exist - CreationCollisionOption::ReplaceExisting options is not worked/not implemented/buggy/billgates_knows_only ).
Code:
auto folder = Windows::Storage::ApplicationData::Current->LocalFolder;
Concurrency::task<Windows::Storage::StorageFile^> createFileOp(
folder->CreateFileAsync(CONFIG_FILE_NAME, Windows::Storage::CreationCollisionOption::ReplaceExisting));
createFileOp.then([=](Windows::Storage::StorageFile^ file)
{
return file->OpenAsync(Windows::Storage::FileAccessMode::ReadWrite);
})
.then([=](Windows::Storage::Streams::IRandomAccessStream^ stream)
{
auto outputStream = stream->GetOutputStreamAt(0);
auto dataWriter = ref new Windows::Storage::Streams::DataWriter(outputStream);
// data save code skipped
return dataWriter->StoreAsync();
})
.wait();
BTW, I've used workaround, to save ported C++ app data to the LocalSettings instead of text file (as it was in original code).

"Doesn't work" doesn't give us a lot to go on, troubleshooting-wise. Can you tell us what error you get?
Only thing I see in the code that looks a little weird is that the
Code:
"\\tmp.txt"
part isn't explicitly a wide-character string, but I'd expect string concatenation to take care of that.
Also, out of curiosity, why libc functions instead of Win32? Obviously, the code you're writing here isn't intended for much portability...

@GoodDayToDie, there is no error code at all - standard POSIX functions returns NULL FILE, the ::GetLastError() also return 0.
I'm porting old C-style app to WinRT platform and don't care about portability (but the first post code - just a simplified example, nothing more).
POSIX (libc) functions works pretty well for reading only but not for writing - that's the problem...
As I said before, I resolved my issue by workaround but still curious why the POSIX calls fails for file writing in the app storage.

buuuuuuuuuuuuuuuuh
No need for lambdas
https://paoloseverini.wordpress.com/2014/04/22/async-await-in-c/
You may also want to rethink your strategy
You can't create files at arbitrary locations, so your method is kinda redundant. All the locations you are allowed to create and read files to/from are available through KnowFolders and ApplicationData classes. These return StorageFolders which in turn can create files with CreateFileAsync (used for both creating and opening existing files) and get files with GetFilesAsync ( I recommend against this one though) and similar methods.

@mcosmin222, could you please re-read my posts one more time? I'm not trying to create files at "arbitrary locations"; I wanna create/write simple text file at the app's local storage (which one should be available for reading/writing). And the problem not in the lambdas or task usage (yes, it looks ugly but it works as it supposed to be).
Could you provide a working example instead of words? And I'll be glad to say you "thanks a lot"; can't say now...

sensboston said:
@mcosmin222, could you please re-read my posts one more time? I'm not trying to create files at "arbitrary locations"; I wanna create/write simple text file at the app's local storage (which one should be available for reading/writing). And the main problem not in the task (async execution).
Could you provide a working example instead of words? And I'll be glad to say you "thanks a lot"; can't say now...
Click to expand...
Click to collapse
Sure, just gimmie a few hours till I can get near a compiler that is capable of doing that

Of course, no rush at all, take your time. It's not a showstopper for me now (actually, my workaround with AppSettings is more preferable way - at least for universal app and roaming settings) but the issue still has an "academic interest" and maybe will be useful in the next projects for porting old C/C++ code to WinRT.

sensboston said:
Of course, no rush at all, take your time. It's not a showstopper for me now (actually, my workaround with AppSettings is more preferable way - at least for universal app and roaming settings) but the issue still has an "academic interest" and maybe will be useful in the next projects for porting old C/C++ code to WinRT.
Click to expand...
Click to collapse
hi
in vs 2015
#include <pplawait.h>
Something of the like should work
Code:
WriteSomeFile() __resumable
{
auto local = ApplicationData::Current->LocalFolder;
auto file = __await local->CreateFileAsync("some file", CreationCollisionOption::eek:penIfExists);
__await FileIO::WriteTextAsync(file, "this is some text");
}
However, as of right now, in VS 2015 RC, you have a host of limitations when dealing with this, but I do not believe this will be of any issue to you.
Code:
Cannot use Windows Runtime (WinRT) types in the signature of resumable function and resumable function cannot be a member function in a WinRT class. (This is fixed, but didn't make it in time for RC release)
We may give a wrong diagnostic if return statement appears in resumable function prior to seeing an await expression or yield statement. (Workaround: restructure your code so that the first return happens after yield or await)
Compiling code with resumable functions may result in compilation errors or bad codegen if compiled with /ZI flag (Edit and Continue debugging)
Parameters of a resumable function may not be visible while debugging
Please see this link for additional details
http://blogs.msdn.com/b/vcblog/archive/2015/04/29/more-about-resumable-functions-in-c.aspx
you should also note that this works with native, standard C++ types.

@mcosmin222, looks like unbuffered writing works (i.e. without streams) fine but it still not an answer for my initial question
I'm curious why the standard POSIX libc writing operations are not working on the app's local storage (but reading from files works fine). Actually, it's all about porting old C/C++ code for WinRT; of course for the new app it's not a problem but re-writing old code to FileIO should be a huge pain in the ass. What I did: I've "mechanically" changed all libc formatted outputs from file to string, and use LocalSettings class (actually it's XML file) to store that string (I'm planning also change LocalSettings to RoamingSettings, to provide settings consistency between WP & desktop app).
P.S. <pplawait.h> is not available in my VS 2015 (release pro version) so I've tested by using lambda pattern.

OK, first things first, LIBC != POSIX! The POSIX way to do this would be to call the open() function and get back an int as an "fd" (file descriptor), which is of course not implemented on Windows Phone because Windows Phone is not a POSIX platform (you might find the Windows compatibility functions _open() and _wopen(), but I doubt it). You are attempting to use the standard C library functions, which are portable but implement kind of a lowest common denominator of functionality and are generally slightly slower than native APIs because they go through a portability wrapper.
Second, sorry to be all RTFM on you but you should really Read The Manual (or manpage, or, since this is Windows, the MSDN page)! Libc APIs set errno (include errno.h) and use different error values than Windows system error codes (or HRESULT codes, or NTSTATUS codes, or...). Error reporting in C is a mess. If you were calling CreateFile(), you would check GetLastError(), but since you're calling _wfopen(), you check errno (not a function).

@GoodDayToDie, _wfopen_s returns 0 (i.e. "no error") but tmp pointer receives also 0 (NULL) Could you explain why libc file functions are working for reading (at the app installation & local data folders of course) but not for writing? Any logical ("msdn based") explanation? Or you just... don't know, heh?

sensboston said:
@GoodDayToDie, _wfopen_s returns 0 (i.e. "no error") but tmp pointer receives also 0 (NULL) Could you explain why libc file functions are working for reading (at the app installation & local data folders of course) but not for writing? Any logical ("msdn based") explanation? Or you just... don't know, heh?
Click to expand...
Click to collapse
LIBC functions will most likely work just in debug mode. The moment you try to publish the app it will fail. You can do lots of crazy stuff on your developer device with basic C functions, but if you try publishing, it won't pass the marketplace verification.
Most C APIs are simply not supported, since they do not comply with the sandbox environment of the Windows Runtime.
The code I gave you is tested with VS 2015 RC. You should be able to include <pplawait.h> just fine, if you are targeting toolchains newer than November 2013.

mcosmin222 said:
The moment you try to publish the app it will fail. You can do lots of crazy stuff on your developer device with basic C functions, but if you try publishing, it won't pass the marketplace verification.
Click to expand...
Click to collapse
Hmm... Are you sure or it's just your assumption? My app is still under development but (just for test!) I've made store app package for WP and it passed local store verification I also uploaded package to the store (via browser) and it also passed. I don't have time to create all tiles and fill all fields to complete beta-submission (actually, I don't know how to mark app as beta in the new dashboard) but for me it looks like app don't have any problem and will pass store certification easily. And you may be sure - it uses A LOT of libc calls 'cause originally it was written for Linux (or kind of UX system)

sensboston said:
Hmm... Are you sure or it's just your assumption? My app is still under development but (just for test!) I've made store app package for WP and it passed local store verification I also uploaded package to the store (via browser) and it also passed. I don't have time to create all tiles and fill all fields to complete beta-submission (actually, I don't know how to mark app as beta in the new dashboard) but for me it looks like app don't have any problem and will pass store certification easily. And you may be sure - it uses A LOT of libc calls 'cause originally it was written for Linux (or kind of UX system)
Click to expand...
Click to collapse
Once usage reports get up to microsoft, you will be given a notice to fix the offending API (happened to be once). You are much better off using the platform specific tools: not only they are much faster, they are also much safer and you won't have problems later on.
You might get away with reading stuff (since reading is not that harmful), but you should be using the winRT APIs each time they are available.
Simply uploading your app to the marketplace just reruns the local tests in their cloud servers: once you submit the actual app (not beta, not tests) for consumers, it will be much more aggressively checked. This is because the store allows specific scenarios for distributing apps in close circles that may break the usual validation rules.

@mcosmin222, one more time: is it your assumptions or personal experience? I don't know how many apps you have in store (I do have a lot) but I never heard that you said. I've used C++ libraries with WP hacks in some of published apps but never had any problem with "aggressive checks". What I know: if you are using some "prohibited" calls, your app will not pass uploading to the store (uploading, not a certification).
P.S. I'll send you personally a link when I publish release Hope, you'll like it

sensboston said:
@mcosmin222, one more time: is it your assumptions or personal experience? I don't know how many apps you have in store (I do have a lot) but I never heard that you said. I've used C++ libraries with WP hacks in some of published apps but never had any problem with "aggressive checks". What I know: if you are using some "prohibited" calls, your app will not pass uploading to the store (uploading, not a certification).
P.S. I'll send you personally a link when I publish release Hope, you'll like it
Click to expand...
Click to collapse
By "hacking" you mean recompiling the code to fit the windows phone toolchain? if so, then you shouldn't have to worry about too many things.
but even so, calling stuff like fopen in locations other than local storage will get your app banned. Even if it makes past the first publication, you can get noticed weeks later or even months (yes, it did happen to me personally).
In most cases, calling C APIs that can potentially break the sandbox (like opening a file in doc library with fopen) will always fail the marketplace verification, eventually. If it hasn't happened to you yet, then you may have not been using such APIs.

No, my C++ code is not accessing other than approved locations but the app has a lot of libс (and of course other C/C++ libs) calls; I'm 99.9% sure it's legitimate and will be not a source of any problem. Otherwise what is the advantages of having C++ compiler?!
As far as I know, just some of API's are prohibited but you will notice it right after local store compatibility test run...
As for "hacks" I mean usage of undocumented ShellChromeAPI calls (including loading hack).
P.S. I've found why <pplawait.h> header is missing. Initially I've created solution with the 12.0 toolset but now I can't (or don't know how to) change it to 14. However creating the new empty universal solution in VS 2015 also gives me toolset 12 by default. What is the toolset 14 for? Windows 10?

sensboston said:
No, my C++ code is not accessing other than approved locations but the app has a lot of libс (and of course other C/C++ libs) calls; I'm 99.9% sure it's legitimate and will be not a source of any problem. Otherwise what is the advantages of having C++ compiler?!
As far as I know, just some of API's are prohibited but you will notice it right after local store compatibility test run...
As for "hacks" I mean usage of undocumented ShellChromeAPI calls (including loading hack).
P.S. I've found why <pplawait.h> header is missing. Initially I've created solution with the 12.0 toolset but now I can't (or don't know how to) change it to 14. However creating the new empty universal solution in VS 2015 also gives me toolset 12 by default. What is the toolset 14 for? Windows 10?
Click to expand...
Click to collapse
The advantage of C++ is the obvious versatility: the standard C++ APIs will work fine for you as long as you stay inside the sandbox (this means you can't access files even in locations that are outside of sandbox but you have permission to them, such as music library). You can use most classic C/C++ libraries without issues as long as you do the interface with the runtime broker yourself. That means using windows runtime APIs instead of classic C APIs when dealing with stuff such as file access, for example. This is a pretty extensive topic and It is rather difficult to explain it all with 100% accuracy, especially when there is lots of docs running around.
You also get deterministic memory management, which is huge in specific scenarios.
Long story short
You will be fine with standard C/C++ when using
any in-memory functions supported by the compiler (you can manipulate data types, string, mutex, etc).
File IO in isolated storage only (applicationData folder)
Threads (although you are better off using threadpool or the like, it is much easier and cleaner). You can also use futures, and std::this_thread.
You will have to use winRT replacement
File system access in any other location than application data (you must use the windows::storage APIs)
sockets, internet access and the like.
any hardware related thing: music&video playerback must be interfaced through winRT (although the underlying decoders can be classic C/C++), messing around with the device sensors.
Retrieving system properties (internet connection state etc)
cross process communications
communicating with other apps
There are also win32 equivalents
mutex, threading, fileIO (isolated storage only)
Media playback with custom rendering pipeline.
Basically, winRT functions as an abstraction layer between the hardware and your code. You can use classic C++ up to the point where you need to interact with the system in any way. At that point, system interaction must be done with winRT. This way, microsoft ensures a higher degree of stability and security for devices.
check this link out for more information on the toolchains. You should be able to use this in VS 2013 as well with windows 8 (this is a compiler feature, has nothing to do with supported platform)
https://paoloseverini.wordpress.com/2014/04/22/async-await-in-c/