Prev: MDI App: start 2 DocTemplates in CMyApp::InitInstance
Next: How To: CStatubar panel Right-align text
From: David Ching on 3 Apr 2010 13:55 "Mihai N." <nmihai_year_2000(a)yahoo.com> wrote in message news:Xns9D4F51BEAB0FMihaiN(a)207.46.248.16... > >> But I would guess the majority of iPhone apps are iPhone-only, >> and the authors are perfectly fine with that. >> Similar with Win Phone apps, I would think. > > This is just a guess. > But there are many applications that have common code. > Just mentioned browsers, and few others. > For a different light on the common code picture: if you target Silverlight, you can deploy on Windows Phone, Mac desktop, Windows desktop, which is pretty compelling. > It is not only about developers. As a user I want to install whatever > I feel like it. And I don't want Apple to know. Just because. > Not because I do something wrong or illegal, but because it is *my* > device. > > So yes, for me it is a reason enough to buycott. > Do you know if Microsoft is going to be as strict as Apple is regarding this? I haven't heard one way or the other. -- David
From: Mihai N. on 4 Apr 2010 04:49 > That's a not a particularly relevant comparison. How many apps did iPhone > have when it first appeared? Now there are 150K. It is very relevant. Because many of them were ported from the desktop versions. > iPhone apps are written > with Objective C, same as Mac apps. I don't know the answer, but how many > existing Mac apps got easily ported to iPhone? I would guess not many at > all. Well, my guess is quite a few. Btw, you can use C++ on iPhone. Just not for UI. And you can mix and match without many problems. You can completely reuse the C or C++ "engine" and fix redo the UI in Objective C (whitch you might have to do anyway because the interaction is quite different). In porting something like Firefox, what do you thing is the hard part? The HTML parsing and rendering engine, or the UI of the browser? > I'm not sure where this thing about "toy" applications comes from. For me a "non-toy application" is something that takes many tens of thousand lines of code (or hundreds of thousands, or millions). Duck-tapping a data service with some predefined data grid does not and it is still toy. That's my definition. Or put it differently: something a single guy can put together in a couple of weeks is a toy application. This time estimat ignores the cute UI animations that can more than tripple the real coding time :-) By this definition, toy applications are easy to fully rewrite in Objective C, or C#, or Java, or whatever one dreams. > Well, you definitely will be able to load apps through Visual Studio! ;) Really? I don't care about the emulator. > I'm not sure who would run a web server on a phone. There are some crazy people doing that. For instance: http://msdn.microsoft.com/en-us/library/ms834461.aspx :-) Or this: http://www.chilisoftware.net/CompactWebServer/ Or this: http://handheld.softpedia.com/get/Internet-Utilities/Mobile-Web- Server-Free-42332.shtml Or this http://www.cam.com/windowsce.html http://wmpoweruser.com/?p=4387 http://www.mochasoft.dk/freeware/ftpd.htm > Well, you were right to exclude programming language as a valid criteria, > but here are confusing end user functionality with technology with this > list. End user doesn't care, and most likely doesn't even know about, > these technologies, they want what they can provide. No, there is no confusion. I want Perl or a web server to run on my device! (not to develop for the device using Perl) See http://perlce.sourceforge.net/ Any chances someone will rewrite Perl in C# soon? Take away C/C++, you just killed this (and a lot of other useful stuff) > Nothing prevents these capabilities from being exposed to managed code (or > native code for that matter). Whether they are or not is a different > question. No, it is not a different question. We know .NET does not give access to all that's needed, and on desktop there is a need of pinvoke for a lot of things. If I can write C/C++, I can use what I want. If I can only write C#, I am at the mercy of what MS wants to give me. -- Mihai Nita [Microsoft MVP, Visual C++] http://www.mihai-nita.net ------------------------------------------ Replace _year_ with _ to get the real email
From: Mihai N. on 4 Apr 2010 04:58 Anyway, I will stop here. I do believe that Windows and Microsoft in general benefited greatly from being developer friendly. And restricting what developers can do is a bad move, especially when you are the underdog. Apple has the army of funboys that will do whatever Steve tells them is the right thing. And they would throw away Objective C and rewrite their applications from scratch in Ruby, if Steve sais that's the next Apple thing. -- Mihai Nita [Microsoft MVP, Visual C++] http://www.mihai-nita.net ------------------------------------------ Replace _year_ with _ to get the real email
From: David Ching on 4 Apr 2010 10:59 "Mihai N." <nmihai_year_2000(a)yahoo.com> wrote in message news:Xns9D501280016B0MihaiN(a)207.46.248.16... >> iPhone apps are written >> with Objective C, same as Mac apps. I don't know the answer, but how >> many >> existing Mac apps got easily ported to iPhone? I would guess not many at >> all. > > Well, my guess is quite a few. > Btw, you can use C++ on iPhone. Just not for UI. > And you can mix and match without many problems. You can completely reuse > the C or C++ "engine" and fix redo the UI in Objective C (whitch you might > have to do anyway because the interaction is quite different). > > In porting something like Firefox, what do you thing is the hard part? > The HTML parsing and rendering engine, or the UI of the browser? > And how many of these "non-toy" apps are being run on a smartphone? It's a different market, the apps need to do different things, so your definition of a toy app needs to change. The HTML parsing and rendering engine has already been written, you just use it in your apps. > For me a "non-toy application" is something that takes many tens of > thousand lines of code (or hundreds of thousands, or millions). > Duck-tapping a data service with some predefined data grid does not > and it is still toy. > That's my definition. > Or put it differently: something a single guy can put together in a > couple of weeks is a toy application. This time estimat ignores the > cute UI animations that can more than tripple the real coding time :-) > > By this definition, toy applications are easy to fully rewrite > in Objective C, or C#, or Java, or whatever one dreams. > I'm sorry, but that's as arrogant as in 1980's the programmers of DEC, VAX, IBM Mainframes (or Sun workstations) saying PC's were "toys" ignoring apps like VisiCalc and WordStar were being used to get real work done by real people. Of course PC's weren't in the same league as the mainframes but neither were they throwaway toys, and you know what? I have never programmed a mainframe in my entire career, and stayed with these "toys" to produce useful software for many people. So if that's your definition, then it isn't a useful one in terms of evaluating a smartphone platform like Windows Phone. >> Well, you definitely will be able to load apps through Visual Studio! ;) > > Really? I don't care about the emulator. > You have to be able to transfer your app to the phone in order to debug it! >> I'm not sure who would run a web server on a phone. > There are some crazy people doing that. For instance: > http://msdn.microsoft.com/en-us/library/ms834461.aspx > :-) > Or this: http://www.chilisoftware.net/CompactWebServer/ > Or this: http://handheld.softpedia.com/get/Internet-Utilities/Mobile-Web- > Server-Free-42332.shtml > > Or this > http://www.cam.com/windowsce.html > http://wmpoweruser.com/?p=4387 > http://www.mochasoft.dk/freeware/ftpd.htm > > >> Well, you were right to exclude programming language as a valid criteria, >> but here are confusing end user functionality with technology with this >> list. End user doesn't care, and most likely doesn't even know about, >> these technologies, they want what they can provide. > > No, there is no confusion. I want Perl or a web server to run on my > device! > (not to develop for the device using Perl) > See http://perlce.sourceforge.net/ > > Any chances someone will rewrite Perl in C# soon? > Take away C/C++, you just killed this (and a lot of other useful stuff) > If you want these types of things, I agree that MS missed the boat for you. I just had no idea these were the kinds of things you were using to evaluate suitability. They are completely different than mine. I was looking for great tools to write great mobile apps (which by nature have different functionalities AND different presentations, etc.) like what is found on the very popular iPhone, and MS appears to have succeeded in doing that. On top of that, the same app can run cross platform on Mac, and other Windows platforms, both on desktop and in a browser. In 2010, what's not to like about that? This fixation on native things like FTP servers or IP tunneling could be useful in the short term, but long term there will be more elegant replacements to achieve the same goals, if enough people want those types of things. Similar to how many programmers like me used to evaluate PC graphics cards based on how well they showed text in a DOS box because that is where we lived, and did not care too much about how pictures looked (whereas the rest of the world couldn't care about DOS boxes). But over time, our editors got ported to GUI and then we didn't care about DOS boxes anymore. There will be a time when you won't care about whether you can have a FTP server on the device either, if you get easy file transfer some other way. > >> Nothing prevents these capabilities from being exposed to managed code >> (or >> native code for that matter). Whether they are or not is a different >> question. > > No, it is not a different question. > We know .NET does not give access to all that's needed, and on desktop > there is a need of pinvoke for a lot of things. > If I can write C/C++, I can use what I want. > If I can only write C#, I am at the mercy of what MS wants to give me. > These things would be useful to me too, but it is not a deal breaker if I don't have them. A deal breaker for me is having to use Objective C (iPhone) , or having a puny audience the size of Windows Mobile that even then requires massive #ifdef'ing to support all the phones. I used to think there is no way MS could replace an HWND. It was simply too powerful and too customizable to be replaced. But since then, browsers and Silverlight/WPF don't use HWND's any yet offer an even more elegant API that let me do what I want. I suspect MS may yet come up with something that will win you over in the same way. -- David
From: Mihai N. on 5 Apr 2010 04:02
> The HTML parsing and rendering engine has already been written, you just > use it in your apps. And if I want something better than the IE engine? > I'm sorry, but that's as arrogant as in 1980's the programmers of DEC, VAX, > IBM Mainframes (or Sun workstations) saying PC's were "toys" ignoring apps > like VisiCalc and WordStar were being used to get real work done by real > people. Again, it is about the size of the application, not about real work or not, or the usefulness of the application. A unit conversion application is extremely useful, but it is a toy application. I doube VisiCalc was written in a week or had less than 10K lines of code. If you have such a problem with "toy", then replace it with "small" -- To all the rest: I am not talking here as a developer, but as a user. I know what I run on my current WinMo, and I want the same on the future one. And it will take a very long while for a vpn client :-) Same for mapping software, or a pdf viewer. And I want choices. I don't care if there is a browser, or mapping software out of the box. I want to compare and choose what I like most. Being able to use older C/C++ code can give a headstart. Apple is still complaining that people don't rewrite their stuff in Objective C for desktop, after so many years. Apple says "please use my language" while MS says "my way or the hightway" This might be the final nail in the WinMo saga. Can things work with C# only? Yes. I am not bashing C# here. Just the decision to make that the *only* option. But who knows. Let's wait and see who was right. -- Mihai Nita [Microsoft MVP, Visual C++] http://www.mihai-nita.net ------------------------------------------ Replace _year_ with _ to get the real email |