I've recently spoken to more and more people who are working with PhoneGap on Windows, so I'm trying to get my own environment (well, my own virtual environment) up to shape. I even have an application I'd like to put out on the Windows app store. I ran into some significant issues with it (the app, not PhoneGap in general) with 2.9 but decided to try it again with 3. I ran into an interesting issue and I want to share it in case others run into it as well.
One of the coolest things about the PhoneGap CLI is that it tells you what SDKs it is ready to use locally. It's a quick way to see if you've got your crap set up right. Here is what I see on my Mac.
Awesome, right? But here is what I see in Windows:
Oh, sad face. Seeing all those question marks, my assumption was that the CLI wasn't able to determine if the SDKs were available or not. Fair enough. I figured I'd check the docs and see if I missed something.
Unfortunately, it turned out to be something far weirder. Captain Obvious (no, seriously, that's his/her name in the Google Group) pointed out that those question marks were actually high ASCII characters. Sending the result of the PhoneGap CLI to a text file and opening with Notepad++ reveals the truth:
Boom. This is already filed as a bug (Issue 155) if you want to track it. I'm still having issues with the CLI on Windows, so expect a follow up later this week.
Archived Comments
Further proof that Windows as a modern development environment continues to fall further and further behind. Switched to OSX years ago for unrelated reasons and I can't imagine ever going back. I may one day switch to Hackintosh, but OSX is amazing for developers.
Really? As I've seen unicode bugs in other apps, other platforms before, this really doesn't seem fair. Don't get me wrong - I prefer OSX too - but I honestly think Win8 is a fine platform and would be great for dev too.
Really.
The windows command line is all but useless, at least in comparison to the developer tools built into and available for *nix (and thus OSX).
Sure, there are various CMD.exe replacements and alternatives, but they all fall short and have integration issues.
Unix-based tools have deep integration throughout the OS and everything "just works" (not the apple kind, this is a bigger, broader, unix thing).
Zsh (and OhMyZsh) and homebrew spring immediately to mind. Then there's just a cornucopia of tiny little tools (with unix, isn't there always?) that have no counterpart on Windows, or if it's there, it's a crappy copy that doesn't have all of the same functionality and changes flags just to be different.
Grep. Awk. Sed. Cron. Curl. The list goes on.
And see - as much as I like OSX, I don't use grep, or awk, or sed, or cron, or curl. :)
And iOS SKD is ready to use locally on windows?
Heh, just noticed that. That seems.... wrong. Going to post to the PG Google group.
I think I am with Raymond on this one. I am a Linux user primarily, but also use a MacAir for iOS dev. I am mentioning this so that you do not incorrectly assume I am a Microsoft Fanboy. Far from it.
This is a bug because it was not tested on anything other than the majority platform (macs these days) or more specifically the developers platform. This is something that we used to complain about Microsoft doing.
Windows (Servers especially) have become much more *nix-like in the last several years. ...but hey are alway a little different than what you might expect when coming from *nix/mac. The Microsoft way. Having run both Linux and Windows servers in production environments I can also say that they can be extremely stable. I am assuming you have not spent much time with powershell. I am guessing that you were pretty deep into the windows world but left quite a while ago. Between CMD and PS there is quite a bit of power there. Take a look at http://ss64.com/ps/ for a command reference; 'Tee' for instance, but also service control and OS integration. Much of the CMD stuff shows its age and just does not 'feel' powerful (it is pretty old). So I am not saying that this is the answer to your needs, or that you need to switch platforms... just that your logic in this case was flawed. 'Everything just works' ONLY when you know how to use it. I love watching Mac first timers as they come from windows... pure frustration.
Windows is being left behind by the current culture of developers. But it is the culture that changed. So talking about shells is really saying you have found the *nix dev approach more comfortable, and I might add more prevalent now. You might have figured out that I actually agree with your choices and end results. I am staying away from windows these days too.
But this is just a bug and it was not related to the power of the platform. If anything the platform led the devs astray ("its works on my machine, so it must be OK").
Raymond, good work on the investigation... I am sure that this likely passed a QA test at Adobe. The question marks look like are a possible value in such a screen - for instance when functionality is not available on some platforms. Without deeper info you wouldn't know.
Cheers to both of you, and continued happy 'gap'ing!
THANK YOU!!! I feel validated or vindicated or something like that. I just abandoned trying to build a project on Windows because people think your an idiot when you are explaining how it doesn't work in Windows development. Like Ian said, nobody bothers to test ON a Windows machine. Not VM but an actual machine running the most widely available Microsoft OS, which incidentally is not 8. Personally I am not a fan of Microsoft for much of anything, but their OS is sort of widely used. I'm not much of an Apple fan either after my experiences with their app approval process. They are freakin apps after all. It's not like they are curing diseases or feeding hungry kids.
Anyway, it seems like at least one person at Phonegap could own a Windows machine and build an app prior to release of a new version.
I've got two other Windows thing to report - just haven't blogged it yet. Will try to do so today.
A related entry for you guys: http://www.raymondcamden.co...
Selecting a Unicode font for use in the cmd.exe environment would have fixed this issue. I know it's not nice this isn't the default, but if you're coming from a *nix environment I'd think finding frustrating defaults and overcoming them is just part of the *xperience?