Develop Bugs

Programming ... Whats Best???

Hi!
I'm a Programmer for Visial Basic and Delphi...
I'm not sure whitch system is the best 4 programming the XDA?
AppForge or what?
Thanx
Stevie

Each have their advantages. I would go with Embedded C++ every time, but then, I'm that kind of guy. I like lean code.

On the other hand... If you don't want to learn C++, give Embedded VB a try.

Programming
Hi!
Thanx, but U mean Visual C++ 6.0 ??? Is there anything other what I need with C++ like Appforge 4 VB? Or do I need nothing more?
Stevie

No.. I mean Embedded C++. It is available for free from microsoft
http://msdn.microsoft.com/downloads...=/msdn-files/027/001/963/msdncompositedoc.xml

>I'm not sure whitch system is the best 4 programming the XDA?
>AppForge or what?
I guess it depends on your definition of "best".
I do C++, but actually prefer Visual Basic for most
applications due to the development speed for GUI-based
stuff.
I've downloaded eMbedded Visual Basic and eMbedded C++ from
Microsoft. One problem: EVB apparently does *not* yet
support the XDA architecture (StrongARM).
The SmartPhone SDK from MS *does* support StrongARM (not
*specifically the XDA* that I can tell) but only provides the SDK
for eMbedded C++ (not EVB).
I EMAILed the MobileVB folk and they said:
1) They don't support SmartPhones.
2) They don't have any support for SMS handling.
At this point I guess I'll go to EVC++ unless I can find other
tool(sets) to use.
What *I* would like to see is script support ALA PERL or PYTHON.
Is there anyone out there that knows of a beastie like this?
Or, even better (for me) would be LINUX on the XDA (I've
been using Familiar distro on the iPAQ, and it is great .. can
do GPRS/GPS from a LINUX-based platform (C/C++/JAVA/PERL/PYTHON/whatever).
Charlie

You keep mentioning Smartphone here, and the Smartphone SDK. The XDA does not support the Smartphone SDK, as it is not a Smartphone - it runs Pocket PC 2002 Phone Edition - something completely different.
So please, don't spend several hours downloading the Smartphone SDK to find it's not the right one. Download the Pocket PC 2002 SDK. I have developed several apps for the XDA using this already.

What *I* would like to see is script support ALA PERL or PYTHON.
Is there anyone out there that knows of a beastie like this?
Click to expand...
Click to collapse
There is a PocketPC Python, you have to use the win32api to GUI work, and installation can be a little painful depending on what you need. It does run and is stable though. Check out http://www.murkworks.com/Research/Python/PythonCE/PythonCEWiki/FrontPage[/quote]

Hi guys
I downloaded eMbedded Visual Tools 3.0 from Microsoft, but during installation, I was asked for the Product ID #
Any help ? :?:

I'd like to throw in another suggestion: the .Net Compact Framework. If you're a Delphi programmer (as are we - I used to be on TeamB for Delphi), you'll take to it straight away. After all, .Net and C# was designed by the same Anders Hejlsberg that designed Delphi. C# is very like Object Pascal with a C/Java syntax, but with even more goodies.
We've been using the Compact Framework beta for several months and it is quite simply superb. It was just launched officially on April 26th as part of Visual Studio.Net 2003. However, you don't need to buy Visual Studio - just download the .Net 1.1 SDK from Microsoft - it's free.
It's just a subset of the full .Net Framework, but if you need to do something that's not supported directly in the Framework classes, you can easily call API functions - or even write some code in embedded VC++ and call that. The managed environment is just great.
MikeS.

When prompted for the CD Key, please enter TRT7H-KD36T-FRH8D-6QH8P-VFJHQ
Khang Le
[email protected]

Khang Le, thanks

No DirectX on .Net CF 3.7

I've seen that .Net CF 3.7 doesnt have the directx ( Direct 3d) libraries and i was wondering if microsoft decided to delete them and not continue using directx with .net cf or if it's only because the 3.7 version is a beta and lacks many things.
Apart of that, i don't know what new things has 3.7 version, is there any changelog? because if there aren't important changes, i consider it may be better to continue using .net cf 3.5.

No follow up?
I'm curious if anybody has any more information on this matter. I'm currently using a slightly older version of NRGZ's EnergyROM with a Touch Pro and am unable to use Diamond Hologram because of a TypeLoadException stating that Microsoft.WindowsMobile.DirectX can not be found.
There's a chance that the rip of the unreleased .NET CF 3.7 was incomplete (though the GAC is pretty straightforward) or the pre-release state of it could also be used to rationalize missing assemblies, but if I were to take a random crack at it, I would guess that they're working on XNA for Windows CE/Mobile since it's based on CF and runs on Windows, XBox 360 and Zune it would be a logical step for Microsoft (just as they stopped supporting Managed DirectX on desktop editions), though it does seem a bit unfair to developers of existing applications since the desktop edition was not shipped with the framework, but rather with the DirectX SDK whereas this was deployed in the framework.
Is there a chance that someone could test using the 3.5 version on a 3.7 runtime? If the CLRs are compatible (and they seem to be) then it should still be able to load the assembly, and if binding works at all similar to the desktop framework we could probably just copy it into the directory of the application path, rather than GACing it.

After some searching around this is better discussed in the original CF 3.7 thread since it has been brought up. I'll repost my thoughts there and see if someone can help with experimenting.
http://forum.xda-developers.com/showthread.php?p=4060348

Not sure if this should be posted in the aforementioned thread, but it has long been rumoured that MS would phase out Direct3D by Windows Mobile 7, in favour of OpenGL and OpenGLES. Hope this helps at all.

GL
Well, I'm not so sure MS will ever officially support GL since it's a "competing" product to DirectX. In fact, to me it seems very unlikely. While they have been supporting community solutions and open source work more lately, generally Microsoft makes an effort to have developers use Microsoft technologies which in turn makes applications dependent on Microsoft and therefore users dependent on Microsoft. They have (arguably) the most powerful, useful and time-saving development tools which keeps many developers (like myself) developing applications that are inherently designed for their operating systems.
XNA, on the other hand is a Microsoft technology that is gaining a lot of traction and is directly related to the .NET Compact Framework, which is what leads me to believe they'll choose that route. With the right love and care a single XNA game can be played on PC, XBOX 360 and Zune and it seems likely that supporting the platform that .NET CF was first implemented on is only a matter of time. It's been rather surprising to many in the XNA community that MS hasn't already supported it, since their original press releases strongly indicated support for it. One thing's for sure: while there is an XNA Game Studio built on top of Visual Studio, there will probably not be any MS initiative to build a GL game studio.
http://www.microsoft.com/presspass/press/2004/mar04/03-24xnalaunchpr.mspx

To be fair though, that doesn't necessarily mean they won't implement the Windows Mobile version of XNA using OpenGL ES, though it seems likely that the architecture is designed more toward DirectX. Still hardware manufacturers could play a huge role in this decision.

Which is supported, C# or C++?

Does Windows Mobile support coding in C# or C++, and if both, then which should I use? I'm asking this because I'm currently trying to learn computer programming, and I would like to eventually develop for Windows Mobile, but I'm not sure which programming language it supports. I've heard people say C++ and C#, and I'm confused.
Thanks

In theory you could do either one. Here are some links to get you started.
http://msdn.microsoft.com/en-us/windowsmobile/bb264328.aspx
http://msdn.microsoft.com/en-us/windowsmobile/default.aspx
http://msdn.microsoft.com/en-us/windowsmobile/bb264330.aspx
The last one has some starter kits for both C++ and C#.

Thanks for the help!

C# is a managed environment of course, so it requires the .net compact framework to run. This can lead to issues if the framework you develop for is newer than that which is installed on the device. However, managed code is much easier to write than native code. There is no managed version of C++ tmk.

Sleuth255 said:
C# is a managed environment of course, so it requires the .net compact framework to run. This can lead to issues if the framework you develop for is newer than that which is installed on the device. However, managed code is much easier to write than native code. There is no managed version of C++ tmk.
Click to expand...
Click to collapse
Quite true. Obviously you can write apps with either - but if it was up to me I would probably pick C# and use the latest .net compact framework avail at the time.

If you have knowledge of C++, it's much more powerful, and lots of win32 is the same on Windows Mobile. C# is simpler to do basic user interfaces, but the .Net overheads are far more significant on mobile devices than on desktops.

l3v5y said:
If you have knowledge of C++, it's much more powerful, and lots of win32 is the same on Windows Mobile. C# is simpler to do basic user interfaces, but the .Net overheads are far more significant on mobile devices than on desktops.
Click to expand...
Click to collapse
amen to that.

Extracting Native APIs? Possible...maybe.

Okay, so since the unlocked emulator has a file manager and task manager, does that mean it would be possible to extract them and run them on an actual WP7S device? And if that was possible, would it also be possible to extract the Native APIs from these apps? I'm fairly certain that they use Native APIs because ordinary apps can only access their own directory. I'm not very smart with these things, so sorry if it's obviously impossible or something.

It's wince - the native API is always there, where do you want to extract it from? Also some people figured out most WP7 apps from the emulator ROM are written in native as well. it's always here.
But you can't just put file manager on a WP7 device because there's no access for you to put anything on it, except apps from Marketplace you got the picture? even if we could cook our custom ROMs in the future the only thing we could do is throw in our own DLLs, services or background tools on it and customize it a little. I still doubt you'd be able to develop real WP7 style apps like a file manager or registry editor because the GUI is supposed to be written in Silverlight/XNA. And from those frameworks you can't access the native API unless Microsoft would add support for it.
101% dumb phone. If you think about it then WP7 is even WORSE then iphone.

But what if you could use Visual Studio to load it onto the device? If you look around in it, there is an option for that.

Actual devices will have to be unlocked for developement purposes to allow sideloading through Visual Studio and even then I doubt the system would be able to deploy native code. Developer phone means a yearly fee for membership in the MS developer programm.
I don't think that using native APIs from managed code would be impossible in the SDK - carriers, e.g. will be allowed to use it, but for normal applications the Security Context in .Net would prevent the programm from calling them (Code Security Managers are configurably available in Java and .Net from the beginning, so i believe that would be what MS uses to block access).
And of course programs using those wouldn't get on the marketplace.

Oh, too bad then, but thanks for your response anyway!

Fdo35 said:
Okay, so since the unlocked emulator has a file manager and task manager, does that mean it would be possible to extract them and run them on an actual WP7S device? And if that was possible, would it also be possible to extract the Native APIs from these apps? I'm fairly certain that they use Native APIs because ordinary apps can only access their own directory. I'm not very smart with these things, so sorry if it's obviously impossible or something.
Click to expand...
Click to collapse
Okay, the issue here is the lack of a few key DLLs: Windows 7 Series will not offer GDI most likely (I'm downloading the emulator set now, and will confirm this soon) and will lack comctl32.dll and the like, removing these functions. As it's been stated before, like Windows 7 uses the 6.1 NT Kernel, Windows Phone 7 series uses the 6.5 Windows CE kernel, at least, last that I've heard. It would then be both possible to bring Windows Mobile 6.5 DLLs over, but anything that calls GDI will not work. Solution? Make a mock GDI that uses the new render.
This isn't new either, Windows 7 uses WPF more than ever (Which composes most of the games as well as Windows Media Center), which is a 3D accelerated and fancier way to draw to the screen, and Windows 7's GDI subset has been updated to allow hardware acceleration granted the graphics card allows it (It's actually something the video card driver must tell Windows, as MSDN states)

Deploy native code, no. Run it, of course
I'll be investigating the possibility of native code here shortly. Chances are, you will need to set the target to ARMV6, and set the compile type to Native, not Windows. Most developers, if not all, probably have overlooked this.

I would expect that it'll require privileged access to run native code, so you'll need to solve the code signing problem.

ThymeCypher said:
Okay, the issue here is the lack of a few key DLLs: Windows 7 Series will not offer GDI most likely (I'm downloading the emulator set now, and will confirm this soon) and will lack comctl32.dll and the like, removing these functions. As it's been stated before, like Windows 7 uses the 6.1 NT Kernel, Windows Phone 7 series uses the 6.5 Windows CE kernel, at least, last that I've heard. It would then be both possible to bring Windows Mobile 6.5 DLLs over, but anything that calls GDI will not work. Solution? Make a mock GDI that uses the new render.
Click to expand...
Click to collapse
Well, I doubt things like comctl.dll and some other things like GWES will be that big of an issue once Platform Builder 7 is released and we can just generate these components ourselves. Hell, adding back GDI support (if those rumors aren't just lies) may be as easy as replacing the GWES with a less crippled one generated by Platform Builder. Maybe GDI support is still compiled in but just doesn't output directly to the screen using the default graphics driver implementation. That's how the Dreamcast implementation of Windows CE was. To even see apps like IE on the screen, you need to copy the contents of the standard WinCE GDI output to a DirectDraw surface.
What I'm more worried about is the hackability of the hardware/software. I'm really hoping it's not as insanely locked down to the point to being unhackable like every Zune.

do you think Platform builder is still available for WP7? Since MS won't allow the OEMs to modify the OS I doubt that. Do you have a source? You've seen an announcement from MS or something?

RAMMANN said:
do you think Platform builder is still available for WP7? Since MS won't allow the OEMs to modify the OS I doubt that. Do you have a source? You've seen an announcement from MS or something?
Click to expand...
Click to collapse
Platformbuilder is for the OS, which is Windows CE. There is still some debate as to what version the emulator is running, leaving alone the possibility that the actual version of the OS may be different at release.
If the CE6R3 camp is right, you can get platform builder for that right now, though you wont have telshell.exe (WP7 replacement for explorer.exe), and the WP7 specific apps. It would be an interesting exercise to see if they could be run on CE6R3. If no one beats me to the punch, I plan on trying this for myself when I am less swamped at work.
If the CE7 camp is right, you will have to wait till MS releases that version to the public. And they WILL release it because there are far too many embedded systems outside of phones that run on CE for them to neglect it.

No, I was talking about the generic Windows CE 7.0 Platform Builder and not the OEM specific OAK for WP7S. Unless MS plans to completely drop their generic Embedded Windows CE offerings, I see no reason why PB 7.0 will not be released and help with hacking WP7S (if it is even based on 7.0). You always needed to be a large ODM and sing an NDA to use a Platform Builder addon/OAK for the MS platforms like Pocket PC. Those almost never leak and I can't imagine this would be much different.

RAMMANN said:
do you think Platform builder is still available for WP7? Since MS won't allow the OEMs to modify the OS I doubt that. Do you have a source? You've seen an announcement from MS or something?
Click to expand...
Click to collapse
Yes, platform builder was used to build leaked wp7 arm image.
d:\wm700_6176\platform\common\src
\soc\qcom_v1\oal\power\sleep.c
It is from from nk.exe

use dumpbin.exe to get all methods in dll/exe

[Q] Tablet / Desktop/Phone app compatiblity

Hello:
This is my first posting here and I'll be getting a Surface RT tablet this thanks giving. I have a iMac 2013 running Windows 8.1 and Visual Studio 2013 Ultimate thru MSDN.
I would like to develop Windows Store desktop/tablet/phone apps (using C#, XAML) or Xojo that should run on Surface RT, Surface Pro, Windows Phone, Windows 8, Windows 7, Vista and XP (supporting both 32 bit and 64 bit). I wanted to know whether the desktop apps I'm developing would run on all of these environments or is it limted to run only on Surface variants. The intent of buying a Surface RT is to take it to college while at the same time test the apps on Surface RT and deploy to the Windows store. I'm confused on the ARM and Intel/AMD cpus and do I need to change anything in Visual Studio 2013 config to target these environments.
Please advise.

ARM vs x86 is simple enough to cover quickly. Computer processors always use a particular "instruction set" to tell them what to do. x86 is one instruction set, ARM is another instruction set, an ARM processor of course uses the ARM instruction set and an x86 processor uses the x86 instruction set.
Computer software is usually compiled from human readable source code into machine code which the processor then executes or they are interpreted where a piece of software which has already been compiled via the previous method then reads your source code and processes the output directly (as they rely on existing software, you cant write an operating system in an interpreted language, they are often referred to as scripting languages instead of programming languages but in terms of application software they are sometimes just as capable if just slightly slower). Then standing write in the middle you get the bytecode languages, you take human readable source code and compile it into bytecode, the bytecode essentially being an instruction set for a processor which doesn't exist in hardware, you then take a piece of software called a virtual machine which takes the bytecode and processes the output, sort of a half way between being fully compiled and fully interpreted.
Java compiles to java bytecode for the java virtual machine, as long as you have a functional java virtual machine you can run your java application on any platform (and java is indeed on most desktop operating systems and on multiple instruction sets). C# and Visual Basic .NET both compile to .NET Bytecode for the .NET virtual machine, again, with a functional .NET virtual machine you can run a C# application on any platform (unfortunately only windows (including RT) has microsofts official .NET virtual machine, but mono is compatible and runs on other platforms too). C or C++ are compiled, compiled languages must be compiled for a particular operating system and instruction set. Python, lua or batch are interpreted, as long as you have a functional interpreter they will run on any platform. One thing to take note of, in theory it is possible to take a particular programming language, lets say a compiled one, and then write an interpreter for it instead of a compiler (and there are indeed C interpreters) or an interpreted language and write a compiler for it (has been done too), but we are ignoring that.
Visual studio will build windows applications in C/C++ or it is the IDE of choice for C# or VB.net on .NET. No surface limitations, with plugins (or considering usage of mono on other operating systems) it can even do extra platforms and languages too (I personally use it for python and have used it for arduino microcontrollers). It supports both ARM and x86 for C/C++, I admit I have not tried C/C++ in visual studio for windows software so I dont know if it simply builds your software 2/3 times or if you need to manually select ARM but the drop down for it is in the build configuration manager either way so you can always take a look in there for yourself, for .NET it says Any CPU (it is possible to tell it to make an x86 or ARM only .NET application, I am yet to come across why with the exception of perhaps optimisations). Windows store apps generally have to be done in Visual studio and officially your only options for store apps are C++, C#, VB.net and Javascript.
Store apps in my opinion are *not* a good introduction to programming. Console applications are far better to start off with. Leaves you with an issue, windows RT cannot run any application except store apps without a digital signature attached to the executable, which is great but we have no way of obtaining those signatures ourselves, only microsoft do. End result is that you can compile your C project for ARM from visual studio or take a .NET application, but you cant run it on the RT (which is an ARM device). Useful huh? Someone wrote a jailbreak which removes this restriction, but its for RT 8.0 only, the 8.1 update breaks it.
Also windows store apps are different from windows phone apps. You wont be able to write an app for both. You would have to write 2 entirely seperate apps. Only windows 8, 8.1, RT and RT 8.1 can run store apps. Only windows phone can run windows phone apps. Officially only windows 8 (including 8.1) and below can run desktop. Your cross platform ambitions are just that, ambitions. For 1 beginner, they are unattainable.
Xojo is for web apps, aka glorified websites.