An introduction to the new Palm OS & CMS

...before read my next topic, "PalmSource to build Palm OS on Linux", I would rather explain the new Palm OS based on Linux & CMS as an introduction in a FAQ...

Q. Can you give some background on CMS?
A. China MobileSoft Limited is a Bermuda-based holding company, founded in 2000, which owns 100% of MobileSoft Technology (Nanjing), the Chinese operating company. MobileSoft Technology was approved as a Wholly-Foreign Owned Enterprise (“WFOE”) under Chinese law in 2001. A WFOE qualifies for government incentives and is legally treated as a domestic company in China, even though it is funded from overseas. MobileSoft Technology offers a broad range of mobile phone software, from low end to high end. CCID Consulting, an arm of the Chinese Ministry of Information Industry, named the company one of the “30 Chinese Software Enterprises with the Most Growth Potential.”

Q. What are CMS' products?
A. CMS currently offers its customers a wide range of software for mobile phones, including more than a dozen phone applications, operating software for smart and feature phones, and has been developing a version of Linux optimized for mobile devices. In the future, the phone applications and phone software will be able to take advantage of the Palm OS® look and feel and data compatibility, extending the Palm OS ease-of-use to all classes of mobile phones, and will be made available worldwide. CMS and PalmSource customers will continue to be able to customize the user interface to meet the needs of their markets.

Q. Does Palm OS for Linux replace current versions of Palm OS?
A. This is an addition to our line, not a replacement. Other versions of Palm OS continue to be available. As always, we'll make decisions on their future growth path based on feedback from our licensees and other partners.

Q. Will this delay delivery of devices running Palm OS Cobalt?
A. No. Palm OS® Cobalt version 6.1 is already finished, and the software is in the hands of licensees. We expect devices based on it to ship in 2005.

Q. Why Linux?
A. PalmSource's business model has always been based on shared innovation and enabling partners to innovate. The Linux community has the same philosophy, so we think we're a good match for each other.

We think by offering Palm OS for Linux, we can attract more licensees and developers, create more new devices, and bring in more users than either could on its own. Linux has a large community of developers who innovate rapidly and support new technologies aggressively, far faster than any proprietary operating system company can on its own. We bring an award-winning user interface, software frameworks-based on the best of Palm OS® and BeOS®, a large base of professional and consumer applications, and a community of more than 25 million enthusiastic users and over 360,000 registered developers. We believe we can help mobile Linux move beyond the embedded space, and grow rapidly in the consumer and enterprise mobile markets.

We believe that together we'll have the technological and market critical mass to challenge, and beat, even the biggest proprietary operating system companies in the mobile market.

Q. Will existing applications continue to run?
A. We intend to continue to offer the Palm OS® Application Compatibility Environment (PACE), allowing properly written Palm OS 68k applications to run on future versions of the operating system.

Q. When will Palm OS for Linux ship?
A. We intend to provide more information at our developer conference in the Spring.

Q. If you're not shipping yet, why announce now that you’ll support Linux?
A. Our partners -- developers, licensees, operators, chip vendors, and so on -- need to know the long-term future of our software. The development cycle for mobile devices can be very long (for example, some of our licensees plan products up to two years ahead). This happens with almost all platforms. For example, Symbian has announced Symbian OS version 8, but most Symbian products are still based on Symbian 6. And Microsoft has been talking about the next version of Windows for years.

PalmSource to build Palm OS on Linux

...before read this article you may need read the previous topic, "An introduction to the new Palm OS & CMS".Take a look at, I write it down as a FAQ for easily reading, such as a fast track.

PalmSource is to create a new version of the Palm OS with Linux at its core, the company said today after announcing a plan to buy Chinese phone software company China MobileSoft (CMS) ...

With the device market becoming increasingly phone-centric, and with the Chinese market offering a far greater opportunity to device vendors - and their suppliers, like PalmSource - than Europe and North America, it's not hard to see the OS developer's interest in the region.
PalmSource already has a smart phone OS, but it believes CMS code will allow it to extend its reach further downmarket into more basic voice-oriented models. CMS has built a phone platform, mfone, on the back of a home-brewed, ARM- and MIPs-oriented embedded version of Linux, mLinux, and a selection of the usual comms and PIM apps. All these components will be the Palm OS look and feel - and, crucially, data compatibility - over time. What's planned is no mere GUI swap - more the replacement with PalmSource code of CMS' application and that part of the OS sitting above the Linux kernel. Some CMS technology, particularly in the telephony area, may well find its way into the Palm OS.
PalmSource is also likely to take full advantage of Linux's strength in chipset and device support, the better to improve its OS' ability to offer wireless connectivity, such as Wi-Fi and Bluetooth, which if PalmOne and SanDisk's attempts to ship WLAN add-ons are anything to go by, currently need some improvement. Some Linux APIs will be exposed to PalmOS programmers.
Palm's 68k emulation model will be ported to Linux, PalmSource said, to ensure full compatibility with older apps. Software written for Palm OS 6 - aka Cobalt - using the Protein API will probably just need to be recompiled, the company said.
Like Apple with Mac OS X, PalmSource will keep all the top-layer code proprietary, but it will release any changes it makes to the underlying Linux code - for faster boot times and battery life preservation systems, for example - available to the open source community.

Targeting low-end phones

PalmSource will clearly pitch the result as a more open alternative to Symbian and Microsoft's phone operating systems. But it may also improve PalmSource's ability to attract handset makers looking for a less complex operating system than those that typically power smart phones. Not only Symbian and Windows Mobile, but the Palm OS too is generally seen as unsuitable for low-end, low-resource devices. So far only a small percentage of the world's mobile phones fall into the 'smart' category.
While that may not matter to the Nokia's of this world, already equipped with suitable OS technology, it is likely to appeal to companies keen to break into the developing phone markets, and who are more willing to license the technology they need.
If they want a full-featured product, PalmSource has its currently shipping Palm OS 5-based Garnet OS, along with Cobalt. For customers who want something more open, there will be the CMS-derived Linux version, too, replicate Cobalt's feature-set, PalmSource insiders tell us.
CMS' focus on China should help PalmSource's moves in that geographic direction. For all CMS' interest in that market, it was co-founded and is run by Silicon Valley folk, so there should be a good cultural fit with PalmSource. CMS' China sales and R&D operation is run as a subsidiary, MobileSoft Technology (Nanjing), which PalmSource also plans to acquire - doubling its number of engineers at stroke. PalmSource CEO David Nagel was keen to point out that the results of the joint development work will not be restricted to Chinese ODMs - European and North American customers will be welcomed too.
However, it remains the case that many of the device makers most keen on adopting Linux are based in the Far East. Interestingly, it's been actual and potential customers who have pushed for Linux adoption, rather than PalmSource itself, Nagel told The Register.
CMS software is today shipping on 30 Chinese handset designs and has signed ten ODM licences, so its not exactly short of customers.
The deal depends on shareholder and regulatory approval, of course, but if it goes ahead, PalmSource will issue 1,570,000 shares which it will swap for CMS equity. The transaction is anticipated to close before the end of PalmSource's third fiscal quarter, ending 28 February 28 2005.

PalmSource will then be able to announce a 'Palm on Linux' release schedule at its developer conference next Spring. ®

How to use Java to connect with HTTP servers outside your corporate firewall

Summary
This tip will show you how to write Java applications that can get past your corporate proxy and access Web servers on the Internet. Adding proxy support to your Java applications involves writing just a few additional lines of code and doesn't rely on any security "loopholes."

Almost every company is concerned with protecting its internal network from hackers and thieves. One common security measure is to completely disconnect the corporate network from the Internet. If the bad guys can't connect to any of your machines, they can't hack into them. The unfortunate side effect of this tactic is that internal users can't access external Internet servers, like Yahoo or JavaWorld. To address this problem, network administrators often install something called a "proxy server." Essentially, a proxy is a service that sits between the Internet and the internal network and manages connections between the two worlds. Proxies help reduce outside security threats while still allowing internal users to access Internet services. While Java makes it easy to write Internet clients, these clients are useless unless they can get past your proxy. Fortunately, Java makes it easy to work with proxies -- if you know the magic words, that is.

The secret to combining Java and proxies lies in activating certain system properties in the Java runtime. These properties appear to be undocumented, and are whispered between programmers as part of the Java folklore. In order to work with a proxy, your Java application needs to specify information about the proxy itself as well as specify user information for authentication purposes. In your program, before you begin to work with any Internet protocols, you'll need to add the following lines:

System.getProperties().put( "proxySet", "true" );
System.getProperties().put( "proxyHost", "myProxyMachineName" );
System.getProperties().put( "proxyPort", "85" );


The first line above tells Java that you'll be using a proxy for your connections, the second line specifies the machine that the proxy lives on, and the third line indicates what port the proxy is listening on. Some proxies require a user to type in a username and password before Internet access is granted. You've probably encountered this behavior if you use a Web browser behind a firewall. Here's how to perform the authentication:

URLConnection connection = url.openConnection();
String password = "username:password";
String encodedPassword = base64Encode( password );
connection.setRequestProperty( "Proxy-Authorization", encodedPassword );


The idea behind the above code fragment is that you must adjust your HTTP header to send out your user information. This is achieved with the setRequestProperty() call. This method allows you to manipulate the HTTP headers before the request is sent out. HTTP requires the user name and password to be base64 encoded. Luckily, there are a couple of public domain APIs that will perform the encoding for you (see the Resources section).

As you can see, there's not a whole lot to adding proxy support to your Java application. Given what you now know, and a little research (you'll have to find out how your proxy handles the protocol you're interested in and how to deal with user authentication), you can implement your proxy with other protocols.

Proxying FTP
Scott D. Taylor sent in the magic incantation to deal with proxying the FTP protocol:

defaultProperties.put( "ftpProxySet", "true" );
defaultProperties.put( "ftpProxyHost", "proxy-host-name" );
defaultProperties.put( "ftpProxyPort", "85" );


You can then access the files URLs using the "ftp" protocol via something like:

URL url = new URL("ftp://ftp.netscape.com/pub/navigator/3.04/windows/readme.txt" );


If anybody has examples of using a proxy with other Internet protocols, I'd love to see them.

Note: Has only been tested with JDK 1.1.4.

Follow-up Tips!

from Marla Bonar: For those still using JDK 1.1.7 (with WebSphere 3.0), setting the system properties for proxyHost and proxyPort does not work; conn.getInputStream() either returns with Connection timed out or No route to host. However, I was able to work around this problem by using the URL constructor that takes the Host and Port as parameters (using my proxy host and port): public URL(String protocol, String host, int port, String file). from Dylan Walsh: The method for providing authentication via username and password does not work. "Basic " should be at the start of the authentication string; for example: String encodedPassword = base64Encode( password ); should be: String encodedPassword = "Basic " + base64Encode( password ); Also you don't need a separate program to do the base64 encode. You can use the sun.misc.BASE64Encoder() class instead. Here is what the code looks like with both changes: System.getProperties().put("proxySet", "true"); System.getProperties().put("proxyHost", proxyHost); System.getProperties().put("proxyPort", proxyPort); String authString = "userid:password"; String auth = "Basic " + new sun.misc.BASE64Encoder ().encode(authString.getBytes()); URL url = new URL("http://java.sun.com/"); URLConnection conn = url.openConnection(); conn.setRequestProperty("Proxy-Authorization", auth); from Marcel Oerlemans: Here's how you use Socks 4 proxy servers: System.getProperty("socksProxySet", true); System.getProperty("socksProxyHost", proxyHostName); System.getProperty("socksProxyPort", proxyPort); Usually the proxyPort for Socks 4 is port 1080 You can then make your connection using Socks4.

Resources

• java.lang.System
  http://www.javasoft.com/products/jdk/1.1/docs/api/java.lang.System.html
• java.net.URLConnection
  http://www.javasoft.com/products/jdk/1.1/docs/api/java.net.URLConnection.html
• HTTP Client API
  http://www.innovation.ch/java/HTTPClient/
• Cabletron Systems
  http://www.cabletron.com/
• CsProxy (a free proxy server)
  http://www.cabletron.com/csproxy/
• Relevant RFCs
  http://www.cabletron.com/csproxy/handbook/rfc/

Top Ten Virus Monthly Report

Top ten virus November 2004

E1 Technology

Q: What's E1 exactly?What does it mean & how it works?Please explain in brief & complete.
A: E1 is the European equivalent to the American T1. Although both E1 and T1 use 64 kbps channels, they differ in many aspects. E1 is a point-to-point, dedicated, 2.048 Mbps communications circuit that carries 32 channels contrasted with T1's 24 channels. Of these 32 channels, 30 channels transmit voice and data. Unlike T1, E1 always provides clear channel 64 kbps channels.
Of the two remaining channels, one uses time slot 16 and is used for signaling and carrying line supervision (such as whether the telephones are on-hook or off-hook). The other remaining channel uses time slot 0, and is used for synchronization, channel control, and framing control.
There are two options for the physical media:
* 120 ohm twisted pair cabling, typically foil shielded. This is called a balanced interface and uses a DB-15 or 8-pin modular connector.
* 75 ohm coaxial cable. This is called an unbalanced interface because the two conductors do not have an equal impedance to ground, and uses a BNC connector.

Supernetting

...Today I decide to talk about "Supernetting".If you are working on BGP you may need to read this, even for experts, maybe you want to know the basic.

Supernetting (known as CIDR, too) allows the use of multiple IP networks on the same interface. It is the reverse of subnetting, which allows the use of a single IP network on multiple interfaces.
Officially, supernetting is the term used when multiple network addresses of the same Class are combined into blocks. If the IP networks are contiguous, you may be able to use a supernet. If the IP networks are not contiguous, you would need to use sub-interfaces. These are not currently supported on Compatible Systems routers but are supported on routers from Cisco Systems.
A prerequisite for supernetting is that the network addresses be consecutive and that they fall on the correct boundaries. To combine two Class C networks, the first address' third octet must be evenly divisible by 2. If you would like to supernet 8 networks, the mask would be 255.255.248.0 and the first address' third octet needs to be evenly divisible by 8. For example, 198.41.15.0 and 198.41.16.0 could NOT be combined into a supernet, but you would be able to combine 198.41.18.0 and 198.41.19.0 into a supernet.
An IP address is a 32-bit number (4 bytes, called "octets", separated by periods, commonly called "dots.") Supernetting is most often used to combine Class C addresses (the first octet has values from 192 through 223). A single Class C IP network has 24 bits for the network portion of the IP address, and 8 bits for the host portion of the IP address. This gives a possibility of 256 hosts within a Class C IP network (2^8=256).
The subnet mask for a Class C IP network is normally 255.255.255.0. To use a supernet, the number of bits used for the subnet mask is REDUCED. For example, by using a 23 bit mask (255.255.254.0 -- 23 bits for the network portion of the IP network, and 9 bits for the host portion), you effectively create a single IP network with 512 addresses. Supernetting, or combining blocks of IP networks, is the basis for most routing protocols currently used on the Internet.
For Example: Two Class "C" network numbers of 198.41.78.0 and 198.41.79.0
The addresses pass the prerequisites. They are consecutive and the third octet of the first address is divisible by 2 (78 Mod 2 = 0). To further illustrate what is being done, let's look at the addresses in binary. The third octet of the first address (78) is 01001110. The second (79) is 01001111. The binaries are the same except for the last bit of the address (the 24th bit of the IP address). The 78 network is supernet 0 and the 79 network is supernet 1.
The subnet mask for this example supernet is 23 bits, or 255.255.254.0. ALL devices on the network MUST be using this subnet mask. Any device that is not using this subnet mask would be unreachable.
The broadcast address for ALL devices on the example supernet is 198.41.79.255. Most modern devices don't require you to fill out the broadcast address, as it can be deduced from the IP address and the subnet mask. The broadcast address is used as a special destination signifying ALL hosts on the network.
As with any IP network, the first number in the range (.0 in a class "C") has special significance, and can't be assigned to any hosts on the network. The first number in the range is referred to as the "network number". Conversely, the last, or highest number in the range (.255 in a class "C") is called the broadcast address, and also can't be used by any host on the network.
Because of these unique addresses, it would probably be wise not to use the 198.41.78.255 and 198.41.79.0 addresses (in the above example), even though these SHOULD be perfectly legal addresses for hosts when using a supernet.
There is one additional prerequisite for supernetting, you MUST EITHER be running static routing EVERYWHERE or be using a classless routing protocol such as RIP2 (or OSPF) which include subnet mask information and can pass supernetting information in order for this to work. Standard RIP does not transmit the subnet mask information.
If you are using Compatible Systems Routers then you should check that you are running a router ROM version later than 3.0.7 to have the supernetting feature fully implemented.