Can I build non-silverlight UI for WP7?
Or how to use as less silverlight as we can in a WP7 app?
These questions probably sound silly... I am actually thinking about the difficulty of migrating a software from other platform.
Yes, you can code wp7 apps in c# or xna (but xna really only applies to games)
Dyskmaster said:
Yes, you can code wp7 apps in c# or xna (but xna really only applies to games)
Click to expand...
Click to collapse
Thanks~~ but does it means I can use win forms.net or lower api to draw the UI?
cswords said:
Can I build non-silverlight UI for WP7?
Or how to use as less silverlight as we can in a WP7 app?
These questions probably sound silly... I am actually thinking about the difficulty of migrating a software from other platform.
Click to expand...
Click to collapse
RTFM, developer.windowsphone.com is your friend.
There is no WinForms for WP7, it's either Silverlight or XNA, that's it.
perdurabo2 said:
RTFM, developer.windowsphone.com is your friend.
There is no WinForms for WP7, it's either Silverlight or XNA, that's it.
Click to expand...
Click to collapse
Thanks a lot. So I am hoping WP7 to support HTML5... Then I can minimize the part of silverlight.
cswords said:
Thanks a lot. So I am hoping WP7 to support HTML5... Then I can minimize the part of silverlight.
Click to expand...
Click to collapse
If you were going to do an HTML5 app, this would likely live in the browser. I suppose you could do a native app with a webview and do most of your logic in html/css/js but that seems like a convoluted way of doing things.
You can use XNA libraries for user controls. There are a lot of them and some of them are free.
cswords said:
These questions probably sound silly... I am actually thinking about the difficulty of migrating a software from other platform.
Click to expand...
Click to collapse
Just thought I'd mention in case you don't know. Microsoft has put together some resources and documentation to help people convert apps from other platforms (e.g. iOS, Android, WebOS) to Windows Phone.
As an example, see below for Android:
http://windowsteamblog.com/windows_...tise-to-build-windows-phone-applications.aspx
And iPhone:
http://windowsteamblog.com/windows_...se-to-build-windows-phone-7-applications.aspx
Related
I am in the process of starting a small firm to create Android applications. Not being a programmer myself, I have no idea what kind of engineer we need to create vacancies for.
So, what are the languages necessary to program for Android?
ftgg99 said:
So, what are the languages necessary to program for Android?
Click to expand...
Click to collapse
I've read that for apps, you need to learn Java, and for Kernels learn C.
Sent from my T-Mobile myTouch 3G Slide using XDA App
As a business owner here is something that might interest you as you will be able to develop cross platform - DragonRad.
Getting ready to try it myself. Best of luck with your search and your new firm ftgg99.
Video 1
Video 2
Video 3
Only drawback I can see is Windoze based only as far as building...use of app is cross platform
Thank you, looks very interesting!
DragonRAD is for building data-driven apps. If you're looking to mobilize your existing back-office data, then DragonRAD is for you. But if you're looking to build games, or 'consumer-type' applications, it may not be. Hope that helps!
Android applications are mainly coded in Java but i believe can also be coded in C++
Although, if you're going to be developing cross platform (iphone, symbian, etc.) you'll need people who can code in a range of different languages.
Qt apps work on WinCE. If WP7 is built on top of WinCE, why would Qt apps not be allowed on Win7?
I'm just trying to make sense of it here. Is it an artificial Microsoft restriction for their platform?
Because third-party apps are managed in .NET compact framework. Qt is a C++ framework and thus unmanaged. This is a smart move by MS as it increases system stability and enhances user experience.
leonard2010 said:
Because third-party apps are managed in .NET compact framework. Qt is a C++ framework and thus unmanaged. This is a smart move by MS as it increases system stability and enhances user experience.
Click to expand...
Click to collapse
If that's the lame reason they give for it not being doable then I will just need to hack Qt onto it. Dumbest move in Nokia's history!
discourse said:
If that's the lame reason they give for it not being doable then I will just need to hack Qt onto it. Dumbest move in Nokia's history!
Click to expand...
Click to collapse
givin that one of the main reasons that windows mobile 6 and for that matter windows desktop can be unstable is poor quality 3rd party programs i think the move was a very good one, forcing programers to stick to strict controls means they have to develop good software, also givin MS got most of the flak for these crap programs i think it was a good move on their part
at the cost of lower performance and code easily being stolen. MS don't care about developers. Hacking a silverlight app onto CE and calling it a new OS was a terrible shortcut and will cost them in the long run.
It's a matter of time until Microsoft releases a Native Development Kit. In a recent interview Brad Watson from Windows Phone 7 Development team said:
Brad Watson said:
8) What about native SDK? Android got theirs later, should we expect Microsoft to provide a native SDK also, or just forget about it ?
BLW – if by native SDK, you are asking will we allow anyone to run C or C++ unmanaged code on the device, the answer is “not now.” Our primary concern is ensuring that there is a fantastic customer experience on the phone. We recently announced that we have satisfaction rates for the phone at 93%. That’s amazing. We attribute at least some of that to the fact that customers can buy apps that they don’t have to worry will trash their phones, and they don’t have to worry because of the managed platform.
Over time we will certainly relax certain restrictions on the phone, but we cannot compromise the integrity of the phone experience or the marketplace experience.
Click to expand...
Click to collapse
Microsoft has to release a NDK because the competition has a NDK. Hopefully the competition will have more and more NDK applications (Firefox, Skype) which would make them more appealing to the user.
When such a NDK will be present, Qt (at least lighthouse) will be ported to Windows Phone 7
indiekiduk said:
at the cost of lower performance and code easily being stolen. MS don't care about developers. Hacking a silverlight app onto CE and calling it a new OS was a terrible shortcut and will cost them in the long run.
Click to expand...
Click to collapse
While I agree it's far from the entirely new OS we were promised I very much doubt it will cost them in the long run. They have provided a OS experience that is second to none, this is all because of the limitations they have put in place.
I would expect the platform to open up somewhat for the next wave of [higher-end] devices giving existing users an iOS-like experience where you can certainly upgrade to utilize multitasking and all that jazz but it will cost you some of the current smoothness of the UX.
The fact that .Net assemblies are easily decompiled into fully working Visual Studio projects hasn't been a huge problem on the desktop and as obfuscating tools become better and better I see no reason why it should lead to a problem on the mobile platform either. Looking thru some of the recent marketplace apps they are all but decipherable for the average developer. Also, as more and more processing moves to the cloud it becomes less and less of a problem - most startups are neither willing not capable of mirroring your closed-source/protected backend services.
The missing NDK is not the sole reason. The OS IS different. As others have pointed out, quite some GDI stuff is just not there, or doesn't do anything. So, Qt would probably just not start. And as there will never be (as MS said) (official) OpenGL drivers on WP7 you can't switch the backend.
And there has to be already some kind of NDK, as e.g. Navigon Select is a semi-native application and it is not created by OEMs.
Hades32 said:
The missing NDK is not the sole reason. The OS IS different. As others have pointed out, quite some GDI stuff is just not there, or doesn't do anything. So, Qt would probably just not start. And as there will never be (as MS said) (official) OpenGL drivers on WP7 you can't switch the backend.
And there has to be already some kind of NDK, as e.g. Navigon Select is a semi-native application and it is not created by OEMs.
Click to expand...
Click to collapse
They say IE9 will have accelerated graphics support, which I presume is based on Direct3D. For WinPhone7 Qt needs a Direct3D backend, which should work on all WinPhone7 devices.
Qt should have the same capabilities of IE9, which AFAIK is not written in managed code.
Qt could also use Google's angleproject which should help in translating "OpenGL ES 2.0 API calls to DirectX 9 API calls".
Since this is a discussion thread, this is going in WP7 General.
~~Tito~~
It will simply not happen. It's that easy. (Not w/o homebrew that is)
By not allowing Qt on WP7, Microsoft and Nokia have just shot themselves in the foot. Instead of offering a smooth migration path for the millions of Nokia users and devs, they've basically alienated the entire community. WP7 is also losing out on thousands of high quality applications like Angry Birds for Symbian^3 and MeeGo that was developed using Nokia's Qt SDK. http://www.youtube.com/watch?v=mS1dwYmKMjs
discourse said:
If that's the lame reason they give for it not being doable then I will just need to hack Qt onto it. Dumbest move in Nokia's history!
Click to expand...
Click to collapse
Good luck hacking Qt into it.
Using .NET also increases Security.
WP7 doens't need Qt, and Microsoft should do whatever it can to stop Nokia from putting Qt in WP7.
Those reasons aren't lame, unless you're missing the portion of you brain that controls logic.
discourse said:
By not allowing Qt on WP7, Microsoft and Nokia have just shot themselves in the foot. Instead of offering a smooth migration path for the millions of Nokia users and devs, they've basically alienated the entire community. WP7 is also losing out on thousands of high quality applications like Angry Birds for Symbian^3 and MeeGo that was developed using Nokia's Qt SDK. http://www.youtube.com/watch?v=mS1dwYmKMjs
Click to expand...
Click to collapse
It's much easier to develop for WP7 than it is for Symbian/Qt. I don't think the developers will have much of an issue with it. They didn't shoot themselves in the foot, you people just AREN'T developers, and don't understand it.
You know you're talking to clueless people when Angry Birds is the epitome o fa high quality application to them.
Cause you cannot develop Angry Birds in XNA, and you seriously believe porting Angry Birds to WP7 will involve nothing other than a few code line changes and a recompilation?
Give me a break.
I wish Microsoft had partnered with SE or something. Nokia's fanbase are more bat**** crazy over these pet projects than the Android people.
Qt will continue to be the development framework for Symbian and Nokia will use Symbian for further devices; continuing to develop strategic applications in Qt for Symbian platform and encouraging application developers to do the same. With 200 million users worldwide and Nokia planning to sell around 150 million more Symbian devices, Symbian still offers unparalleled geographical scale for developers.
Extending the scope of Qt further will be our first MeeGo-related open source device, which we plan to ship later this year. Though our plans for MeeGo have been adapted in light of our planned partnership with Microsoft, that device will be compatible with applications developed within the Qt framework and so give Qt developers a further device to target.
We need to develop a standalone application on a Windows 7 tablet (Motion Computing CL900). Initially Java was the language of choice to develop this application. One criteria is that the tablet is not going to be in Wi-Fi range and will have to be on its own in the field.
if I write it in J2EE/JSP, then I would need a servlet container like tomcat loaded on the device itself. Or I think I could go the Swing route to make it standalone.
But then another person thought, Java is an overkill and just plain HTML5, CSS3, JavaScript (Webkit) will get the job done. The application consists of a form, a signature capture and an image capture using the inbuilt camera.
Since this is my first app on a tablet, I thought I would check around for ideas / pointers. Any feedback would be sincerely appreciated. Thanks.
Since you are doing it for W7, how about using Silverlight?
OndraSter said:
Since you are doing it for W7, how about using Silverlight?
Click to expand...
Click to collapse
The management wants me to develop in a language that we already have the skillsets for. So there are people who know Java and then there are people who are familiar with HTML/CSS/JavaScript. We do not have any developers who are familiar with Silverlight
There is no difference between this and a standard desktop app. Pick the language based on the familiarity of your developers and the quality of the tools.
Can you do things like image captures in standard HTML5?
PG2G said:
There is no difference between this and a standard desktop app. Pick the language based on the familiarity of your developers and the quality of the tools.
Can you do things like image captures in standard HTML5?
Click to expand...
Click to collapse
I don't know much about HTML5, but looks like HTML5/CSS3/JavaScript (library) will form a pretty powerful light-weight combo. I am googling to see if I can do an image capture using HTML5 / HTML & JavaScript
There has been talk of Android shifting to C#, mainly due the Google-Oracle lawsuits over the use of Java. While there rumors haven't been confirmed, there is mono-based C# for Android at http://xamarin.com/monoforandroid but what interests me more is what's on this link: http://hexus.net/mobile/news/android/38789-google-android-ported-java-c-blazing/
At the bottom, of the link, they point to an ICS build of Android based on C#. Though the build isn't yet complete, the second link I've posted contains a comparison from which it can been that C# trumps java... Badly!
The C# build can be found at https://github.com/xamarin/XobotOS
It is called the XobotOS. Has anyone tried this? This is supposed to be a working build.
Here is a snippet of their description:
XobotOS project
===============
XobotOS is a Xamarin research project that explored porting Android
4.0 from Java/Dalvik to C# to explore the performance and memory
footprint benefits of C#.
XobotOS is a semi-automated port of the Android 4.0 source code from
Java to C#. The automated parts were ported using an improved version
of Sharpen that can compile more advanced Java constructs and supports
generics. Most of the manual bits of code fall in two categories (a)
code to integrate with the host operating system and (b) replace the
Java JNI code used to call into C, with the ECMA CLI P/Invoke
functionality.
Click to expand...
Click to collapse
switch
thatd take a lot of developing to switch after so much work has been done in java!
I wonder if is a good idea to move from an open to a closed and corporate environment. How about compatilibity and scalability?.
C#, though made by Microsoft, is supposed to be an open specification. And the mono framework provides an open source platform for C#.
Check this out from Slashgear:
The key difference between Java and the C# and .NET runtime is that the latter two are covered by ISO standards. That means there are legally binding commitments by Microsoft that prevent the software giant from suing implementers for patent infringement.
Click to expand...
Click to collapse
This looks very good: http://xamarin.com/monoforandroid
It's mono for Android. It runs on the current Android versions but it is based on C#. Though this is slightly different from a C# Android, this can provide a unified code base for Android, iPhone and WP7. However, this project isn't free except for evaluation.
I'm wondering if any dev's could try out this port on one of their devices.
yea, I remember mono a how it failed on linux... anyway looks interesting but Im sure is not promising
cpl.Bower said:
yea, I remember mono a how it failed on linux... anyway looks interesting but Im sure is not promising
Click to expand...
Click to collapse
I am no programmer, but I'm glad it failed. I can't imagine Google officially going to port the whole Android to C# and .NET. If they were going to do that, might as well transfer all their Android IP to Microsoft for free to avoid another case like SCO (funded by Microsoft) v Novell.
Anyway, on the recent Oracle v Google case the latter won overall except for a few minor offenses.
I wouldn't personally mind a switch from Java (read: Oracle), but that would be a huge switch for whole community, it might even split it in a way if Google went with this. What about Google Go? I've never used it nor I even know the state of it. Who knows, maybe Google has plans to use in for android in the long run already?
A switch from Oracle's Java to C# which I think is tied to Microsoft wouldn't be a wise thing to do IMO.
The switch to a C# based android would mean better performance and battery life if what they say is true. However doing so is largely impractical and would be a decent alternative only if Google was forced to switch from Java.
As far as the Mono platform goes, it is a godsend for XNA developers. It enables you to retain 80-90% of your codebase between all 3 platforms (android, iOS and WP7) and will greatly reduce porting time if you're writing in C#.
Sent from my Droid Incredible using the XDA app.
Sounds cool, for me anyway since i use unity 3d and program in C# though i though the lawsuit was over between them?
i doubt that google would change android to C# way to much has been done in java think of all the apps that would no longer work.
although the flip side is that it would mean a clean slate for the app store witch means no more bad apps because google could change the restrictions for publishing.
Every app would need to be rebuilt...but hey, you could code for iOS and Android at once!
AceRoom said:
C#, though made by Microsoft, is supposed to be an open specification. And the mono framework provides an open source platform for C#.
Check this out from Slashgear:The key difference between Java and the C# and .NET runtime is that the latter two are covered by ISO standards. That means there are legally binding commitments by Microsoft that prevent the software giant from suing implementers for patent infringement.
Click to expand...
Click to collapse
The ECMA standard is incomplete, and the only actual protection is a "Microsoft Community Promise" which only prevents Microsoft from suing you, not one of the patent trolls which it can, and has already in the past, equipped.
As this article points out:
If Microsoft genuinely wants to reassure free software users that it does not intend to sue them for using Mono, it should grant the public an irrevocable patent license for all of its patents that Mono actually exercises.
Click to expand...
Click to collapse
In short, there are still serious reasons for worrying about C#, despite what they'd like you to believe.
Hmmm.... Basically Microsoft can still come back and screw us over... And they would have reason to since they offer products directly competing with ALL of Google's products. The only reason they probably aren't doing so to Apple is that Microsoft makes products for Apple systems...
And then Apple would come out from nowhere and sue android again for this, claiming they patented it.
♬★------ιƒ ι αgяєє∂ ωιтн уσυ; ωє'∂ вσтн вє ωяσηg シ------ ★♬
java always used to be more advanced than .net, especially back when android was released. but in the past few years .net has really caught up and now greatly surpasses java in both development tools and runtime performance. you can already run android apps written in .net with mono which already outperforms the same application written in java.
also i think csharp is a very easy language to learn and visual studio really makes it easy for new developers. however i dont see google pulling a complete switch like this. especially when the entire android project is based on rapid development (which seems to be working well for them).
I think that if legally everything can work out between Goo and MS about patents etc., would be nice to see some C# Android. .NET and C# are good base to have some improvements. Then again the security issue would escalate sky high and we will be all under the good grace of MS.....
I know this is a potentially dangerous post, but I'm looking for suggestions for things to port. I make no promises that I'll be willing/able to port any suggested software.
Some ground rules before you hit 'reply'
1) Don't ask for Chrome. I won't port it. Period.
2) The source code must be available and not have any _obvious_ specific ties to non-open source code. Eg: some proprietary or closed source library which it depends on.
3) Code must be in C or C++ (I can deal with porting some assembly if needed)
4) Project must be of a _reasonable_ size for 1 person. Honestly, I do this on my own and in my spare time. Some apps can be just massively overwhelming to port. That being sad, sometimes the big ones are also easy.... so use your own judgement here.
5) Tell me why you want it ported. Whats your "use case".
6) Drivers aren't out of the question, but they generally take significantly more work.
Feel free to +1 others suggestions.
Ok.. <puts on protective gear>.. fire away!
Cheers!
Thanks for all your awesome work.
While this isn't an app, I think that the kexec kernel-mode driver idea that was tossed around earlier would be waay more useful than an individual app. Every time it was brought up somebody said "Oh, that won't be much work." And then nobody did anything :-/
So, I'm hugely grateful for the time you put in here, but I think I'd be even huger-ly grateful-er if you opened the door to other OSs.
Sent from my SCH-I535 using xda app-developers app
What would be good is:
http://ekiga.org/download-ekiga-binaries-or-source-code
But I'm pretty sure it uses some libraries not avail
I wish XNA could run on Windows RT. It'd be funny to see Terraria and Magicka on Windows RT...
Firefox would be nice, but without a Thumb-2 JITter, it's not worth it.
Would be nice to have InSSIDer. I use it a lot on my laptop, rather leave it at home.
https://github.com/metageek-llc/inSSIDer-2
Myriachan said:
I wish XNA could run on Windows RT. It'd be funny to see Terraria and Magicka on Windows RT...
Firefox would be nice, but without a Thumb-2 JITter, it's not worth it.
Click to expand...
Click to collapse
I would say to take a look at monogame. It can actually build microsoft store apps including ARM support, so coercing it into functioning on the windows desktop may be possible. Otherwise it might end up being a rule 4 :/
There are hacks out there to run terraria on MonoGame instead of XNA, most of them pretty complete but sometimes have the odd graphical glitch. A full source port to MonoGame would be far more reliable, and actually very simple, but sadly its closed source (although not obfuscated).
One of the supposedly more reliable ones: http://www.terrariaonline.com/threads/wip-monogame-terraria-terraria-for-linux.72997/
Isn't rule one covered by rule four?
SixSixSevenSeven said:
Isn't rule one covered by rule four?
Click to expand...
Click to collapse
No.
People can have bad judgement.. so I'm making an explicit point about Chrome.
Personally i Was really disappointed by the lack of a transmission remote app when i discovered métro interface!
Plus there are many utorrent app...
SO, i think TR Gui source code is available, i think there is many people interested, And i think it will not be too difficult to develop, that can be a wonderfull idea (especially for me ) to make this one
Just found one. TCPMP, this player worked great during the PocketPC/Windows Mobile era. It moved from open source to a commercial different version which is closed source but I believe the link below has the source.
http://www.hpcfactor.com/downloads/tcpmp/
This would bring about a player that supports MKV playback.
lambstone said:
Just found one. TCPMP, this player worked great during the PocketPC/Windows Mobile era. It moved from open source to a commercial different version which is closed source but I believe the link below has the source.
http://www.hpcfactor.com/downloads/tcpmp/
This would bring about a player that supports MKV playback.
Click to expand...
Click to collapse
There is no source code downloadable from that site. All the links are non-existent. Please post the source code if you have it.
Cheers!
bfosterjr said:
There is no source code downloadable from that site. All the links are non-existent. Please post the source code if you have it.
Cheers!
Click to expand...
Click to collapse
Does this help http://code.google.com/p/tcpmp-revive/source/browse/#svn/trunk
mr djé said:
Personally i Was really disappointed by the lack of a transmission remote app when i discovered métro interface!
Plus there are many utorrent app...
SO, i think TR Gui source code is available, i think there is many people interested, And i think it will not be too difficult to develop, that can be a wonderfull idea (especially for me ) to make this one
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=2101891
mr djé said:
Personally i Was really disappointed by the lack of a transmission remote app when i discovered métro interface!
Plus there are many utorrent app...
SO, i think TR Gui source code is available, i think there is many people interested, And i think it will not be too difficult to develop, that can be a wonderfull idea (especially for me ) to make this one
Click to expand...
Click to collapse
I think the problem with the current torrent apps are you either have to pay to get the ability to download files in the background, or the app doesn't support it. I'd like to see a free torrent client that allows background downloading, even if it means speed has to be throttled a bit.
To the OP what is your favorite browser? If it is not Chrome(or Chromium), do you think it is possible to port that browser? At this point I'll even take Safari as I am starting to hate all the crashes that occur for me in IE.
bigsnack said:
I think the problem with the current torrent apps are you either have to pay to get the ability to download files in the background, or the app doesn't support it. I'd like to see a free torrent client that allows background downloading, even if it means speed has to be throttled a bit.
To the OP what is your favorite browser? If it is not Chrome(or Chromium), do you think it is possible to port that browser? At this point I'll even take Safari as I am starting to hate all the crashes that occur for me in IE.
Click to expand...
Click to collapse
Safari is not open source so cannot be ported.
Chrome is a rule 4 - or in other words is too much effort for 1 man to do in a reasonable time frame.
Firefox is also a rule 4, plus its a ***** to get it to compile properly under microsoft tools apparently, plus its javascript engine is raw ARMv7 JIT whereas windows RT bugs with that and would require a THUMB2 JIT. Chrome also would have javascript issues, although in chrome you can have an interpreted javascript engine I think which would just be hideously slow in comparison.
Opera - Closed source.
The list goes on unfortunately. Browsers are complex creatures. Most will come under rule 4 though.
bigsnack said:
I think the problem with the current torrent apps are you either have to pay to get the ability to download files in the background, or the app doesn't support it. I'd like to see a free torrent client that allows background downloading, even if it means speed has to be throttled a bit.
To the OP what is your favorite browser? If it is not Chrome(or Chromium), do you think it is possible to port that browser? At this point I'll even take Safari as I am starting to hate all the crashes that occur for me in IE.
Click to expand...
Click to collapse
What the hell are you doing to get all these crashes? I have yet to have IE crash on 8 or 8.1 on RT in desktop or metro.
My only suggestion would be a gui SFTP client. This is probably the one utility I am currently missing on my Surface RT (I use ssh to remote into Linux systems both for work and personal use, point #5). To clarify, I do use the psftp client in the putty suit, and that works well enough, just takes a bit more time and effort than something like winscp. I can continue to use this if an gui alternative is not feasible.
I recall someone requesting winscp at some point in the past, so I searched around this forum and I did find a couple of people that took a stab at it, but with no results, and I haven't found a clear explanation on what the hang up was. Looking at the readme winscp appears to be written in c++ at least (point #3):
To build WinSCP you need:
- Embarcadero C++ Builder XE2 Professional.
- Copy MFC source code from Borland C++ Builder 6 Professional and
build its Unicode version (see readme_mfc.txt).
- nasm from http://www.nasm.us/
- To build 64-bit version of drag&drop shell extension, you need
Windows Platform SDK:
http://msdn.microsoft.com/en-us/windows/bb980924
Click to expand...
Click to collapse
I am unsure if the aforementioned Windows Platform SDK is available for Windows RT, or if it is even needed since Windows RT is not 64-bit.
Is nasm the problem? It looks to be an x86/x64 assembler... which of course wouldn't work on ARM... unless I just don't get what an assembler is...
Not being much of a coder I also don't know if one can import a Borland C++ project into Visual Studio, so maybe that is also a problem too.
So I guess I'm not sure on a lot of the points on the ground rules list...
domboy said:
My only suggestion would be a gui SFTP client. This is probably the one utility I am currently missing on my Surface RT (I use ssh to remote into Linux systems both for work and personal use, point #5). To clarify, I do use the psftp client in the putty suit, and that works well enough, just takes a bit more time and effort than something like winscp. I can continue to use this if an gui alternative is not feasible.
I recall someone requesting winscp at some point in the past, so I searched around this forum and I did find a couple of people that took a stab at it, but with no results, and I haven't found a clear explanation on what the hang up was. Looking at the readme winscp appears to be written in c++ at least (point #3):
I am unsure if the aforementioned Windows Platform SDK is available for Windows RT, or if it is even needed since Windows RT is not 64-bit.
Is nasm the problem? It looks to be an x86/x64 assembler... which of course wouldn't work on ARM... unless I just don't get what an assembler is...
Not being much of a coder I also don't know if one can import a Borland C++ project into Visual Studio, so maybe that is also a problem too.
So I guess I'm not sure on a lot of the points on the ground rules list...
Click to expand...
Click to collapse
Borland C++ is an alternative set of 3rd part C++ tools. Would take a bit of work to get a borland project to compile it under microsoft tools.
Nasm is an x86/x64 assembler yes. Assembly language is pretty much the lowest level of programming possible before writing in raw hex or binary. It is *HIGHLY* CPU dependent. Specifically the set of commands available in assembly is the plain text form of the exact instruction set the CPU has available which for x86 is different from ARM. The fact that nasm is required means that the project will have assembly in it, therefore an RT port will not be undertaken (one of the rules in the OP).
Sorry man, its proprietary tools and parts of it are unportable anyway. Doesnt mean another SFTP client can't be ported, just this one.
Here's my wishlist. I've poked at some of them, but I don't really have time to finish any of them.
WinPCap - Iirc, the biggest issue was that it was written targeting an older version of NDIS. The usecase would be to provide network support for BOCHS.
QEmu - There's a build of QEmu that builds on MSVC called WinQEmu, but it's dynarec recompiles to x86 only. I believe the official QEmu repo doesn't support MSVC, and I don't know if it can recompile to THUMB-2.
A good IRC client - X-Chat and mIRC run poorly under the emulator, and the few .net clients I've tried are meh. X-Chat has too many GCC-specific requirements, and mIRC isn't open source, I just want a good IRC client.
An X Server - I've been unable to find an X server that builds with MSVC, or anything short of Cygwin for that matter, but I'd love to have one.
Calibre is a good eBook manager I think this is the correct source code https://code.launchpad.net/calibre
I'm not good with this source code stuff so if its to much you dont need to make a port but if you can it would be appreciated thanks
Sent from my SGH-M919 using Tapatalk 4
cx1 said:
What the hell are you doing to get all these crashes? I have yet to have IE crash on 8 or 8.1 on RT in desktop or metro.
Click to expand...
Click to collapse
Browsing news sites and/or using Spotify.