Database Users

Learning how to program for Windows Mobile?

I've done some searching, and I know Windows CE uses Win32, which I know to an extent. I was curious if there are any good free resources for learning WinCE-Win32, or if I should simply use my existing books for MFC/Win32. Microsoft's site kinda sketchy, and MSDN not being very useful. I did get Microsoft Embedded Visual C++ working and compiled a test app which worked on my MDA and on the emulator.

i would just start coding
miniMFC and compact .net framework is soo close it's only
some controls and options you dont have
ortherwise it's the same thing
learning by doing and having ones fingers down and dirty
into the code is where you learn the most

Yep, that's just how I learned when I switched to coding for PPCs.
Any way here are a few major differences to start you off:
1) All API's that use strings are in UNICODE. ASCII versions were removed.
2) For most API's that have an 'ext' version the regular version was removed. Example: ExtTextOut - yes, TextOut - no.
3) When dealing with files, all paths must be absolute. No '..\file.x' and 'file.x' will give you the file in device root and not the app directory.
And here is a nice site for pocket PC specific apps:
www.pocketpcdn.com
Has articles on just about everything from making dialogs not full screen to writing today plug-ins.

levenum said:
Yep, that's just how I learned when I switched to coding for PPCs.
Any way here are a few major differences to start you off:
1) All API's that use strings are in UNICODE. ASCII versions were removed.
2) For most API's that have an 'ext' version the regular version was removed. Example: ExtTextOut - yes, TextOut - no.
3) When dealing with files, all paths must be absolute. No '..\file.x' and 'file.x' will give you the file in device root and not the app directory.
And here is a nice site for pocket PC specific apps:
www.pocketpcdn.com
Has articles on just about everything from making dialogs not full screen to writing today plug-ins.
Click to expand...
Click to collapse
I knew about how everything was Unicode. Is there an easy way to create unicode strings? I remember there was something in MFC macro like TEXT() that did something like that, but the specifics are missing. I remember there was a knowledge base article on this, but I can't find it.
Also, what's the difference between the Ext version and the non-ext versions of an app?
EDIT: Unless I'm mistaken, I just need to put my strings in _T("*string*")

Yes, you're right, this is how you write strings in your code:
Code:
WCHAR uniStr[] = L"Unicode string";
or if you are using MFC:
Code:
CString uniStr = _T("Unicode string");
and if you have a ASCII string you want converted to UNICODE
use mbstowcs function. (CString class has a built in conversion)
As for the 'ext' API's they just give you more parameters to better control the result of whatever they are doing. In desktop windows if you didn't want to call a function with 10 parameters you usually had a simpler version of it where some things were default.
Example:
Code:
BOOL TextOut(
HDC hdc, // handle to DC
int nXStart, // x-coordinate of starting position
int nYStart, // y-coordinate of starting position
LPCTSTR lpString, // character string
int cbString // number of characters
); //5 parameters
BOOL ExtTextOut(
HDC hdc, // handle to DC
int X, // x-coordinate of reference point
int Y, // y-coordinate of reference point
UINT fuOptions, // text-output options
CONST RECT *lprc, // optional dimensions
LPCTSTR lpString, // string
UINT cbCount, // number of characters in string
CONST INT *lpDx // array of spacing values
); // 8 parameters

what would be your suggestion for a newbie to learn programming for PPC?
I'm beggining to have interest in doing this but have absolutely no idea where to start.
thanks for any advise.

For complete newbies, I wrote this post a while back:
http://forum.xda-developers.com/viewtopic.php?p=209136#209136
V

VB.NET how to pass a struct? anyone?

Anyone know how to pass a pointer to a struct in VB.NET that could help me out?
" pGPSPosition
Pointer to a GPS_POSITION structure. On return, this structure is filled with location data obtained by the GPS Intermediate Driver. The dwValidFields member of the GPS_POSITION instance specifies which fields of the instance are valid."
This is from a link on MS site: (http://msdn2.microsoft.com/en-us/library/bb202050.aspx)
So how do I do this in VB?
Looking for a little love here...
TIA,

WM6 SDK contains the sample with the complete wrapper around the GPS intermediate driver in the managed code
But one warning - on some devices (namely HTC Artemis) the serious bug in some version of code provided by Microsoft to Oem return an error when calling functions this API. Communication with a GPS via serial port is still more reliable for a commercial solutions...

Appreciate the response but do you have any source that I can use with VB? My biggest problem is actually retrieving any information from the GPS device using the "GPSGetPosition" function. (see other link - http://forum.xda-developers.com/showthread.php?p=1979418#post1979418)
"But one warning - on some devices (namely HTC Artemis) the serious bug in some version of code provided by Microsoft to Oem return an error when calling functions this API"
Could you be a little more specific?
TW,

Semi manual marshhalling of structure to pointer:
Dim pointerM As IntPtr = Marshal.AllocHGlobal(Marshal.SizeOf(myStruct))
Marshal.StructureToPtr(myStruct, pointerM, False)
Marshal.FreeHGlobal(pnt)
Ad Artemis and another devices) GPS structure has invalid size from old platform builder and intermediate driver (GPS API) refuse it with error.

RStein,
As I was reading about it appeared that Marshaling was going to have to be used in some way since I'm pretty sure that the struct would need to be passed to the C function.
Which brings me to another Q since it appears your are savy at programing in C - how to convert the following C struct?
The struct appears to have a couple of arrays and a few other enums thats are passed to the function, how is that handled in VB?
DWORD GPSGetPosition(
HANDLE hGPSDevice,
GPS_POSITION *pGPSPosition,
DWORD dwMaximumAge,
DWORD dwFlags
);
typedef struct _GPS_POSITION {
DWORD dwVersion;
DWORD dwSize;
DWORD dwValidFields;
DWORD dwFlags;
SYSTEMTIME stUTCTime;
double dblLatitude;
double dblLongitude;
float flSpeed;
float flHeading;
double dblMagneticVariation;
float flAltitudeWRTSeaLevel;
float flAltitudeWRTEllipsoid;
GPS_FIX_QUALITY FixQuality;
GPS_FIX_TYPE FixType;
GPS_FIX_SELECTION SelectionType;
float flPositionDilutionOfPrecision;
float flHorizontalDilutionOfPrecision;
float flVerticalDilutionOfPrecision;
DWORD dwSatelliteCount;
DWORD rgdwSatellitesUsedPRNs[GPS_MAX_SATELLITES];
DWORD dwSatellitesInView;
DWORD rgdwSatellitesInViewPRNs[GPS_MAX_SATELLITES];
DWORD rgdwSatellitesInViewElevation[GPS_MAX_SATELLITES];
DWORD rgdwSatellitesInViewAzimuth[GPS_MAX_SATELLITES];
DWORD rgdwSatellitesInViewSignalToNoiseRatio[GPS_MAX_SATELLITES];
} GPS_POSITION, *PGPS_POSITION;
Click to expand...
Click to collapse
I had a suggestion to create a library from the C# SDK, how difficult would that be? Would it be easier than trying to convert to VB?
Can you help with that?
Thanks for any feedback...

HTC Sensors (HTCSensorSDK.dll)

Hi, I've seen some sensor implementations and some of them are not good written I think. I've disassembled HTCSensorSDK.dll file to help developers who use HTC sensors. You can look at it to know how it is done.
PF2009

I'm not a developer, but isn't this the same like this?

No, HTCSensorSDK.dll is SDK library from HTC which is used by this. 'Unified Sensor API' imports only some of HTCSensorSDK.dll functions. The author doesn't know how it was implemented. So there are some useless parts e.g.:
enum HTCSensor : uint
{
Something = 0, <--
GSensor = 1,
Light = 2,
Another = 3, <--
}
or signaling events:
// note: I noticed in Scott's code, on the shutdown he fires the "HTC_GSENSOR_SERVICESTART" event again.
// I am guessing that is a bug in his code.
// My theory is the service start/stop manage a reference count to the service.
// Once it hits 0, the service is stopped.
IntPtr hEvent = CreateEvent(IntPtr.Zero, true, false, "HTC_GSENSOR_SERVICESTOP");
SetEvent(hEvent);
CloseHandle(hEvent);

Awesome! You are correct, my implementation of the HTC sensor contains a lot of debug/instrumentation code. But it is private and unused, so it is really just benign code (such as the enum).
The only particular spot I wasn't sure was being done properly was the sensor cleanup; as indicated in my code comment. The only real outstanding issue then is the signaled events. I actually think that is used to start the HTC service that changes the orientation setting in the registry. So that is probably legitimate code. Unless you know otherwise?
The Samsung implementation was a lot easier, because I had a .h file to work with.

accelerometer(Incite) method signatures

I am trying to create a managed wrapper(.net) for the CT810(incite) accelerometer, just hit the wall--
I have dumped my ROM, and extracted the accelsensor.dll
but am unable to extract any signatures
I though I get lucky and just be able to tlbimp it, no such luck
next tried dumpbin /EXPORTS accelsensor.dll
Dump of file accelsensor.dll
File Type: DLL
Section contains the following exports for ACCELSENSOR.dll
00000000 characteristics
2C05A62B time date stamp Thu May 27 22:42:03 1993
0.00 version
1 ordinal base
11 number of functions
11 number of names
ordinal hint RVA name
1 0 000015E0 ACC_Close
2 1 0000141C ACC_Deinit
3 2 000021CC ACC_IOControl
4 3 00001F40 ACC_Init
5 4 000015DC ACC_Open
6 5 00001520 ACC_PowerDown
7 6 00001574 ACC_PowerUp
8 7 000015E8 ACC_Read
9 8 00001618 ACC_Seek
10 9 00001600 ACC_Write
11 A 00001620 DllEntry
Summary
1000 .CRT
1000 .data
1000 .pdata
1000 .reloc
4000 .text
But this does not show any vector data I could subscribe to
Does PEBrowse work with ARM?
Any advice on what to do next?
Regards
_Eric

could you please post the dll for others to work with?in no dev but have been looking forapps that will work with the incite accelerometer but most are made for HTC. you have a step up on most you the fist ive seen in past 4mo of looking who even trying hopefullu little team work with some guys who developed few apps that work with htc g sensor.if you could repost this with included dll. thanks

I now own a LG GM750 (WM6.5) and it also uses the accelsensor.dll.
Some MS applications like IE6 and picture viewer use it when turning the phone but all the nice HTC apps are not working.
There is HTCEmu for Samsung which probably could be adapted for LG.
Anybody trying to do this ?

Hmm.. since this old thread was bumped, I just wanted to link this for reference if it's helpful:
http://www.lg-incite.com/index.php?topic=2791.0
dll & mbn are at 3rd post

Hi
first sry 4 my englisch im german.
Im very interested to get the motion/g-sensor to work with htc apps. I got my lg last week and have the same problem that no apps work on it exepting ie and some windows apps.
If i can help to post some detail or if somehone has a conclusion how to use plz help.
i testet the samsung emu but it do not work also.
THX much

attached the.dll of the lg gm750 in case they serve of something

solution for LG GM750
First take a look at the Unified Sensor Api at codeplex.
My solution is based on the Samsung sensor class, modified to meet the peculiarities of the LG GM750.
First of all, the import of the DeviceIoControl in NativeMethods.cs must be modified such way dwIoControlCode is type uint, and the buffers are byte:
Code:
[DllImport("coredll", CharSet = CharSet.Auto, SetLastError = true)]
public static extern bool DeviceIoControl(IntPtr hDevice, uint dwIoControlCode, [In] byte[] inBuffer, int nInBufferSize, [Out] byte[] outBuffer, int nOutBufferSize, ref int pBytesReturned, IntPtr lpOverlapped);
After a long time dissassembling the accelsensor.dll and and a lot of trial and error testing I came to this conclusion that works:
The constant that starts/stops data output becomes:
Code:
const uint ACCOnRot = 0x1014EE8;
const uint ACCOffRot = 0x1014EE8;
and for reading values:
Code:
const uint ACCReadValues = 0x1014F10;
The difference between start and stop comes from the input given in DeviceIoControl method as follows:
Code:
public static LGAccSensor Create()
{
DeviceIoControl(ACCOnRot, new byte[1] {1}, new byte[4] );
return new LGAccSensor();
}
protected override void Dispose(bool disposing)
{
base.Dispose(disposing);
DeviceIoControl(ACCOffRot, new byte[1] {0}, new byte[1] );
}
The DeviceIoControl inside the accelerometer class becomes
Code:
public static void DeviceIoControl(uint controlCode, byte[] inBuffer, byte[] outBuffer)
{
IntPtr file = NativeMethods.CreateFile("ACC1:", 0, 0, IntPtr.Zero, ECreationDisposition.OpenExisting, 0, IntPtr.Zero);
if (file == (IntPtr)(-1))
throw new InvalidOperationException("Unable to Create File");
try
{
int bytesReturned = 0;
int inSize = sizeof(byte) * inBuffer.Length;
int outSize = sizeof(byte) * outBuffer.Length;
if (!NativeMethods.DeviceIoControl(file, controlCode, inBuffer, inSize, outBuffer, outSize, ref bytesReturned, IntPtr.Zero))
throw new InvalidOperationException("Unable to perform operation.");
}
finally
{
NativeMethods.CloseHandle(file);
}
}
Note that the accelerometer device is called ACC1:.
Further the method that returns the three component vector becomes
Code:
public override GVector GetGVector()
{
byte[] outBuffer = new byte[4];
DeviceIoControl(ACCReadValues, new byte[1] {1}, outBuffer);
GVector ret = new GVector();
int accx = outBuffer[2];
if (accx <=31)
ret.X = accx/2.17;
else
ret.X = (accx-64)*0.47;
ret.X = -ret.X;
int accy = outBuffer[1] ;
if (accy <=31)
ret.Y = accy/2.17;
else
ret.Y = (accy - 64) * 0.47;
int accz = outBuffer[0] ;
if (accz <=31)
ret.Z = accz/2.17;
else
ret.Z = (accz - 64) * 0.47;
double somefactor = 1; return ret.Scale(somefactor);
}
Note that the when called with AccReadValues parameter, the DeviceIoControl returns three bytes each of them containing a signed 6 bit 2's complement value.Basicly there are values on 6 bit ranging from -32 to +31. In the docs below there are tables that put in correspondence these values with acceleration in range -1.5g +1.5g which are the limits of the device. The code I wrote returns acceleration in meters/second2 where 1g=9.8 m/s2. That information I extracted from the technical specifications of the MMA7660FC accelerometer, as found at(try a google search). Also, the type of the accelerometer circuit is found in the service manual (I only found the service manual for LG GM730 which is pretty close).The same thing I also posted at codeplex.

All that means that you are in a good way to make the gm750 sensor act like samsung' s, even htc's, sensor???
Oh, iamspv, please make it work, I begging you!

jowl_tnt said:
All that means that you are in a good way to make the gm750 sensor act like samsung' s, even htc's, sensor???
Oh, iamspv, please make it work, I begging you!
Click to expand...
Click to collapse
It already works! There is nothing more to do about it than use the code in your applications (I speak as a programmer and for programmers). I only showed everyone interested in developing for LG GM750 the steps to modify the SamsungGSensor class from "Unified Sensor Api" at codeplex to work with a LG. Just get the rest of the code from there and put it toghether.
Now there are two directions:
Direction #1
If you want to develop applications that aim to be portable between HTC, Samsung, LG, Toshiba, etc, and you want to use Unified Sensor Api then..
the person responsible for the unified api project at codeplex should make the update to the library as soon as possible such way the library should keep compatibility with the adressed devices. I'm just contributing with some results. That's because the initial code was not very general (ie. the initial parameter types to deviceiocontrol invoked from coredll didn't work with this solution) I had to make some modifications to the code that work with the LG but affect other devices' sensor classes. Now, if the update doesn't come up soon, no problem, anyone just gets the code from codeplex, adds a new class for LG, copies code from Samsung, renames Samsung with LG, adds my modifications, corrects syntax errors, compiles, et voila . . the library is updated to support LG GM750.
Direction #2
If you develop only for LG, just write a LG class as presented above and don't care about other devices.
If you don't know how to use your new class, the project at codeplex has some examples and you'll easily see inside the code how to instantiate sensors, how to read data at certain moments using a timer, and how to capture screen rotation events.
And for your long awaited joy to see it working, I attached the sensor test program along with a version of sensors.dll compiled by me, that works for GM750.
Now get your fingers toghether on the keyboard and start developing for LG

Thanks a lot for this! I can now play sensory-overload on the LG750
I downloaded the game and replaced the sensor.dll with your version.
Now I'll need to find out how to use this with SPB Mobile Shell...

Thanks for your help but I'm not a programmer and I don't understand much of these.
I think the solution is to make a modified HTCSensorSDK.dll for gm750. Then all gsensor apps for htc will work on our lg. Is that right;

That is what so many users have been waiting for.
It works for LG GM735 as well.
much appreciated !. Well done!.

roolku said:
Thanks a lot for this! I can now play sensory-overload on the LG750
I downloaded the game and replaced the sensor.dll with your version.
Now I'll need to find out how to use this with SPB Mobile Shell...
Click to expand...
Click to collapse
roolku, please confirm that when playing sensory-overload the Y axis is reversed. It is an issue of the Sensor API I encountered while testing.
The theory says,
"The positive X axis is from the center of the screen to the right.
The positive Y axis is from the center of the screen to the top.
The positive Z axis is from the front of the screen towards the viewer."
but this isn't the case in sensor api.
I respected this theory when I returned the acceleration values, as you can see in my sensor test program. But also you will see the api considers Portrait as Reverse Portrait.
Developers should be aware of these issues and make the appropiate changes to the library when writing code.

iamspv said:
roolku, please confirm that when playing sensory-overload the Y axis is reversed. It is an issue of the Sensor API I encountered while testing.
Click to expand...
Click to collapse
Yes, you are right. I couldn't quite put my finger on what was strange when playing it.
iamspv said:
I respected this theory when I returned the acceleration values, as you can see in my sensor test program. But also you will see the api considers Portrait as Reverse Portrait.
Developers should be aware of these issues and make the appropiate changes to the library when writing code.
Click to expand...
Click to collapse
Hm, I wonder if it is more sensible to conform to the established convention rather than expect everybody else to change their ways. Unless I misunderstood you?
Would you mind supplying a version of sensor.dll that is compatible with the Samsung one (i.e. reversed y-axis)?

thank you, clublgmobile you thanks, expect that works with all applications

I don't understand how that works. How can i play RescoBubbles for example;

this is excellent news. now if we could just get the GW820 (expo,IQ) accelsensor.dll dissasembled we'd be cookin with gas

killerskincanoe said:
this is excellent news. now if we could just get the GW820 (expo,IQ) accelsensor.dll dissasembled we'd be cookin with gas
Click to expand...
Click to collapse
Yes, it would be very much appreciated! Ive been looking for a htc wrapper for our sensor since i got the phone.
I attached the accelsensor.dll from the eXpo in case that will help at all. I wish i had the knowledge to do more myself..
edit:
Also, theres a game that comes stock on At&t's model gw820 called Ferrari GT Evolution that uses the gsensor. Its made by gameloft so maybe its not as hard to get to as the incites?

to roolku:
Here is a modified version of sensors.dll with reversed Y axis that will a allow you to normally play sensory overload on your GM750. Using the GSensorTest you will see Portrait is now detected correctly.
Also, this version of sensors.dll works on HTC and Samsung as the original one , I managed to separate code. See the attachement.
to theyllib
I dissassembled the gw820 accelsensor.dll you provided. Looks like the interesting part is here
this is some data
Code:
.text:100027CC dword_100027CC DCD 0x32100C ; DATA XREF: ACC_IOControl+25Cr
.text:100027D0 dword_100027D0 DCD 0x321008 ; DATA XREF: ACC_IOControl+250r
.text:100027D4 dword_100027D4 DCD 0x321004 ; DATA XREF: ACC_IOControl:loc_1000263Cr
.text:100027D8 off_100027D8 DCD unk_10005650 ; DATA XREF: ACC_IOControl+8Cr
.text:100027D8 ; ACC_IOControl+138r ...
.text:100027DC dword_100027DC DCD 0x22200C ; DATA XREF: ACC_IOControl+80r
.text:100027E0 dword_100027E0 DCD 0x222008 ; DATA XREF: ACC_IOControl+74r
.text:100027E4 dword_100027E4 DCD 0x222004 ; DATA XREF: ACC_IOControl+68r
.text:100027E8 dword_100027E8 DCD 0x222010 ; DATA XREF: ACC_IOControl+48r
.text:100027EC off_100027EC DCD aAcc_iocontrol0 ; DATA XREF: ACC_IOControl+30r
.text:100027EC ; "ACC_IOControl(%08x)"
and this is where they are adressed
Code:
.text:10002440 LDR R3, =0x222010
.text:10002444 CMP R6, R3
.text:10002448 BHI loc_100025D4
.text:1000244C BEQ loc_10002588
.text:10002450 MOV R3, 0x222000
.text:10002458 CMP R6, R3
.text:1000245C BEQ loc_100025C0
.text:10002460 LDR R3, =0x222004
.text:10002464 CMP R6, R3
.text:10002468 BEQ loc_10002540
.text:1000246C LDR R3, =0x222008
.text:10002470 CMP R6, R3
.text:10002474 BEQ loc_10002518
.text:10002478 LDR R3, =0x22200C
.text:1000247C CMP R6, R3
.text:10002480 BNE loc_10002660
.text:10002484 LDR R3, =unk_10005650
.text:10002488 LDR R3, [R3]
.text:1000248C CMP R3, #1
.text:10002490 MOVNE R3, #0
The codes that must be sent to DeviceIoControl in coredll.dll are probably the 0x22200C, 0x222008 and stuff. The 0x321008 and stuff are some power get/set codes. But you need a programmer with an actual gw820 device to make it work as it need lots of testing. Hope this information helps and someone with such device will make it work.

Can anyone check if the Incite comes with ACCAPI.DLL, and if so can it be posted ?

File transfer over TCP sockets

I've been trying to get a simple file transfer between desktop app and phone app. The transfer works up to a point, when it simply ...stops dead.
The server(aka desktop client) enters the listening state, and the phone goes idle.
Anyone has any samples on transfers of large file (bigger than 1 MB)?

mcosmin222 said:
I've been trying to get a simple file transfer between desktop app and phone app. The transfer works up to a point, when it simply ...stops dead.
The server(aka desktop client) enters the listening state, and the phone goes idle.
Anyone has any samples on transfers of large file (bigger than 1 MB)?
Click to expand...
Click to collapse
Have you looked through GoodDayToDie's source code for the File Server? I wonder if he has anything in there that could make that work.

snickler said:
Have you looked through GoodDayToDie's source code for the File Server? I wonder if he has anything in there that could make that work.
Click to expand...
Click to collapse
lalz.
Completely forgot about that one xD
Meh he has it written in C++
Apparently, he didn't do anything that I didn't.

mcosmin222 said:
lalz.
Completely forgot about that one xD
Meh he has it written in C++
Click to expand...
Click to collapse
You can still utilize the transfer portion . I was thinking of seeing what I could do with sockets on the phone. I know it could come in handy somehow

snickler said:
You can still utilize the transfer portion . I was thinking of seeing what I could do with sockets on the phone. I know it could come in handy somehow
Click to expand...
Click to collapse
It's a pain in the ***.
It stops transfer at random points.

mcosmin222 said:
It's a pain in the ***.
It stops transfer at random points.
Click to expand...
Click to collapse
That doesn't surprise me at all for some reason.

Did you double-check your socket multithreading code?
I recently had problems with sockets and it turned out that I had the muti-threading thing wrong.
I think you shouldn't use only one connection and fail if it drops ...

ScRePt said:
Did you double-check your socket multithreading code?
I recently had problems with sockets and it turned out that I had the muti-threading thing wrong.
I think you shouldn't use only one connection and fail if it drops ...
Click to expand...
Click to collapse
What do you mean by socket multthreading code? You mean the use of async methods? or having the thread work on background, using the socket?

Take a look to the Tim Laverty's networking samples.

sensboston said:
Take a look to the Tim Laverty's networking samples.
Click to expand...
Click to collapse
That's what im doing (more or less)

@mcosmin222: The most common reason I saw for why that happened was the thread doing the transfer would crash. There's a lot of things that could cause such a crash, but because it's not the main thread or a UI thread, you don't see it. It just stops. In fact, even the debugger usually doesn't catch it (annoying as hell...)
There are a few common things that non-UI threads aren't allowed to do which you might be trying. For example, attempting to show a MessageBox on a non-UI thread will crash the thread (you can do it by adding a lambda or function to the dispatcher for the UI). In any case, feel free to use or adapt my code, or share yours here and if there's an obvious issue I'll point it out. Incidentally, you can set a larger buffer on the socket if you want the operation to complete without looping.
By the way, the only portion of my webserver that's written in C++ is the file I/O code, which I chose to do in C++ rather than .NET because the phone's stunted .NET framework makes it more difficult than I like to access arbitrary file paths. That code is all fairly clean wrappers around the Win32 calls; I suppose I could comment it more but it's very straightforward to read even if you aren't familiar with managed C++. The actual network code is entirely written in C# 4.5. You could actually simplify it a bit for a direct transfer app, too; I wrote it with a lot of multithreading in case I wanted to re-use the code somewhere that might be expected to have more than one client connecting at a time.

GoodDayToDie said:
@mcosmin222: The most common reason I saw for why that happened was the thread doing the transfer would crash. There's a lot of things that could cause such a crash, but because it's not the main thread or a UI thread, you don't see it. It just stops. In fact, even the debugger usually doesn't catch it (annoying as hell...)
There are a few common things that non-UI threads aren't allowed to do which you might be trying. For example, attempting to show a MessageBox on a non-UI thread will crash the thread (you can do it by adding a lambda or function to the dispatcher for the UI). In any case, feel free to use or adapt my code, or share yours here and if there's an obvious issue I'll point it out. Incidentally, you can set a larger buffer on the socket if you want the operation to complete without looping.
By the way, the only portion of my webserver that's written in C++ is the file I/O code, which I chose to do in C++ rather than .NET because the phone's stunted .NET framework makes it more difficult than I like to access arbitrary file paths. That code is all fairly clean wrappers around the Win32 calls; I suppose I could comment it more but it's very straightforward to read even if you aren't familiar with managed C++. The actual network code is entirely written in C# 4.5. You could actually simplify it a bit for a direct transfer app, too; I wrote it with a lot of multithreading in case I wanted to re-use the code somewhere that might be expected to have more than one client connecting at a time.
Click to expand...
Click to collapse
I am aware that some calls from background threads are not allowed, especially those that have to do with the UI thread.
This is the code for the server. It would seem this one is the problem, somewhere...I just can't see where...
I tried limiting the number of packages sent (that's what the timer is all about).
Code:
public class StateObject
{
// Client socket.
public Socket workSocket = null;
// Size of receive buffer.
public const int BufferSize = 1024;
// Receive buffer.
public byte[] buffer = new byte[BufferSize];
// Received data string.
public StringBuilder sb = new StringBuilder();
}
public class AsynchronousSocketListener
{
// Thread signal.
public static ManualResetEvent allDone = new ManualResetEvent(false);
public static string[] TransferStages = new string[] { "sendmetadataz-length", "sendmetadataz", "file-length", "file" };
public static int Index = -1;
public static List<string> FilePaths = new List<string>();
public static long CurrentStreamPosition = 0;
public static FileStream ifs;
static int pocketspersecond = 0;
static bool LimitExceded = false;
DispatcherTimer timer = new DispatcherTimer();
public static int CurrentArraySize = 0;
public static int FileIndex = 0;
public AsynchronousSocketListener()
{
timer.Interval = TimeSpan.FromSeconds(1);
timer.Tick += timer_Tick;
}
void timer_Tick(object sender, EventArgs e)
{
LimitExceded = false;
}
public static void StartListening()
{
// Data buffer for incoming data.
byte[] bytes = new Byte[StateObject.BufferSize];
// Establish the local endpoint for the socket.
// Note: remember to keep the portnumber updated if you change
// it on here, or on the client
IPEndPoint localEndPoint = new IPEndPoint(IPAddress.Any, 13001);
// Create a TCP/IP socket.
Socket listener = new Socket(AddressFamily.InterNetwork,
SocketType.Stream, ProtocolType.Tcp);
// Bind the socket to the local endpoint and listen for incoming connections.
try
{
listener.Bind(localEndPoint);
listener.Listen(10);
while (true)
{
// Set the event to nonsignaled state.
allDone.Reset();
// Start an asynchronous socket to listen for connections.
Console.WriteLine("Waiting for a connection...");
listener.BeginAccept(
new AsyncCallback(AcceptCallback),
listener);
// Wait until a connection is made before continuing.
allDone.WaitOne();
}
}
catch (Exception e)
{
Console.WriteLine(e.ToString());
}
Console.WriteLine("\nPress ENTER to continue...");
Console.Read();
}
public static void AcceptCallback(IAsyncResult ar)
{
// Signal the main thread to continue.
allDone.Set();
// Get the socket that handles the client request.
Socket listener = (Socket)ar.AsyncState;
Socket handler = listener.EndAccept(ar);
// Create the state object.
StateObject state = new StateObject();
state.workSocket = handler;
handler.BeginReceive(state.buffer, 0, StateObject.BufferSize, 0,
new AsyncCallback(ReadCallback), state);
}
public static void ReadCallback(IAsyncResult ar)
{
String content = String.Empty;
// Retrieve the state object and the handler socket
// from the asynchronous state object.
StateObject state = (StateObject)ar.AsyncState;
Socket handler = state.workSocket;
// Read data from the client socket.
int bytesRead = handler.EndReceive(ar);
if (bytesRead > 0)
{
// There might be more data, so store the data received so far.
state.sb.Append(Encoding.UTF8.GetString(
state.buffer, 0, bytesRead));
// Check for end-of-file tag. If it is not there, read
// more data.
content = state.sb.ToString();
if (content.IndexOf("<EOF>") > -1)
{
// All the data has been read from the
// client. Display it on the console.
Console.WriteLine("Read {0} bytes from socket. \n Data : {1}",
content.Length, content);
// Respond to the client
Send(handler, content);
}
else
{
// Not all data received. Get more.
handler.BeginReceive(state.buffer, 0, StateObject.BufferSize, 0,
new AsyncCallback(ReadCallback), state);
}
}
}
public static void Send(Socket handler, String data)
{
//handler.SendBufferSize = File.ReadAllBytes(@"D:\MUZICA\Activ - Visez.mp3").Length;
// handler.BeginSendFile(@"D:\MUZICA\Activ - Visez.mp3", new AsyncCallback(SendCallback), handler);
#region cotobatura
data = data.Replace("<EOF>", "");
if (data.Contains("sendmetadataz") && data.Contains("length")==false)
{
data = MainWindow.DataContextModel.Files.ElementAt(FileIndex).ToString()+"<EOF>";
byte[] byteData = Encoding.UTF8.GetBytes(data);
// Begin sending the data to the remote device.
handler.BeginSend(byteData, 0, byteData.Length, 0,
new AsyncCallback(SendCallback), handler);
}
else if (data.Contains("sendmetadataz-length"))
{
Index++;
if (Index >= MainWindow.DataContextModel.Files.Count)
{
//FileIndex++;
data = "TransfersComplete<EOF>";
}
data = Encoding.UTF8.GetByteCount((MainWindow.DataContextModel.Files.ElementAt(FileIndex).ToString() + "<EOF>").ToString()).ToString();
byte[] MetaDataLength = Encoding.UTF8.GetBytes(data);
handler.SendBufferSize = MetaDataLength.Length;
handler.BeginSend(MetaDataLength, 0, MetaDataLength.Length, 0, new AsyncCallback(SendCallback), handler);
}
else if (data.Contains("file-length"))
{
ifs = File.Open(MainWindow.DataContextModel.Files.ElementAt(FileIndex).Location, FileMode.Open);
byte[] gugu = Encoding.UTF8.GetBytes(ifs.Length.ToString());
handler.SendBufferSize = gugu.Length;
handler.BeginSend(gugu, 0, gugu.Length, 0, new AsyncCallback(SendCallback), handler);
}
else if (data.Contains("file") && data.Contains("length") == false)
{
//byte[] filedata = File.ReadAllBytes(MainWindow.DataContextModel.Files.ElementAt(FileIndex).Location);
//handler.BeginSend(filedata, 0, filedata.Length, 0,
//new AsyncCallback(SendCallback), handler);
byte[] filedata = new byte[150];
for (int i = 0; i < 150; i++)
{
if (CurrentStreamPosition < ifs.Length)
{
filedata[i] = (byte)ifs.ReadByte();
CurrentStreamPosition++;
CurrentArraySize++;
}
else
{
Array.Resize(ref filedata, CurrentArraySize);
break;
}
CurrentArraySize = 0;
}
// if (pocketspersecond == 25) LimitExceded = true;
//Thread.Sleep(1000);
handler.BeginSend(filedata, 0, filedata.Length, 0, new AsyncCallback(SendCallback), handler);
}
//handler.BeginSendFile(MainWindow.DataContextModel.Files.ElementAt(FileIndex).Location, filedata, null, TransmitFileOptions.ReuseSocket, new AsyncCallback(SendCallback), handler );
// What we want to send back in this application is a game move based on what
// has been received. So we call Play on the GameLogic to give us a move to send back
// data = GameLogic.Play(data);
// Convert the string data to byte data using ASCII encoding.
//byte[] byteData = Encoding.UTF8.GetBytes(data);
// Begin sending the data to the remote device.
//handler.BeginSend(byteData, 0, byteData.Length, 0,
// new AsyncCallback(SendCallback), handler);
#endregion
}
public static void SendCallback(IAsyncResult ar)
{
try
{
// Retrieve the socket from the state object.
Socket handler = (Socket)ar.AsyncState;
// Complete sending the data to the remote device.
int bytesSent = handler.EndSend(ar);
Console.WriteLine("Sent {0} bytes to client.", bytesSent);
handler.Shutdown(SocketShutdown.Both);
handler.Close();
}
catch (Exception e)
{
Console.WriteLine(e.ToString());
}
}
}
This is basically modified from the tick tak toe over sockets sample from MSDN.
The only possible call that would affect the UI is the call to the Console, but the code works fine for a while, after it just crashes.
I tried running the whole thing synchronously on the UI thread, the result appears to be the same.
In the Send method, the first 3 stages work (file-legth, metadata, metadata-length) and a few steps in the file stage (which actually sends the file).
AT some point, I assumed the thread was guilty somehow, but I just can't prove it. Running the thing directly on UI thread does not seem to change anything.
If the async method finishes and the socket gets disposed, the thread would "die".
PS: the entire thing is hosted by a WPF application.

Hmm... OK, there are several bugs here. I'm not sure which, if any, are responsible for the problem. I'd be tempted to overuse try-catch-log (for example, on the Send() function) and debug-print statements, but here are some things I can see that could cause a crash or other unexpected failure:
There is no guarantee that "ifs" is instantiated before use. If you for some reason skip the file-length step, the file step will crash with a null pointer exception.
The entire send function is hugely thread-unsafe. For example, if a second request arrives before you're done servicing the first one (which is entirely possible due to where the event gets signaled) then the values of "ifs" and "CurrentStreamPosition" and so on will be unpredictable at any given time. Since CurrentStreamPosition seems to be monotonically increasing, that's probably not going to cause an out-of-bounds exception, but it could cause you to enter a state where the test "if (CurrentStreamPosition < ifs.Length)" always fails.
The line "data = "TransfersComplete<EOF>";" never does anything; the next line (immediately following it) overwrites that variable. If you cared about that string, too bad.
FileIndex never changes; I hope you're only ever sending one file here...
You don't actually check that the number of bytes sent is the number you meant to send (admittedly, it *should* be, but there are cases where it won't be).
The last 150-byte chunk of every file transfer is truncated to the first byte. This is because "CurrentArraySize" is reset to 0 on every iteration of the byte-read loop (why use a byte-read loop?) so whenever "CurrentStreamPosition < ifs.Length" tests false, the "filedata" array will be resized to one byte (or zero if the file is an exact multiple of 150 bytes, which presumeably be correct).
There are probably more, but that's what jumped out at me (well, and some technically correct stylistic issues, like the "... == false" test). Given that your protocol seems to rely on end-of-message flags, I'm guessing that your problem is that since the last part of the file is almost always truncated, that marker is never getting sent. This probably leads to the client concluding that the server will be sending it more data, which it does by sending another "file" request. The server attempts to respond and immedately hits the CurrentStreamPosition < ifs.Length check, fails, goes to the else case, and tries to send a 1-byte packet containing a NULL byte.
Incidentally, does your file transfer protocol really require that the client request each 150-byte chunk one at a time, using a new TCP connection each time? That's... awfully inefficient.

GoodDayToDie said:
Hmm... OK, there are several bugs here. I'm not sure which, if any, are responsible for the problem. I'd be tempted to overuse try-catch-log (for example, on the Send() function) and debug-print statements, but here are some things I can see that could cause a crash or other unexpected failure:
There is no guarantee that "ifs" is instantiated before use. If you for some reason skip the file-length step, the file step will crash with a null pointer exception.
The entire send function is hugely thread-unsafe. For example, if a second request arrives before you're done servicing the first one (which is entirely possible due to where the event gets signaled) then the values of "ifs" and "CurrentStreamPosition" and so on will be unpredictable at any given time. Since CurrentStreamPosition seems to be monotonically increasing, that's probably not going to cause an out-of-bounds exception, but it could cause you to enter a state where the test "if (CurrentStreamPosition < ifs.Length)" always fails.
The line "data = "TransfersComplete<EOF>";" never does anything; the next line (immediately following it) overwrites that variable. If you cared about that string, too bad.
FileIndex never changes; I hope you're only ever sending one file here...
You don't actually check that the number of bytes sent is the number you meant to send (admittedly, it *should* be, but there are cases where it won't be).
The last 150-byte chunk of every file transfer is truncated to the first byte. This is because "CurrentArraySize" is reset to 0 on every iteration of the byte-read loop (why use a byte-read loop?) so whenever "CurrentStreamPosition < ifs.Length" tests false, the "filedata" array will be resized to one byte (or zero if the file is an exact multiple of 150 bytes, which presumeably be correct).
There are probably more, but that's what jumped out at me (well, and some technically correct stylistic issues, like the "... == false" test). Given that your protocol seems to rely on end-of-message flags, I'm guessing that your problem is that since the last part of the file is almost always truncated, that marker is never getting sent. This probably leads to the client concluding that the server will be sending it more data, which it does by sending another "file" request. The server attempts to respond and immedately hits the CurrentStreamPosition < ifs.Length check, fails, goes to the else case, and tries to send a 1-byte packet containing a NULL byte.
Incidentally, does your file transfer protocol really require that the client request each 150-byte chunk one at a time, using a new TCP connection each time? That's... awfully inefficient.
Click to expand...
Click to collapse
I know it is inefficient, but I'm rather new to sockets. I just want it to get working in a "beta stage" then ill optimize it (hance the FileIndex never increasing, the blatant lack of try-catch blocks).
On the client side, once the bytes in the buffer are processed, the server gets another send that to send the following 150 bytes (i use 150 just for the lulz).
So basically, the workfow is as follows:
ask metadata length >server gives the length >client adjusts buffer>ask metadata
ask metdata >server gives metdata>client processes the data>asks file length
ask file length>server gives file length>client adjusts a huge array of bytes in which the file will reside (i know this is horribly inefficient, but at some point i will write directly to a file stream)>asks for the first 150 bytes in the file.
server gets the request, sends 150 bytes to client>client copies the 150 bytes in the array created earlier, the asks for the next 150.
I am using 150 just to make sure the data never splits in more than one buffer.
When the file transfer occurs, a different message is used to signal the end of transfer. Client side counts the bytes it gets, and when it is equal to the file length, it no longer asks 150 bytes.
The whole thing seems to be safe from crashing until it gets to the part where it sends the file. I am aware that in the code i gave you there's some file streams not getting closed, but i've fixed that and the problem still occurs.
Since The debugger won't help me at all, I decided to use a WCF service instead.

mcosmin222 said:
What do you mean by socket multthreading code? You mean the use of async methods? or having the thread work on background, using the socket?
Click to expand...
Click to collapse
I mean worker threads not async.You will always have to have a thread in the background to "accept". once you accept you "read" in a new thread and the parent thread "accepts" again. Accept will freeze the thread.
On the other side, you simply "connect" and "write" in the same thread.
Read and Write is done in a loop via pre-defined buffers syncronously.
But if you want the server to give a response, the above flow is the other way around, and it is then when things get complicated. (server needs to "connect" and client needs to "accept" over a different set of ports and different threads)
Probably if you want to have reliable connection you will need the server to come back with a response "give me more" or sth.
So, trying to assist, it was my guess that drops or stalls could be because the above flow is not implemented properly.
Edit Oh ho, missed a whole new page so I am sorry if the reply is irrelevant now.
I would suggest you use the sync methods of sockets and not callbacks because is super easier to debug. ThreadPool.QueueSth (ctr + space I dont remember how it's called is your friend to handle threads yourself.
And try to separate pure socket handling from domain handling (lengths, metadata, etc). Send some bytes back and forth, clean-up and then move to domain specific things!

Moving the line that resets CurrentArraySize to outside of the for loop may well sove your problem. I'd try that first.
Optimization involves, among other things, removing try blocks. Unoptimized code, when you're trying to just make thigns work, ought to be full of them.
Don't forget that exceptions will not bubble up the call stack across threads. In addition to threads you create yourself, any async callback will happen on a different thread than the one that called the async function. If an uncaught exception occurs, the thread will die. If enough threads die, the program may crash (or at least hang) due to threadpool exhaustion.

GoodDayToDie said:
Moving the line that resets CurrentArraySize to outside of the for loop may well sove your problem. I'd try that first.
Optimization involves, among other things, removing try blocks. Unoptimized code, when you're trying to just make thigns work, ought to be full of them.
Don't forget that exceptions will not bubble up the call stack across threads. In addition to threads you create yourself, any async callback will happen on a different thread than the one that called the async function. If an uncaught exception occurs, the thread will die. If enough threads die, the program may crash (or at least hang) due to threadpool exhaustion.
Click to expand...
Click to collapse
I avoid try-catch in unoptimized code to see where actual exceptions occur (sometime the debugger doesn't break on exception).
Nop still not working.
The thread still appears to be crashing, even wrapped with try catch.

Do you at least know *which* function it's crashing in? Try putting a breakpoint on each function header and then, when one of them is hit, step through the execution until the thread dies. Work backward from there to find the problem.

GoodDayToDie said:
Do you at least know *which* function it's crashing in? Try putting a breakpoint on each function header and then, when one of them is hit, step through the execution until the thread dies. Work backward from there to find the problem.
Click to expand...
Click to collapse
The send function (the one with the case switch) appears to be crashing.
It executes the function then enters the listening stage (does not execute the callback).