Showing posts with label windows. Show all posts
Showing posts with label windows. Show all posts

Thursday, July 01, 2010

Visual Studio: My build actions are missing


Since this seems to be a faq without an answer: In Visual Studio 2008 (and earlier?) if your project files are missing their Advanced properties - like Build Action - it probably means you were handed a "web application" that is actually a "web site" in Visual Studio parlance. You have to create a new "web application", copy over the source files, and a few other steps to complete the conversion. Some relevant links:

VS 2005: Converting a Web Site Project to a Web Application Project in Visual Studio 2005

VS 2008: Converting VS 2008 Website to Web Application

VS 2010: Converting a Web Site Project to a Web Application Project

Tuesday, June 12, 2007

Safari on Windows, continued


John Gruber was the first person - that I saw - who points out that Apple makes money on Google searches done with Safari's built-in search-box. (i.e. not just browsing to google.com.) That's the angle I was trying to fill in. Apple didn't port Safari just to grow browser share. They didn't do it just to help develop for the iPhone. They did it to make cold hard cash, even if it's not obvious how.

John Gruber's angle and my angle are not mutually exclusive. In order to grow Safari's market share, and the associated search revenues, Apple has to do more than just put it out there and say "we've got the better browser." Firefox and Opera have already been doing that for years. Firefox has had some success with that, Opera less so. Safari now has to compete not only against the incumbent Internet Explorer, but also Firefox and Opera. To entice people, Apple has to create some perceived advantage to using Safari to access some part of "the cloud." .Mac can be the way to do that.

Wait a minute... "perceived advantage" of one browser over another? Isn't that what started the standards wars in the 90s? Well, yes, but that's not at issue here. In the standards wars, Netscape and Microsoft were fighting to control the de facto standards of the entire World Wide Web. If Apple wants to add value to their own web site when viewed with their own browser, so what. Especially if the browser is a free download. Do you feel outrage that the YouTube video player only plays videos from YouTube's own site? Nope.

Helping to develop for the iPhone may be a secondary motivation, but it's not the primary one. I just don't buy that, and here's why: If you're developing a web app with Safari on Windows, you're not developing for the iPhone. You're developing for Safari on Windows. Any web developer worth his salt will tell you that you can't develop for browser X on platform Y and just assume that browser X runs the same on platform Z. Differences in the way the application interacts with the underlying platform APIs can cause subtle bugs. (Or not so subtle!) You must cross-test against each combination of browser and platform. Indeed, the initial surge of Safari/Windows exploits hinges exactly on this fact:


On the OS X platform Apple has enjoyed the same luxury [...] namely intimate operating system knowledge. The integration with the originally intended operating system is tightly defined, but the breadth of knowledge is crippled when the software is released on other systems and mistakes and mishaps occur.

- Thor Larholm


URL protocol handlers on the Windows platform work by executing a process with specific command line arguments. When Apple released Safari for the Windows platform they neglected to implement a proper level of input validation for these arguments

- Thor again

Plus, to take advantage of the iPhone's new hotness, like making calls, you need an iPhone to test that stuff! So you may as well do your early work on the browser with which you are most comfortable. Would Apple like that browser to be Safari? Of course. But from the developer's own perspective, having the iPhone as a deployment target is not a compelling reason by itself to do your early work in Safari.

Monday, June 11, 2007

Safari on Windows - where is this going?


At the D5 conference, Walt Mossberg asked Steve Jobs about iTunes on Windows. Steve Jobs said there have been hundreds of millions of downloads of iTunes for Windows, to which Mossberg said "that makes Apple one of the larger vendors of Windows software." Given today's announcement about Safari on Windows, you almost wonder if Mossberg's question at D5 was a plant.

While Safari on Windows is a neat idea, you have to wonder what Apple is trying to get out of it. iTunes on Windows is a no-brainer - that's the only way to shop the iTunes store, so Apple clearly makes money on it. But what do they get out of porting Safari? Are they trying to take control of the de facto web standards? No, certainly not. In order to do that they would have to (a) take substantial market share from Internet Explorer, which is something that Mozilla hasn't been able to do in 10 years. And (b) they would then also have to wrest enough market share from Firefox so that Apple could dictate standards. Not only is that not going to happen, it's not even worth fighting for, because the RIAs are coming (i.e. Flex, Silverlight, and whoever else jumps into that ring.)

It seems more likely that in the near future, .Mac is going to gain some new capabilities, and even though it will remain cross-browser, I suspect you'll see the really super whiz-bang extras only work with Safari. Since Safari now runs on Windows, this makes every Windows user a potential .Mac customer. When they see their friend with the Macintosh using the super cool .Mac whiz-bangery, some small percentage of them will go ahead and sign up. And as the Long Tail tells us, the Internet is so damn big that a small percentage of any global market returns big bucks. In short, Safari is about to become the loss leader for .Mac in the same way that iTunes is the loss leader for the iTunes store.

If this plays out like Apple wants it to, not only will it grow .Mac revenues, it will also continue to grow the halo effect.

I mentioned this to a couple people and they considered this strategy to be a stretch. And they're right, it is. But it's a stretch that incurs almost no risk to Apple. With iTunes and Boot Camp, Apple has fostered a group of veteran in-house Windows developers. Porting Safari was not a large investment. If Windows users start buying .Mac, hurray, if not, nothing is lost.

Monday, April 09, 2007

What kind of breakdown would your computer have?


When a Mac, or a Linux computer, or a Sun, is broken, there is still a logic to the brokeness. I have tools available to me for inspecting the computer, and I can pursue the symptoms of the problem, and the symptoms lead on a rational path to the cause. In the cases where I can't fix the problem, I at least feel confident that I have exhausted all my options and the machine is truly well boned.

Trying to troubleshoot a Windows computer is like trying to reason with someone who's had a psychotic break:

Me: Hey what's the problem?
Windows XP: I don't have a problem.
Me: Well you're not remembering my preferences. Really, what's the problem?
Windows XP: BLAH BLAH boogity boogity boo BLEE BLAH BLARRRGH!
Me: Can you be more specific?
Windows XP: I don't have a problem.

Here's a good time I had trying to reinstall Norton Systemworks:

Norton: I'm installing... gosh, I can't do it.
Me: Why not?
Norton: I'm not going to tell you. Would you like to rollback or retry?
Me: What's the point of retrying if I don't get a chance to fix the problem?
Norton: Well, those are your choices.
Me: Fine, retry.
Norton: Nope, still can't do it.
Me: Okay, I give up. Roll back the install attempt.
Norton: Heave... ho... nope, I can't do that either.

(Remember when "Norton" meant "unquestionable quality"? Not anymore.)

Saturday, September 30, 2006

VBScript == teh SuxOrz


VBScript sucks in so many - oh, so many! - ways.

The interaction between VBScript and ADO is particularly non-intuitive and bug-ridden. Let me make a note of this one in particular, before I push it down into the part of my brain where it will become just another mote swirling around with all of the other instances of VBScript sucktitude in my memory.

Sometimes you want to know if a field of a database record is NULL, because some VBScript functions like Replace() will choke if you pass them a NULL field. This does not work:


for objField in rsQ.Fields
  if IsNull(objField.Value) then
    strValues = strValues & "NULL,"
  else
    strValues = strValues & "'" & Replace(objField.Value, "'", "''") & "',"
  end if
next
ASP will crash out saying "invalid use of Null: Replace()" even though the value passed the IsNull() check. This, however, works fine:


for objField in rsQ.Fields
  scratchVal = objField.Value
  if IsNull(scratchVal) then
    strValues = strValues & "NULL,"
  else
    strValues = strValues & "'" & Replace(scratchVal, "'", "''") & "',"
  end if
next
One of the nicest projects I ever inherited was from a guy who had done a site in "old" ASP (pre-dotNet) but he did all of the scripting in server-side JScript. It helped that he was a good programmer, but with JScript you spend less time fighting the language. Unfortunately, you can only combine VBScript and JScript under some narrow conditions, so if you inherit a site already done with VBScript you can't just start writing all of your changes in JScript. Even if you fit inside those narrow conditions at the beginning, you'll probably very quickly reach a point where you need to include some JScript into VBScript at a very specific point or vice versa, and the necessary ordering of the code just isn't going to work out.

What you can do that's better yet is to start a gradual migration to ASP.NET, using this really great trick for sharing session state between ASP and ASP.NET on the same server.