City of Heroes Legacy Updater no longer in use from August 4

Just running in a browser does not make something a remote application. All this example does is make the browser a local execution environment. As you say, the sandboxing such runtimes have in the browser these days sounds like that could be painful. I am not an AIR developer though, so perhaps not. AIR apps don't have to run in the browser though. In any case, Until very recently I'm not sure AIR had any legs up on .NET for security. It's certainly cross platform.

Let me clarify since I was tired when I wrote that simpler is better post. Here's an example of what I mean.

For a standalone application, minimum requirements are just if you're running this processor and graphics and this OS you're probably fine.

With .NET, or AIR, or Flash, etc, you have the above, plus you have to add on this version of web browser, plus this plug-in or add-on, plus this other add-on that's optional for Windows but required for the first add-on or plug-in. See where it starts getting complicated?

I wasn't disagreeing with that part of your post, so my apologies for not being clear. I was disagreeing with the notion that the launcher/installer didn't have to be a "fat client", or more correctly, that it could be a thin client.

Long-winded exposition follows.

Where I come from a thin client is something that has minimal "business logic" because the guts of what the application does is actually hosted somewhere else. Amazon's online store and Facebook are pervasive examples of thin clients - the actual applications run on those companies' systems, and we just get a thin interface for looking at their applications' output and validating our input to those systems.

As a counter example, if you have any experience with the Dungeons and Dragons 4th Edition Character Builder application, you might know it's a Silverlight application that can run in your browser. It's anything but a thin client. It downloads a crapton of stuff when you launch it and uses that downloaded information to aid you in building your D&D character. Frankly I think this was incredibly stupid, and I don't (just) mean for writing it in Silverlight. It's a fat client you have to have an internet connection to use, instead of a thin client that just displays things that are calculated remotely.

Getting back to CoH, any game installer that honestly installs applications (and installing CoH is more than just copying files) on our computers can't be a "thin client" in the above sense. People sometimes think a "fat client" means it's a complex program that does a ton of things, and it's definitely true our installer/launcher is not doing anything deeply complex. At the same time, it's definitely not a "thin client, because everything serious that it does, like patch our game, it does 100% locally on our desktops. Even if it ran in a browser, like DCUO's, it still would not be a thin client in the sense I describe above. It's just a "fat" (non-thin) app that happens to be hosted in a local browser. And I agree with you that putting such an app in the browser using things like AIR is probably more of a pain for the developers than just letting it be a stand-alone application.

Snow Globe's objection to .NET seems to stem in large part from the fact that it is a desktop runtime. He trusts server-side and thin-client environments. Of course, Java and Adobe AIR are also desktop runtimes. All of them can run in a browser, but that doesn't always mean what they'll be used to write is "thin". Given that CoH itself is a fairly fat C/C++ Windows client that does tons of CPU/GPU-intensive work locally, I can't see anyone writing an installer for it that relies on the runtimes that Snow Globe trusts, barring Flash. (And I don't really trust Flash, though Adobe has made big efforts to improve its security.)

If CoH itself was a browser-based HTML5/WebGL application, all this would be different. In that scenario, it shouldn't even need an installer.

Um, so does Air Applications. Air apps do not run through a browser. Yes, it does have a runtime. However the runtime is not OS-specific in the way .NET is. It functions more like Java (which is also cross-platform).

Again, you seem to have the misconception that Air Apps are browser apps. They are not. Even Java doesn't require a browser to operate in.

Air apps are mostly stand alone desktop applications. For instance, take tweetdeck for an example. It can be a desktop app, an iPhone app, an Android app, or an add-on to Google Chrome. And they are currently testing out Tweetdeck Web. It started as a stand-alone (no browser) desktop app though.

Where Air (or Java) shines is that there is ONE code base to take care of for both Windows and Macs. It also helps the Linux users because the same code works for them too.

My main objection to .NET is the fact that it is so closely entrenched in Windows. Also I hate all the bad programs made with Visual Basic that never seem to be stable (or fast).

I trust cross platform environments more than environments that are exclusive to one platform.

The launcher could be written in C/C++ and have a quarter of the footprint of the current launcher. It would be cross-platform as well. Given the previous launcher lasted nearly 7 years. Would a native app be better than a cross-platform app? Sure. However that means multiple sets of code to maintain.

At any rate, I'm not going to derail this thread further with this topic.

Triumph: White Succubus: 50 Ill/Emp/PF Snow Globe: 50 Ice/FF/Ice Strobe: 50 PB Shi Otomi: 50 Ninja/Ninjistu/GW Stalker My other characters

If you missed my posts above, that's kind of been mostly done already. The Mac Launcher is a standalone application written in Objective-C (it's C-compatible). I mentioned that I wish they'd take that Launcher and build one for Windows that abandons .NET.

I'm aware of all this.

I'm not sure why you think I have this misconception. I only said that these runtimes can be embedded in a browser. That came up because of the mention of DCUO's launcher, and comparisons to HTML5. I use (Windows) desktop applications that have at least some components written in AIR.

Java is absolutely craptastic if you want to do anything OS-specific. I am exposed to this repeatedly in my work, because I frequently write OS and application management tools. Java's implementation of "write once, run anywhere" is a burden that makes it wholly unsuited to these tasks unless you are willing to extend it by calling native binaries or using native libraries via JNI, either of which harms the benefits of using Java to begin with.

I am not familiar with AIR's APIs, but I'm willing to bet it's better about this.

I hate to tell you this, but CoH is, first and foremost, a Windows application.

Also, .NET is not a "VB" library. It's a language agnostic API library that runs in VM concceptually similar to Java's JVM, which happens to be able to front-end a number of languages. (JVMs can too - see Scala.) I think VB is a pretty terrible langauage too, but .NET is not VB.

I can't see any significant, logical reason to base "trust" on this. I am hardly arguing that .NET is better than a cross-platform runtime, either in general or in this case. I don't have issues of "trust" with it over this, however.

It would also have taken longer to develop, taken longer to debug, and still probably have ended up more buggy. I say all this as a skilled C/C++ developer. I prefer C/C++ in most ways, because I am a code hacker at heart, but all managed runtimes are easier to use to produce more stable and well-behaved applications faster than C/C++. I work with lots of developers, and most of them still find ways to create resource leaks and invalid references in languages arguably designed to avoid them. The idea of most of them having to deal with pointers, memory allocators, destructors and the like makes me ill.

Writing the launcher in some managed runtime was the right, practical choice. Choosing .NET on Windows was a reasonable choice, given that CoH is primarily a Windows application, almost certainly with a predominantly Windows install base.

I'll bet you money that the Objective C code used on the Mac can't be cross platform, because it probably uses Mac-specific libraries. If you compile it for Windows, you have to use something like gcc, and you don't have access any more to any of the MacOS graphical libraries, which have no Objective-C equivalent available on Windows that I am aware of. So while it's probably leaner, it's probably not cross platform at all.

Really the only runtime we've talked about that sounds like it would work well cross platform is AIR. An AIR app is still going to have a relatively large footprint, and AIR has some of the same history of insecurity .NET does. (For a while I got security updates for my AIR runtime almost weekly.) That leaves that it's better simply because its cross-platform, which I don't argue. Why didn't they write it in AIR? I don't know, but I consider it likely that it was easier to find a .NET developer faster.

So, let's summarize. You have argued that you hate the launcher, and part of your hate for it is based on it being a .NET application. You've given a number of reasons for this, ranging from its footprint to its (in)security, but the truth is that all these things apply to all the other managed runtime languages. Writing it in a manged runtime language is arguably the sensible choice for any development shop that doesn't want to be debugging the thing constantly. (Note - depending on which version of Objective-C they're using, it may provide them some of these benefits despite being based on C/C++.)

So if the right choice from a practical perspective is to use a managed runtime, the the only valid complaint you've made about the launcher is that using .NET means it's not cross-platform. It looks to me like the only serious contender here was probably AIR, and it was probably just a practical matter that .NET developers are easier to find than AIR ones. Whether Objective-C developers are easier to find than AIR ones, I can't say for sure, but given that you can use Objective-C to write iPhone/iPad apps, it wouldn't surprise me.

Wikipedia has a very good article on the difference between C++ and Objective-C: http://en.wikipedia.org/wiki/Objective-c

The code itself is mostly cross-platform, with a few differences (that's how Apple makes iTunes). The article doesn't cover graphical elements, so I will; they are completely separate from the code, and called Interface Builder objects, which are then linked to the code. So they can be eliminated and replaced with Windows elements if needed.

But that's all less important than this: The Mac NCLauncher has been demonstrated to work. Whatever motivation NC had for making the Windows version in .NET, it's kind of silly to keep it there, maintaining two separate code bases, when they have independent code they can now use, and can eliminate a dependency (and a source of problems with people who can't get it to work) while they're at it.

thanks Cuppa, but i won't buy Windows. also, the command to skip the updater and launch the game directly doesn't appear to be working for myself and others at this time.

Surprise.

As an attempt at an alternative, you could try OS X in Virtualbox.

It ends up being much cheaper.

I admit, it is few more hoops to jump through than I would like for a game... But it is an option.

EDIT to add:
Given how long it took Microsoft to get to that point, the only surprise is that anyone even gives them the chance by testing their latest browsers.

Thanks for the link

One thing I've noticed, espicially lately, when it goes to systems coming into my work with virus infections. 1 maybe 2 out of every 10 systems only use IE as their browser.

Personaly I use IE8, chrome and Firefox in XP mode to test my websites for viewing compatability.

Where to begin?
The NSS Labs' test is about phishing, not other avenues of exploits.

From page 14 of their report (Test procedures):
So they were deliberately excluding exploits.

Again, from page 14 of their report (Test procedures):
They were only targeting social engineering sites that targeted Europeans.

NSS has only been around for the last 3 years, not really long enough to claim any credibility, in fact I'd trust Arcanaville's opinion more than that site. I say this because I've looked at their partners.
Well, I know one of their partners:
TELUS is a phone company.

Also, about the website where you linked to:
This is from neowin's website: http://www.neowin.net/credits/

Oh, an FYI, I use IE 5, 6, 7, and 9 (on various machines). For my personal browsing, I mostly use Chrome these days, followed by Firefox. I used to use Opera, but haven't in a while now.

Triumph: White Succubus: 50 Ill/Emp/PF Snow Globe: 50 Ice/FF/Ice Strobe: 50 PB Shi Otomi: 50 Ninja/Ninjistu/GW Stalker My other characters

Most infections come from phishing attempts when it comes to browsers - I'm surprised you haven't noticed that. You were talking as if you had been helping to take care of these issues.

IE9 isn't as massively insecure as you made it sound. I just grabbed a link to the latest article I remember reading on the subject. I don't want to go digging for more because I think you will have to agree with me that IE is nowhere near as bad as it used to be.

Right, I knew the graphical elements were separate. But what do you replace them with? What's the equivalent on Windows, and how maintainable is it? Who produces commercial (i.e. supported if you find a bug) graphical widgets for Windows C++ applications these days? (That may sound snarky, but it's not - it's a serious question.)

On the Mac, those widgets come from Apple, via the OS's GUI APIs. Certainly Windows has GUI APIs, but building those into something nice looking (edit: using C/C++) is not trivial. Maybe it's not trivial on the Mac either, though I'd be a tad surprised if that's the case. But just because they did it once for the Mac doesn't mean they would to re-engineer the (Mac) interface on Windows. I could easily see maintaining a separate .NET codebase being cheaper.

I really think it may not be that simple. I'm not at all proficient in developing on a Mac, so maybe I'm underestimating the effort they had to put into getting whatever the Mac Launcher's interface looks like to happen, but I think you may be underestimating the effort (and expertise) required to port the UI components of that program to Windows.

The core business logic of the app I do speculate could be common with comparatively little effort. It's the UI I suspect is the deal breaker.

Not really a big surprise, since IE8 and higher gain that security at the expense of being almost totally unusable. I'm actually required to think professionally about things such as browser security, and the only thing I'm usually doing with IE8 is downloading another browser with it.

I have a two by four in my office that is even more secure than IE8 at surfing web sites, and only slightly less useful.

http://www.acidtests.org/

http://forums.whatthetech.com/index.php would beg to differ. Internet Explorer is still the number 1 attack vector for malicious coders looking to compromise an installation of Microsoft Windows.

Context. All browsers have failed the acid test in some way or another in the recent past. Also, of course it is the number one target, as it is still the most used browser in all of history.

In the context of human beings on Earth, IE8 is totally unusable. Technically, you can use it to browse the web, but on a scale of one to ten I would place it a two. I would place calling up a friend, having them enter the URLs I want to visit by hand, and then faxing me the result to be a three.

Mostly because nearly every single security feature in IE8 (and IE9) blocks so many non-malicious activities that I end up turning them all off and losing their benefits anyway. And even then there are things I want to do that I sometimes cannot do because IE8 tells me I can't.

That's just the security side. That doesn't count all the ways IE does things in a completely different way than everyone else, and that way is dumb, and Microsoft refuses to change it. Like FTP cwd root, which I still run into on a regular basis.

True story: the last major rollout I did of IE8 was specifically for a customer that didn't want to ban web browsing in their organization, but didn't really want people browsing a lot. IE8 turns out to be fantastic for that purpose.


Its actually very easy to be perfectly secure: just don't let users do anything. The hard part is being secure while still allowing users to function. IE used to be the browser that let everything happen, and now its the browser that lets nothing happen. In the security space, that's considered a trivial improvement, comparable to the difference between an unpatched computer and an unpatched computer that is turned off.

I still regularly act as a technician and, guess what, most of the viral removals I have to deal with relate to IE.

Heck, I rarely use IE, I have higher than standard Internet settings in IE, I know and use best practices when it comes to phishing/using unknown software and I still found a vector that was embedded in the registry. The vector changed the registry stating the user-agent to a javascript. Installing IE 9 didn't change the user-agent. I had to manually do that myself.

You realize that is like saying that someone is less evil now than they used to be because they only maim people instead of killing them, right?

http://www.embarcadero.com/products/cbuilder

I've used CBuilder in the past, when it was owned by Borland (I still have a copy of 4 professional). It worked great at doing rapid window applications. However I've since moved from desktop to web programming.

Yeah, that is about the only thing I want to do with IE.

It is still a insanely stupid program to use.

Triumph: White Succubus: 50 Ill/Emp/PF Snow Globe: 50 Ice/FF/Ice Strobe: 50 PB Shi Otomi: 50 Ninja/Ninjistu/GW Stalker My other characters