Related
I'm currently doing a little reverse engineering of Coredll so that I can understand how a few functions work. Occasionally I run across a function call to an address similar to F000BDD8. Is this a function call into the kernel or does it correspond to an address in the dll? If someone could point me to the correct reference, I'd appreciate it.
This is how it is layed out:
LDR r0, &0000b650
MOV lr, pc
MOV pc, r0
And at address 0000b650 the value is F000BDD8.
Thanks!
it is something like a "syscall" command on WinCE. The "FIRST_METHOD" value (0xF0010000) is subtracted form the given address, then value is divided by 2 (in your case we get -8468 or 0xff..ffdeec). If the value is negative it is "API call to an implicit handle. In this case, bits 30-16 of the method index indicate which entry in the system handle table." (probably its a typo in comment, bits 8-22 are used instead of 30-16). Lower bits are offset in SystemAPISets[] table for the function address.
For more information look into PrefetchAbort function in "PRIVATE\WINCEOS\COREOS\NK\KERNEL\ARM\armtrap.s" file, and ObjectCall function in "PRIVATE\WINCEOS\COREOS\NK\KERNEL\objdisp.c"
You should get PlatformBuilder and look into Wince 4.20 partial source code that is coming with it. It does not have much information on indexes inside SystemAPISets table for any table except for SystemAPISets[SH_WIN32] (SH_WIN32 == 0).
see this page for a list of systemcalls.
and this page for a description of how systemcalls work.
to convert a trap address ( like 0xF000BDD8 ) back to the syscall nrs:
Code:
$a= (0xf0010000-$addr)/4; # = 0x108a
$api=$a>>8; # 0x10 = SH_GDI
$call=$a&0xff; # 0x8a = ExtCreateRegion
( call defined in public/common/oak/inc/mwingdi.h )
hmm. not sure which is correct though, my wince-systemcalls page lists a different call signature than the headerfile. they should match.
Thank you for the information. I actually have the sample source that comes with the Platform Builder demo. In this case, the call I was investigating was the GetSysColorBrush API.
That brings me to another point. In several of the APIs a check is made to a value (KData->lpvTls[-20], I believe) to see if the 0-bit is 1. The only thing I can determine is whether or not this is checking for the ready state of the API. Whatever the case, it seems that this bit determines whether the function I mentioned earlier is called or whether a function address is loaded from RAM. It's really weird.
The main reason I'm doing this is so that I can access the system's brush cache for the system colors. I've noticed that if I intercept calls to GetSysColor and GetSysColorBrush, it only works for applications that have not called them yet. So, if I override the color for COLOR_BTNFACE, menubars for newly launched applications are colored correctly, but buttons (which belong to GWES) do not use the appropriate color. It's weird because my code has been injected into GWES.Exe.
I guess that brings me to my ultimate question of whether or not someone can point me to the location in RAM where the system brush cache is stored.
Thanks!
is the '-20' in bytes ?
in PUBLIC/COMMON/OAK/INC/pkfuncs.h
#define PRETLS_THRDINFO -5
#define UTLS_INKMODE 0x00000001 // bit 1 set if in kmode
#define IsThrdInKMode() (UTlsPtr()[PRETLS_THRDINFO] & UTLS_INKMODE)
this must be the bit that is set when calling 'SetKmode();'
Yeah, the -20 is in bytes. Here's the disassembly of what I was looking at:
00B5EC E59F6068 LDR r6, &0000B65C
00B5F0 E59F5060 LDR r5, &0000B658
00B5F4 E5960000 LDR r0, [r6, #0]
00B5F8 E5101014 LDR r1, [r0, #-20]
00B5FC E3110001 TST r1, #1
00B600 15950000 LDRNE r0, [r5, #0]
...
00B650 F000BF08 ANDNV r11, r0, r8, LSL #30
00B654 01FC6758 MVNEQS r6, r8, ASR r7
00B658 01FC6760 MVNEQS r6, r0, ROR #14
00B65C FFFFC800 SWINV &FFC800 <-- Points to KDataStruct
What you said makes sense, yet it seems kind of strange that this API would be looking at an offest of -20.
so what you are seeing, is a call to 'IsThrdInKMode()' .
there is a space of thread local storage used by the kernel, just before the publicly accessible thread local storage. - look for SIZE_PRETLS, and PRETLS_RESERVED in the wince source.
this function ( well implemented as a macro actually ) is not a very strange function to call from a system call.
btw, you should have a look at IDA from datarescue. it will give you a much more readable disassembly. the stuff in your example from 00b650-b65c will be recognised as a constant pool, and the references to it, like at 00b5ec will be disassembled as 'LDR r6, =0xffffc800'
The only problem I have with IDA is that I can't afford it and their demo doesn't handle ARM processors. The generated output was done with a fairly simple program and has forced me to learn quite a bit about the underlying code in the OS. I've had to go back and forth between the disassembly and the shared source, but I've managed so far (with this exception).
I do have one other question while I have your attention. I've managed to inject a dll into all of the running processes and I've successfully managed to intercept several APIs by patching an application's IAT (and all attached modules, too) in an attempt to provide a better color handler for the system. It appears, however, that some programs, like Gwes.exe, don't use call my functions, but instead call the functions built into Coredll. For example, the GetSysColorBrush I mentioned earlier. This is what prompted me to begin reverse engineering Coredll in the first place. Do you know if the addresses are being stored somewhere? If so, that would explain why even though I've patched the IAT that the original function is still being called.
contact me in PM, I can help with IDA 4.51 full
gwes.exe is the program implementing the API, so quite likely it either calls it's api's directly, or calls the systemcalls directly.
and maybe someprograms are linked to a statically linked version of coredll?
a while back I experimented with trapping systemcalls, by modifying the method table in an API. ( see hookapi.cpp )
I do remember that my device became very unstable. so I guess that it somewhat worked, but haven't figured out what exactly I did wrong yet.
btw, I would be quite interested to see your code to trap calls via the IAT.
When you have a look to romimage.exe source code in platform builder you will notice that there is a special handling for coredll.dll.
All programs included in the MODULES section will directly resolve calls to coredll.dll. Only if you build a new XIP section a warning will appear "missing coredll.dll ... will late bind".
This means that a hook to coredll.dll will not be visible for in ROM programs since they will call the system functions directly (without the trap).
John
itsme said:
btw, I would be quite interested to see your code to trap calls via the IAT.
Click to expand...
Click to collapse
Unfortunately, I'm not at the computer where I have the code, so I'll have to upload it to you tomorrow. However, it involves extracting the IAT from the PPROCESS structure of a given program, then enumerating through the entries until I find the API I'm looking for. It's actually pretty straight forward. Give me your email address and I'll send it to you as soon as I can.
JohnSmith said:
When you have a look to romimage.exe source code in platform builder you will notice that there is a special handling for coredll.dll.
All programs included in the MODULES section will directly resolve calls to coredll.dll. Only if you build a new XIP section a warning will appear "missing coredll.dll ... will late bind".
This means that a hook to coredll.dll will not be visible for in ROM programs since they will call the system functions directly (without the trap).
Click to expand...
Click to collapse
I don't have the full source code, only what's available in the shared source, so I'm not sure what modules would be affected. However, I'm really only interested in a few of the Gwes APIs. I know it's possible at least at some point to hook into those as I've seen it done, though the individual who did it is under an NDA and can't tell me how he did it.
Itsme's process looks to be about the best so far, assuming I can get it to work. The only thing is that I need to find a way to translate the physical address to a virtual adress (and vice-versa) for MIPS, SH3 and the emulator, not just the ARM/XScale processors. If I could do that, then I might be able to get things to work.
Thanks for all of your help so far. I appreciate the time you have spent in explaining a few things to me.
[email protected]
for translating physical to virtual you would need to find the translation tables for each process, which I assume must exist somewhere, but have not found them yet. - my guess is it may be the 'pPTBL' entry from the process struct, but have not verified this yet.
( you know that virtual addresses can not uniquely be translated back to physical without knowing what process they are for? for instance the virtual address 0x11000 is visable in each process, and mapped to a different physical address each time. )
Fortunately, I've written an OS before, so I know what you mean about address mapping. If the pTBL does contain the page mappings, that would make sense. I found it easier in my OS to keep the TLB entries with the process they belonged to. That way the OS wouldn't have to search through its memory chain looking for the process's mappings.
Also, if the pTBL does contain the TLB entries, then it should be relatively easy to decode the addresses. After reading your code, itsme, I determined that the CINFO structure holds a pServer field which points to the process which contains the APIs. So, for example, the GDI and USER API sets are being held in Gwes.exe (at least, according to the pServer field). The ppfnMethods field is a VA referring to the pServer. If pServer is NULL, then the ppfnMethods field seems to be a PA. So, what I could do is check for pServer. If it is NULL, I could use the current process's pTBL structure to map the PA to a VA. If the pServer field is non-NULL, then I could try the pServer's pTBL field to do the mapping and then do the replacement that way.
If this works, I owe you big!
here is another experimental program, that investigates all the handles present in the system.
I used it to generate this overview of handles.
Progress So Far
I just thought I'd post an update on my progress so far. It appears that I can overwrite the API table pretty easily. Instead of taking a physical address, the table takes a pointer to a function in virtual memory. You just need to map it to slot 0 using MapPtrToProcess.
I've come across two issues in doing this. The first thing is that I can't call the original function address. For example, I store the original address contained in ppfMethods[x] and then attempt to typecast it to the proper function type, passing the incoming variables.
The other issue is that it appears that the API table is NOT refreshed upon a soft-reset. Fortunately, I was playing around with it on the emulator. Had I not, I would have been forced to hard-reset my device.
Does anyone have ideas on either of these issues?
Thanks again for your help so far!
a thing that just occurred to me, is that if you duplicate the apiset struct, the memory pointed to by ppfnMethods should be readable from the process specified in pServer.
so you should allocate the memory in the address space of pServer.
or set pServer to yourself, and add some hook code which does not modify the stack, so you can just pass most calls directly to the original server.
to call the original function address, you have to somehow switch process context, and then call it.
Well, in the case that I tested, I replaced the QueryAPISetID API which exists in Wn32 and therefore has no pServer. It appears that if there is no pServer, then there is no context switch needed. I've been able to verify that the API will execute my code and the generated assembly does not modify the stack in any way.
This one is really weird. Thanks for the suggestions.
chmckay said:
itsme said:
btw, I would be quite interested to see your code to trap calls via the IAT.
Click to expand...
Click to collapse
Unfortunately, I'm not at the computer where I have the code, so I'll have to upload it to you tomorrow. However, it involves extracting the IAT from the PPROCESS structure of a given program, then enumerating through the entries until I find the API I'm looking for. It's actually pretty straight forward. Give me your email address and I'll send it to you as soon as I can.
Click to expand...
Click to collapse
Hi,
Just wondring if you could post/PM/email me the code that lets you replace the API call. This is for the purpose of hooking a different DLL to do my own thing, or see here:
http://forum.xda-developers.com/viewtopic.php?p=131857#131857
I just sent you a PM with the information you requested.
The New BT STACK(BCHS) has Release at 31 May 2006 , Can anybody find the setup file ?
the old BCHS ver.107 ( 1107 ) , See:
O2 MINI NEW BLUETOOTH STOCK.
The New one is ver.1740 , Description :
Release Description BCHS 15.1.0
Thanks !!
ps: Sorry !!! It's " Stack " , Not " Stock " ...
The Release File contains:
The 15.1 serie contains the following new features:
- The Phone Book Access Profile has been added
- The device side of the HID-profile has been added
- In the AV, FTC, OPC, BPP, CM and SC it is now possible to cancel an
action started by:
AV_CONNECT_REQ
FTC_CONNECT_REQ
OPC_CONNECT_REQ
BPP_CONNECT_REQ
CM_SDC_SEARCH_REQ
CM_SDC_UUID128_SEARCH_REQ
SC_BOND_REQ
Besides the new features a number of bugfixes has also been addressed in this release.
Below a short description of the content of the bugfixs that has been solved in this release is listed.
Release 15.1.0
--------------
Introduction
------------
The 15.1.0 release contain a number of bugfixes and improvments as liste
above.
And more old Release.......
link doesnt work....
Link brings up error "you dont not have the authorization to download this content"
I am very interested in seeing this!
It is a stack, you ...!
Hey Chatty,
i'm interested to see whether or not this updated version of the bluetooth stack (that i'm already using) has any of the bugs fixed that the original had.
If you looked at the old stack and the amount of attention it got maybe you should just let people follow what interests them and if you dont like it ... DONT READ IT!
People have the right to read what they want and say what they want! But they should be able to do it with out have someone personally attack them, ESPECIALLY IF THAT PERSON HAS NOTHING CONSTRUCTIVE TO ADD TO THE CONVERSATION!
Anyway
enjoy your night Chatty and relax a little!
we love ya anyway
Nice edit Chatty!
The Release File :
The 15.1 serie contains the following new features:
- The Phone Book Access Profile has been added
- The device side of the HID-profile has been added
- In the AV, FTC, OPC, BPP, CM and SC it is now possible to cancel an
action started by:
AV_CONNECT_REQ
FTC_CONNECT_REQ
OPC_CONNECT_REQ
BPP_CONNECT_REQ
CM_SDC_SEARCH_REQ
CM_SDC_UUID128_SEARCH_REQ
SC_BOND_REQ
Besides the new features a number of bugfixes has also been addressed in this release.
Below a short description of the content of the bugfixs that has been solved in this release is listed.
Release 15.1.0
--------------
Introduction
------------
The 15.1.0 release contain a number of bugfixes and improvments as liste
above.
Bugfixes
------------------
D-0095 Fixed problem in ./common.h with endian dependend macro's for
bytestream manipulation. The macros have been made endia
independent.
D-0307 Linux: Using BCHS in the Linux Kernel mode, the scheduler did
not correctly clean up the timed event queue upon shutdown.
D-0419 Linux: Using BCHS in the Linux User mode, the scheduler did
not correctly clean up the timed event queue upon shutdown.
D-0578 Linux: In the Linux kernel port, it must be possible to
specify an alternate panic handler, such that special
platform/application specific handling can be performed
instead of the default BCHS sched_panic() function.
D-0717 Linux: The Linux userspace USB driver must support the new
kernel-driver interfaces for Reset and EnterDFU.
D-0797 Linux: The Linux kernel USB driver supports a
non-documented customer-supplied "extra" interface to augment
the standard USB driver
D-0804 Linux: It is now possible to setup maximum number of
outstanding ISOC frames in the USB driver at runtime, instead
of having to define it at compile time.
D-0805 Linux: The Linux kernel USB driver is slow due to inefficient
URB usage pattern and too many payload copying.
D-0863 Linux: The Linux kernel driver will sometimes crash when being
unloaded.
D-0879 Linux kernel: Crashes/oopses have been seen to occur when
loading/unloading the USB driver multiple times.
D-0888 Linux: If the Linux kernel BSL (PAN) network interface was
loaded, but not configured (ie. not connected), the module
would crash on unload/unregister.
D-0901 Linux kernel: The USB driver must support the UsbDrv_Reset()
API call required by the USB interface.
D-0904 Linux kernel: The USB driver keeps too much track of the
outstanding URBs.
D-0959 All demo applications: Added "-A <bluetooth-address>" command
line argument for all demo applications. This option can be
used to skip device inquery in the demo application.
D-1017 Linux: The verify_area() Linux kernel API function has been
deprecated since at least Linux version 2.6.11 and completely
removed from at least version 2.6.14. The function access_ok()
should be used instead.
D-1082 Fixed problem in ./common.h with endian dependend macro's for
bytestream manipulation. The macros have been made endia
independent.
D-1100 OBEX/Common: Corrected miscalculation of unicode string length
D-1107 Linux USB: Fixed a problem in the Linux USB driver where a
transfer buffer was allocated based on a predefined value
instead of the value defined by the device
D-1155 BPPS: Support for mandatory features has been completed,
including status and referenced object channel has been
included.
D-1235 Linux USB: Fixed a problem in the Linux USB driver where URB's
could be leaked.
D-1238 Linux: The USB-driver can now handle a warm-reset so it is
possible to use USB ROM devices.
D-1239 Bootstrap: now possible to also use bootstrap when using USB.
A new Library is created for use with USB. The library name
is bccmd_boot_strap_usb.lib for windows and
libbccmd_boot_strap_usb.a for Linux. The old
bccmd_boot_strap-library still contains the serial boot strap
implementation.
D-1254 HFG: Disabling of status indicators using the AT+CMER is now
implemented.
D-1259 HFG: The actual status indicator values are now stored in the
HFG separately for each connection.
D-1265 Linux: The default BCHS sched_panic() now generates a kernel
stack dump when using the Linux kernel BCHS port.
D-1269 In BCHS version 15.0.0 the OBEX profiles writes the total file
size erroneous. This has now been fixed
D-1277 PAN DEMO: updated to prompt user for passkey instead of using
a fixed value.
D-1284 SBC: An overflow could occur in the decoded SBC sound
D-1432 samples, if the sound was played with maximum amplitude at the
time of encoding
D-1293 OBEX/FTC,OPC: The FTC and OPC profiles has had a general code
cleanup.
D-1297 OBEX/OPC: The prim->bodyType in the opcPutReq library function
is only assigned a value if the bodyType in the lib call is
not NULL. I.e. the bodyType contains garbage when arriving in
OPC profile resulting in a crash when OPC pfree it. This has
when fixed so the library set it to NULL.
D-1298 BPP: Could not initiate two requests on different channels at
the same time. This is now fixed.
D-1299 HFG: If the connection was disconnected during a service
search, it was not possible to initiate any further connections
from the HFG since service search resources were not released.
D-1300 Build: Problem compiling without
EXCLUDE_EXCEPTION_HANDLER_MODULE but with ENABLE_SHUTDOWN has
been solved.
D-1305 JSR82: Cancelling an inquiry through the JSR-82 layer led to a
delayed access violation in some cases, because a timed event
was not cancelled. The timed event is now removed when an
inquiry is cancelled.
D-1306 HFG: Fixed problem with Ring request
D-1310 OBEX/FTP: The FTP client API have been updated so the Get and
Put signal describes the new interface
D-1313 Linux: It is now possible to use bootstrapping when running in
the Linux User to kernel mode split.
D-1329 Changed the page scan mode to HCI_PAGE_SCAN_MODE_MANDATORY.
D-1339 Build: The WIN macro has been replaced by the build-in _WIN32
D-1340,D-1341 macro for windows builds. WIN is no longer needed.
D-1344 AV: Avoided AV forcing link to active in case of sniff request
by remote device.
D-1345 DUNC demo app.: Added menu item for hanging up a call and
updated the AT command call setup sequence
D-1350 SC: The SC module does not called sc_db_write() if the peer
device updates a link link which already exits. This has been
fixed so the sc_db_write() function is called when the link
key is updated.
D-1351 SC: If a peer device initiates a connection while the local
device is in high security mode, the class of device parameter
in a SC_BOND_IND msg is zero. A fixed has been made so this
parameter is valid in this situation.
D-1357 BCCMD: Removed memleak in SetPcmChannel
D-1360 VDP-Demo: SD_IFACEQUEUE added to tasks.c
D-1361 VDP-Demo: Alignment set to 8 byte
D-1364 Optimized the HID parser.
D-1365 HFG: When an incoming connection from a headset is initiated
at the same time of a connect request from the application it
is possible that both connections will fail.
D-1367 VDP demo: In order for properly interfacing the external video
library demuxing functions, BCHS libraries and the demo
application must be built using the same alignment as the
external library alignment. Instructions on how to do so has
been added in the demo description.
D-1371 HFG: Fixed handling of AT+CHLD=? in profile and Demo app.
D-1372 VDP Demo: ScPasskeyResSend updated to use proper result format.
D-1373 JSR82: An ill-behaved, threaded Java program could cause rfcomm
packets from the JSR-82 layer to arrive out-of-order. A message
queue has been added to handle this.
D-1374 VDP-Demo: If multiple media packets were sent in the same l2cap
packet then a temporary buffer was freed, causing an error.
This pfree has been removed.
D-1376 OBEX/OPC: If the OPC put an object which need to be spilt up in
multiple OBEX packets, the OPC is some cases keeps sending the
OBEX headers(name, type length).
D-1379 DUNC demo app.: Added response to port negotiation.
D-1380 CM: Under rare condition the Connection Manager could restore
its local queues when it is not allow to. The consequences of
this are that it can send more than one signal to the lower
layer and in worst case a dead lock could happen.
This has been fixed.
D-1381 JSR82: The inquiry procedure of the JSR-82 layer requests names
for all found devices. This has been changed to only request
names when requested from application layer.
The inquiry is now usable for selectService implemented in
upper layer.
D-1382 TCS: The SDP record of the TCS GW contained an incorrect value
of the protocol descriptor list. This incorrect value
(UUID TCS-BIN) has been changed to the correct value
(UUID TCS-BIN-CORDLESS)
D-1389 BPP: Removed potential memory leak when sending document to
printer, by pfreeing printContent.
D-1410 JSR-82: The inquiry procedure may cause a segmentation fault
if no device names are fetched during this. The event
responsible is now properly cleaned up.
D-1411 HFG-Demo: Cleaned up the handsfree demo application and removed
some macro re-definitions.
D-1416 OBEX/OPC: If the OBEX clients (FTC, OPC, BIPC) is release while
setup an OBEX connection their could go into a state where it
has not possible to make a new OBEX connection. This has now
been fixed.
D-1417 OPC: Removed potential memory leak when putting an object to
the server, by pfreeing the object received by the application.
D-1418 OPS: If an OBEX PUT packet includes a type header the OPS
profile did write an invalid byte into the OBEX PUT packet,
which made the rest of it invalid. This has now been fixed so
an invalid byte is not put into the OBEX PUT packet.
D-1420 HFG: HfgAtCmeErrorSend has been added to the Hfg-lib file.
D-1421 HFG: Library function HfgAtCopsSend now returns the correct
structure.
D-1423 BPP: Added description of docTypeLength and printContentLength
in API.
D-1424 HF: Fixed compilation problem when ADVANCED_HF was deined and
new SCO interface is used.
D-1426 BPPS: Activation issue for the BPPS profilemanager solved.
D-1428 BCSP: Fixed problem in BCSP where it was not possible to
initialise BCSP multiple times.
D-1429 Linux kernel: The USB driver should adjust the SCO packet size
after the VOICE_SETTING in usr_config.h.
D-1435 DUNC: Corrected 'maxMsgSize' assignment in the DUNC_STATUS_IND
primitive
D-1438 Handsfree: Fixed interoperability issue with some car kits that
does not follow HFP specification
D-1440 HFG: Fixed problem with incoming and outgoing connection at the
same time
D-1444 AV: Update of the AV API document so it now also states that
the AV profile supports video streaming
D-1445 AV: The description of the roleType parameter in the
AV_STATUS_IND message was wrong. This has been corrected so
the description matches the parameter
D-1446 HIDH Demo: The second parameter of the
HidhConnectAcceptReqSend(...) call in the HIDH demo is invalid.
D-1447 Handsfree: Updated default values for eSCO connections.
D-1456 AVRCP: Update of AVRCP API description, particularly connection
establishment issues.
D-1457 Build: It is now possible to compile BCHS with the
EXCLUDE_BCHS_L2CA_MODULE and/or EXCLUDE_BCHS_RFC_MODULE
compiler defines.
D-1463 BCHS: BCHS has been updated to support RFCOMM so it may be used
together with the 21d Firmware version
D-1467 AVRCP: Prevented forcing connection out of low power mode when
low power was changed by remote device
D-1473 Build: Problem compiling without
EXCLUDE_EXCEPTION_HANDLER_MODULE but with ROM_BUILD_ENABLE
has been solved.
D-1476 HFG: Transmission of callheld status indicator from the HFG is
added.
D-1477 HFG: Fixed the supported features written in service record.
D-1478 BPP-Client: Added description of
BPP_CONNECT_IND and BPP_CONNECT_RES which was missing in the
API documentation (bchs-api-023_obex_bpp_client_api)
D-1482 HFP: PICS document has been updated
D-1488 Corestack: Fixed an issue where the max_frame_size field of an
RFC_START_CFM contained the locally requested value and not the
negotiated value.
D-1489 TCS-Demo: Fixed the GW part of TCS demo application. The GW did
not respond with an alert message due to an imporperly set
variable.
D-1491 FTS: Added low power mode control.
D-1494 HFG: Updated HFG to mutually exclude RING and audio connections
for HSP according to ESR1 E2112.
D-1500 JSR82: For short local names, the JSR-82 layer would read
outside of the string, due to an incorrect cast. The name is
now copied properly.
D-1501 BPP: Made sure that BPP can be activated in NULL state.
D-1502 BPP: Only perform one SDC attribute search during BPP connect.
D-1503 BPP: Fixed problem with handling channels disconnecting in
random order in BPP.
D-1505 The following two compiler defines is added to usr_config.h:
PAGE_SCAN_TYPE
INQUIRY_SCAN_TYPE
These defines allow the customer to select which Page Scan Type
and Inquiry Scan Type BCHS is using.
D-1506 SAPS: Added Bluetooth address of remote device for incoming
connections to the SAPS_CONNECT_IND.
D-1507 BPP: Removed possibility of getting an incorrect structured
OBEX packet on the BPP Object Channel.
D-1509 TCS: Added support for the Samsung SIT105EW access point in the
terminal part of TCS
D-1515 HF: Updated API document with some missing lib. functions.
D-1516 CM: Added more error code mappings from HCI-error codes to
BCHS error codes.
D-1518 Optimized the HID parser
D-1519 HFG: Updated API document with some missing lib. functions.
D-1521 JSR-82: L2CAP connections may leave remaining data when Java
application is closed. This caused new connections in a new
Java application to fail. This data is now cleared.
D-1524 BPP: Corrected the security setting for BPP Object Channel to
none.
D-1525 Obex/Push App: Removed the references to C-code files in
profile_mangers etc. directories and insert the use of
libraries instead.
D-1526 BPP: Corrected the requested max OBEX packet size for BPP Job
and Status Channel.
D-1527 BPP: Added description of channelId and ConnectionId to
documentation of BPP_DISCONNECT_IND.
D-1530 BPP: Added extra security so BPP only accepts incoming Object
Channel connections from a connected printer.
D-1532 HFG: Fixed handling audio request when signals are crossing
D-1533 SC: The cod is zero in the SC_PASSKEY_IND and SC_BOND_IND in
the scenario where:
A successful bond has been made between dev 1) and dev 2).
If dev 2) debonds dev 1) and dev 1) afterwards initiate a
connection to dev 2) then dev 2) will initiate a new bond
sequence against dev 1) and in this case the SC_PASSKEY_IND
will popup with a cod=0 at dev 1).
This has been fixed now by adding a read to the SC_DB if cod=0.
D-1534 HFG/HF: Fixed error in SCO negotiation if application specified
eSCO parameters
D-1535 Changed default sniff mode parameters to 40 in order to follow
the BT spec.
D-1544 BIP: Optimized the BIP code and removed some bugs.
D-1545 AV,FTC,OPC,BPP,CM,SC: A new feature was been made which allowed
the application to cancel a:
AV_CONNECT_REQ
FTC_CONNECT_REQ
OPC_CONNECT_REQ
BPP_CONNECT_REQ
CM_SDC_SEARCH_REQ
CM_SDC_UUID128_SEARCH_REQ
SC_BOND_REQ
D-1547 OBEX/SYNC: Who header length corrected from (10 to 9) in the
obex-sync-server.
D-1548 The compiler define DEFAULT_LINK_SUPERVISION_TIMEOUT has been
added to usr_config.h.
This allows to adjust the default link supervision timeout for
all new ACL links created.
D-1550 OBEX/SYNC: Who header length corrected from (10 to 9) in the
obex-sync-server.
D-1552 SBC:When the SBC decoder decodes an audio signal, encoded with
max amplitude, the output signal occasionally drops to zero at
the peak values. This has been fixed now by fine tuning the
final scaling boarders.
D-1555 BPP: Fixed converter error in BPP related to getEvent,
getJobAttributes, and cancelJob, so it does not forget the
number zero.
D-1559 BCHS: Removed the use of put_message_in, put_message_at and
cancel_timed_message. These functions are planned to be removed
from the BCHS scheduler in the future (date of removal has not
been fixed yet)
D-1560 FTC: In BCHS 15.0.4 FTC always request the link to go to
ACTIVE mode even if it is already in this mode. This has been
change so FTC only request to go to ACTIVE mode if the link is
not in this mode.
D-1561 BPP: Now possible to cancel a job without getting a
disconnection in BPP.
D-1563 CM: In the situations where a peer device releases its L2CAP
connection before it has been configured, the connection
Manager (CM) could go into a state where it keeps rejecting
incoming connection attempts. This has now been fixed
D-1565 TCS: Lib functions has been updated to use bchs_msg_transport
which makes it more easy to split applications from BCHS.
D-1566 Linux: The library: sc_db-file was not built for Linux. This
has now been fixed.
D-1571 HIDD: The device side of the HID profile has now been
implemented conforming to the specifications.
D-1573 Handsfree: Memory leak when a AT command is not encoded as it
should has been fixed.
D-1576 API document updated with additional description, including
examples of how to use library functions.
D-1577 API documentation is updated with additional information on new
library functions and example on how to use all library are
added.
D-1578 PAN: Now only possible to build PAN for HCI and not RFC,
because PAN is only to be runned on HCI-builds.
D-1579 JSR-82: If the JSR-82 layer received a disconnect from the
remote device on an L2CAP connection while sending data,
it could enter a state where it would stop responding to any
signals sent to it. This issue has been cleared up.
D-1581 Handsfree: The body and the data fields are now switched so
that the contents are according to the API document.
D-1583 Handsfree: Length value of the body and the data fields is now
corrected so that the 0-terminations is also included.
D-1584 HFG: Format changed for CIND response, so that the call_setup
element is closed properly.
D-1585 HFG Demo App: OK is now send after HFG demo app has all +CLCC
results to HF.
D-1587 SDP: The SDP layer now does full comparison for 128bit UUIDS,
allowing searches for non-bluetooth (e.g. JSR-82 Java)
applications.
Note: This fix has only been applied to HCI builds.
D-1588 AV: When unregistering the service record when running as
SINK the wrong service record was used. This has now been fixed
D-1595 BCSP: Added init of timer ID to avoid cancelling already
expired timers
D-1597 HF: Fixed problem with string handling for +CLCC. and +CNUM.
D-1600 obex/fts: The connection-ID was wrongly set to 0xFFFFFFFF when
a connection was terminated. This has now been fixed so the
correct connection ID is returned.
D-1605 Handsfree: In the unsolicited +CLIP message send form the HFG a
needed space is added after the ":" so that the message now is
+CLIP: xx, where xx is a number.
D-1606 Handsfree: In different unsolicited message send form the HFG a
needed space is added after the ":" so that the message now
is +CLIP: xx, where xx is a number.
D-1608 Handsfree: The support AT-functions are corrected so that they
are according to the AT specification format.
D-1611 Handsfree: The errors in the function HfSendHfCmeeInd have been
corrected. It is not able to handle a space after :
(example:+CME ERROR: 32) and the digits send in the error code
are not mixed up any more so that a received code is send
corecltly to the app.
D-1613 Handsfree: Implemented signal interface is corrected so that
COPS function will work in HF and HFG API is updated for
HFG_COPS_RES.
D-1614 Linux kernel: The USB driver should have the functionality to
bring the interface into DFU mode.
D-1615 Changed default sniff mode parameters to 40 in order to follow
the BT spec. in the
bchs-api-005_connection_mgm_api documentation
D-1618 HF: Function HfSendClccInd is now able to handle space after :
D-1620 Linux: The userspace part of the USB driver does not support
entering DFU mode or USB reset.
D-1622 Phone Book Access Profile is implemented according version 1.0
of the specification.
The profile has two modules:
PAC is the client side e.g. Car kits
PAS is server side e.g. Mobile phones.
D-1628 BCHS has now been updated to support the BC3MM AV-router
v1.2.2 solution.
D-1630 SPP: Made API for changing low power mode on SPP connections
D-1632 SBC: The SBC decoder has undergone a minor optimization round
to improve the general decoder MIPS performance.
D-1634 CM: If the Connection Manager(CM) receives an incoming L2CAP
connection while the local message l2cap_connect_accept_req is
stored on a local queue, the CM will reject the incoming L2CAP
connection.
This has been changes so if a l2cap_connect_accept_req message
is stored the incoming L2CAP connection is also stored. In this
way the CM will not reject it.
D-1636 BPP: A cancel connect attempt can no longer result in a
BPP_CLOSE_SEARCH_IND.
D-1637 BPP: Made sure that the abort timer is cancelled if a
disconnection happens simultaneous.
D-1641 BPP: Fixed problem with uninitialised memory when using Object
Channel.
D-1642 FTS now sends CmModeChangeReq (for LINK_STATUS_CONNECTED)ONLY
once on rx of CM_DATA_IND while NOT in LINK_STATUS_CONNECTED
and obex is connected.
D-1644 FTS now sends CmModeChangeReq (for LINK_STATUS_CONNECTED)ONLY
once on rx of CM_DATA_IND while NOT in LINK_STATUS_CONNECTED
and obex is connected.
D-1647 Linux: The Linux userspace UART driver now correctly perform
the pthread shutdown sequence.
D-1648 In BCHS 15.0.5 FTC will request the link to go to ACTIVE mode
even if it is already in this mode. This only happens if FTC
receives a FTC_CANCEL_CONNECT_REQ in connected state.
This has been change so FTC only request to go to ACTIVE mode
if the link is not in this mode.
D-1649 Linux USB: A memory leak has been found in the Linux userspace
USB driver in the UsbDrv_Rx() function, where the rx-queue
element itself was not freed after the data has been send to
the stack.
D-1655 Linux user: The USB driver does not use the correct pthread
shutdown sequence.
D-1659 PAC: Added handling for low power mode and cancel connect.
D-1664 HIDH: solved free of non allocated data
D-1665 SPP Demo App: mapping between client and instance number made
more intuitive
D-1672 SAP: Updated Service record for SAP server to be compatible
with WinCE devices
D-1673 FTC: FTC accidently uses more than one timer to control
lowpower. This has been fixed so FTC only use one timer to
control this.
D-1674 HIDH: When calling HIDHConnectReqSend(..) with SdpInfo as a
NULL pointer undefined Memory access is read. This has now been
fixed.
D-1677 HFG: New signal "HFG_STATUS_INDICATOR_SET_REQ" is created to
enable the application to update the actual status indicator on
all link at the same time and in any state of the HFG.
D-1679 AV: Av app. will now receive a negative connect confirm also
when a cancel connect arrives too late to make actual cancel -
when the connection establishement is done but has not yet been
reported to app.
D-1680 An incorrect offset calculation that caused searches for more
than one 128 bit UUID to fail has been fixed.
Note: This fix has only been applied to HCI builds.
D-1681 HIDH: When HIDH luses the connection and should automatically
reconnect. If the reconnect fails, a HIDH_CONNECT_CFM is send
to the application instead of a HIDH_DISCONNECT_IND. This is
Fixed.
D-1682 HIDH: A problem in the HIDH package fragmentation routing which
did not work for packages larger than the MTU size has been
fixed.
D-1685 OBEX: Optimize the OBEX profiles so the clients release the
connection and the servers send a response code with error, if
the peer device sends an OBEX packet larger than agree on.
D-1688 TCS: Doing shutdown the tcs_deinit function did not pfree the
payload in a CM_L2CA_CONNECTIONLESS_DATA_IND_T message, causing
a potential memory leak. This has now been fixed.
D-1691 HIDH: Problems with Connect Accept and Reconnect Flag and
Virtual Cable Flag are True and Normally Connectable Flag is
False. This has been fixed.
D-1694 HIDH: Fixed a memory leak in HIDH which occured when packages
bigger that the MTU size was send. The user payload was then
not free'ed. This is now free'ed.
D-1704 OBEX documentation: Added connected state to the sequence
overview diagram.
D-1740 CM: In BCHS 15.0.6 TCS_IFACEQUEUE were hardcoded into the
Connection Manager (CM). If TCS_IFACEQUEUE were removed from
the bchs_task.h bchs could not compile.
This has now been fixed.
quite list there! will be interesting to see what the possibilities for the magician shall be!
Thanks for the heads up and i look forward to reading more
now to wait for the cab file...
The most important question for me: Will the modem work now?
Good!
Only two questions:
1) When it can be downloaded? From where?
2) That HUGE list of improvements it's really confusing. What is this new stack going to do respect the previous? It's worth install it?
Really thanks to people like wensonlau that discover interessant unpgrades to the magician
Cheers, MocciJ
still no working download to this hotly anticpated release?
What a pity... no one got access.
Was hoping this would make my Magaician work better with my Pioneer Bluetooth head unit....damn dissapointed it hasn't emerged.
UP
where?
I didn't say, I uploaded it. I just meant to put this thread to the top.
Can Anybody please tell me if this works fro Prophet (Xda neo), too ?
I have some Problems with my HT-820....
@meisterlampe2000: just try the older version and you'll know. Or just read the thread about the old version. How to find it? Use the SEARCH function!
SO kind of you !
I`ve read everything now, didn`t expect a different answer from you !
I hope to find a Link to that new Stack soon - Would be nice to listen to Music withoput interruptions.
THX
I have been trying to get a better understanding of CRC calculations. There is a lot of table based code that can be used available freely on the net but I want to implement my own basic technique first to get a fuller understanding. I have made a class to do the calculations and manually calculated an example to verify the code and they both agree. The problem is that based on this http://www.createwindow.com/programming/crc32/crcverify.htm my answer is wrong. If anyone could look over the attached txt file I would be great full. I can't post it here because the formatting would be lost and it would be impossible to read (very long division). The text I crc is resume (only those chars). The polynomial I use is the standard one used in zip 0x04C11DB7 when computing or 0x104C11DB7 when doing manually (the msb always cancels out).
It could just be that a table driven implementation generates a different crc, but I doubt it.
(log on to see attachment)
Hi,
I am a noob in the Java/Android development world. I primarily do hardware and firmware design, but a new product my company is developing has the need for an Android app and since I have the most Android programming experience (which is extremely limited) that leaves the task to me. I need a little guidance figuring out how to do a few things so that I can get this app up and running. I already have a simple GUI to display some stuff, but what I need is a way to handle data.
I am trying to receive a 148 byte stream of data over a serial connection, parse it into a structure and display certain values from that structure. The data is packed in a struct that is sent from a micro controller and due to that it has a very specific layout (i.e. the first 8 bytes mean this, the next 16 bytes are this... ). In C, I can just declare a struct with those values and use the #pragma pack function to eliminate any extra spacing the compiler would otherwise inject for alignment purposes, receive the data and do a memcpy into the struct to write the data. It's not the safest or cleanest way to do it, but it takes very little time and if you do CRC tests to make sure the data received is valid it works like a charm.
Now to the root of the problem: How do I declare structs in Java? Is there a way to pack them tightly like you can using C? Once I've received the binary data, is there a way to parse it into the structure easily? These are the issues we hardware programmers face when dealing with Java...
Any help would be greatly appreciated, thank you.
-Chris
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/