September, 2006

by MichaelF on September 06, 2006 12:19am

http://www.devreadiness.org

·         Guidance

·         Technical Whitepapers

·         Tools

·         Demos

http://msdn.microsoft.com/windowsvista/reference/appcompat/default.aspx

·         Thirty minute compatibility check

·         Extended feature details

·         Integration guidance

http://msdn.microsoft.com/windowsvista/reference

·        Application compatibility

·        Communications

·         Interoperability and Migration

·         Mobile PC

·         Presentation

·         Security

·         System Services

Recently Mozilla’s Mike Beltzner suggested we provide:  "Something like a checklist of the most common OS integration points that have changed from Windows XP would be extremely useful…"

Turns out there are some useful resources already available, see above, for those interested in developing Open Source applications for Windows Vista or ensuring that their current applications are compatible. 

I took a few minutes to speak with Michael Shaw, Technical Evangelist, to get some additional details on the resources available at the sites listed above.  The following is a short synopsis of our conversation.

What is http://www.devreadiness.org?

MShaw:  The site is an aggregation of tools, whitepapers, presentations and videos intended to help developers understand how to make their existing Windows XP applications compatible with Windows Vista.

Are there other sites aside from devreadiness that developers can turn to?

MShaw:  Yes, but many of the resources available on those sites are either linked from devreadiness or the tools/resources are also located on our site.  Consider this a one-stop shop for Vista application compatibility resources.

Is there anything in particular that those interested should take a look at?

MShaw:  Yes. I would first take a look at the Application Compatibility Cookbook that is located here: http://msdn.microsoft.com/windowsvista/reference/appcompat/default.aspx. This is the first document developers should look at concerning application compatibility. We have identified and addressed the major areas affecting applications when changing from Windows XP to Windows Vista. I’d like to point out the section on Computer Defaults as this is one big area that developers should take a close look to ensure compatibility for users.

Thanks to Michael Shaw for taking the time to talk with us and to Scott Laster who manages these sites.  If you have specific questions about devreadiness or the Application Compatibility Cookbook, let us know.

-Michael

by MichaelF on September 05, 2006 06:01pm

On a recent visit to Thailand I had the opportunity to meet a variety of customers, open source community members, government officials and new Microsoft people.  A great part of my job is the opportunity to understand the state of the software industry in different countries around the world – both in developed and emerging countries.  It’s fascinating to see the patterns of similarities and often surprising to learn about the myriad of country-specific characteristics that influence the evolution and growth of a software industry.  My visit to Thailand was remarkable in both of these areas.  I visited at a time where the government was under some unstable conditions – although the environment is amazingly under control and calm. The state of the Thai software industry is relatively segmented, with some areas quite advanced and some under significant early development.

The role of Microsoft in a country like Thailand is somewhat different than in many large developed countries.  In countries like Thailand, Microsoft participates heavily in the growth and health of the software industry.  Certainly we do this in large countries as well, but it’s much more direct and hands on in countries like Thailand.  Naysayer’s will claim this is so we can just ‘sell more’ to new audiences.  Of course we care about software sales (we’re a commercial software business!) but in these environments we prioritize the condition of the software ecosystem as it’s the basis for any near or future business.  For example, the Microsoft general manager for a country like Thailand (Andrew in the photo below – far right) will spend a good portion of their time working on country-wide initiatives for improved software education, or in cross-vendor forums focusing on improved software security, or in helping the government plan for software infrastructures for future natural disasters (tsunamis, for instance).  What I find interesting, is that many people, particularly in the U.S., don’t often see this side of Microsoft and it is a very important part of our role as a business, community and industry leader to help the entire software ecosystem grow and prosper.

Related to this, one of my trip highlights was a dinner in Bangkok with some of the leading science and technology thinkers in the Thai government around the future of IT in Thailand*.  Below is a photo of (left to right): Dr. Chadamas Tuwasetakul, Assistant to Director, National Electronic and Computer Technology Center (NECTEC); Dr. Pairash Thajchayapong, Senior Advisor to National Science and Technology Development Agency; me; Dr Thaweesak Koanantakool, Director, NECTEC; Andrew McBean, General Manager, Microsoft Thailand.

We had a great discussion about software for children in K-12 classrooms, the benefits and challenges to delivering country-wide computing infrastructure for environments that have numerous IT challenges (such as very few technical support staff).  We also talked about commercial and free software, Microsoft’s position on OSS, standards, interoperability and our future product line – particularly Windows Vista and Office 2007.  It was a great and opinionated discussion and I learned much from Dr. Tuwasetakul, Dr. Thajchayapong, and Dr. Koanantakool, their insight was highly valuable.

The software industry is going through tremendous growth in Thailand.  I feel there is much to be learned from watching these next frontier software ecosystems, to see how they develop their industries in this new era of software economies, how they learn from other economies, countries and trends and most importantly how they create a software legacy that is both prosperous and uniquely Thai.

O’Reilly blogger Allison had an interesting term, technodiversity that I think is a great way of thinking about ecosystem evolution.  I believe strongly that intellectual invention, innovation, and both pragmatic and expressible interoperability are keys to achieving this type of technodiversity.  In an upcoming blog entry I hope to dive more into this area of pragmatic and expressible interoperability to describe why this often fuzzy term ‘interoperability’ is crucial to growing ecosystems.  Warning – expect unusual correlations to trains, newts and other seemingly random but (to be illustrated) relevant examples to the subject.

bill

* To be fair, earlier in the day I spent time with James Clark, long time OSS/XML developer and now part of SIPA (Software Industry Promotion Agency) and the leading OSS promoter in Thailand, and I would include James as one the leading thinkers on software in Thailand as well.

by MichaelF on September 01, 2006 07:19pm

(Special thanks to Dan Simonton & Kyle Adams for the testing and writing of this tech tip)
Have you ever stood in front of a server you are building, feeding it install cds, and thought to yourself “it just doesn’t get any better than this…?”
Me neither.

But look at the bright side: That growing collection of CDRS that are now spilling over the top of the spindle will make an excellent conversation piece when you have guests in your facility. It also makes for an interesting makeshift “jenga” type game. Ok, maybe not. The point is, there are alternatives.

After a growing frustration with having to burn new install discs every time one got a scratch in the wrong place, misplaced, or needing them while they were currently in use, some of the other penguins and I said, “STOP THE INSANITY!!”, and then endeavored to build ourselves a PXE boot server for our lab so we could install our machines on the fly. We anticipate this being a major time saver in the future.

If you live in an IT cave or for some other reason are unfamiliar with PXE boot systems, the acronym itself stands for “Preboot Execution Environment”. It is a boot option that is built into the firmware of the bios on most modern network interface cards. Essentially it is a coupling of dhcp(bootp) and tftp. Basically, a dhcp request is sent out from the client machine, it receives an ip address and a file with instructions to complete the transaction. From here, the install process is initiated. That’s the short version. If you want the long version, look here: http://www.pix.net/software/pxeboot/archive/pxespec.pdf

We set ours up on a machine with a dhcp server, tftp server, and an apache web server. It is possible to setup the PXE system, adding it to the configuration of an existing, authoritative dhcp server, but for the sake of simplicity, we kept ours on a separate machine running RHEL4 AS. If an authoritative DHCP server already exists on the network, it is important that the following option be applied to it’s configuration under the subnet specification:

          ignore bootp;

This ensures it will not attempt to answer requests by the PXE client. Otherwise, any PXE installation you attempt may not make it very far.

On the PXE dhcp server, you will want to setup with the following options

          not authoritative;
            allow bootp;

subnet 192.168.1.0 netmask 255.255.255.0 {
        range dynamic-bootp 192.168.0.200 192.168.0.254;
        max-lease-time 3600;
        default-lease-time 3600;
        option routers 192.168.1.1;
        option subnetmask 255.255.255.0;
        filename "pxelinux.0";
}

We kept the lease time at 1 hour. Once the install is complete (which should only take a third of that time), it won’t need it anymore, so we figured this was sufficient. It is important to note the “not authoritative” option at the top, as this will prevent unintended machines from leasing non-routable ip addresses from the machine.

We then mounted the FC5 iso images on a loopback and copied all of the files over to a directory we created called FC5, under /tftpboot.

          mkdir /tmp/FC5
          mount –o loop FC-5-i386-disc1.iso /tmp/FC5
            cp –r /tmp/FC5/* /tftpboot/FC5

We repeated this process for disc 2-5.

In our /etc/httpd/conf/httpd.conf file, we’ve added the following directory options.

          <Directory /tftpboot/FC5>
  Options Indexes
  AllowOverride None
</Directory>
  Alias /linux /tftpboot/FC5

As the directory specification “FC5” might suggest, we’re using this to install Fedora Core 5 from the PXE server. This specification within the httpd.conf gives Anaconda access to the necessary files to install FC5 via http.

It’s worthy of mention that you can choose to do this for as many operating systems as you wish to install.  We primarily run RHEL4 and Fedora Core 5 systems for the sake of uniformity, so we’ll use RHEL4 in this example. Next we copied  initrd.img and vmlinuz files from both /tftpboot/FC5/isolinux and /tftpboot/RHEL4/isolinux into the upper /tftpboot directory and renamed them according to distribution (rhel4-initrd.img and rhel4-vmlinuz for example).
Next we have to setup the tftp server. If the file does not exist under /etc/xinetd.d, it will need to be created (but most likely, it’s already there). It should have the following options specified:

          service tftp
{
                        socket_type             = dgram
                        protocol                = udp
                        wait                    = yes
                        user                    = root
                        server                  = /usr/sbin/in.tftpd
                        server_args             = -s /tftpboot
                        disable                 = no
                        per_source              = 11
                        cps                     = 100 2
                        flags                   = IPv4
}

Next, create the directory /tftpboot/pxelinux.cfg and make it world-readable. Inside this directory, we need to create eight zero-byte files which represent 192.168.0.254 (use the “touch” command).

touch C
touch C0
touch C0A
touch C0A8
touch C0A80
touch C0A800
touch C0A800F
touch C0A800FE

and lastly, a 9th file for the MAC address, with 01 pre-pended to the beginning

            touch 01-AA-BB-CC-DD-EE-FF

The AA-BB-CC-DD-EE-FF portion of course, replaced with the actual mac address of the interface you will be using.  If you do not have this information, it can be obtained via:

          $ ifconfig

            eth0      Link encap:Ethernet  HWaddr
00:C0:A8:8D:D0:D0
inet addr:192.168.1.1  Bcast:157.55.215.255  Mask:255.255.248.0

Next we create a file called “default” with the following added to it:

          prompt 1
default linux-fc5 ks=http://10.197.173.80/FC5/ks.cfg
timeout 100
label linux-fc5
kernel vmlinuz-fc5
append initrd=initrd-fc5.img ramdisk_size=9216 noapic acpi=off
label linux-rhel4
kernel vmlinuz-rhel4
append initrd=initrd-rhel4.img ramdisk_size=9216 noacpi acpi=off

The options are pretty much the same as you would see in a grub configuration. You can add kickstart file options here if you wish, as noted above. With this configuration, once we reach the PXE linux boot prompt, we can specify either the linux-fc5 or linux-rhel4 to begin the install. If you wish to use a kickstart file, simply specify the location next to the kernel option. As you can see, in our example, it is being taken from an http connection on a different machine. One final step, copy /usr/syslinux/pxelinux.0 into your /tftpboot directory and you should be ready to go.

The final step in the process would be to actually perform an install. On the machine intended for this, go into your bios and place PXE/Network boot in the order before harddrive (if there is an OS present on the machine already). Alternatively, if there is a key-press option (such as f12) on post, you could do that as well. You should see the dhcp client address request progress on screen. Once the address has been obtained, you will see the files specified under /tftpboot/pxelinux.cfg directory load and will get a “boot:” prompt. At this point, specify the label of the kernel you wish to boot (these were defined in your /tftpboot/pxelinux.cfg/default file).  The install process should now begin.

That’s all there is to it.