1a) You can use SSH via Wifi if you don’t have that many photos to transfer

1b) If you have a LOT of movies and photos, use a USB file transfer utility like iFunBox to transfer the Photos back into /User/Media/DCIM/100APPLE

2) Now for the critical part, merely transferring the photos back into the directory above will not cause them to show up in the Camera Roll.  What you need to do as well is to delete some of the stuff inside /User/Media/PhotoData (or to play it safe, copy them into a directory called, say, Original/).

According to this page, you only need to delete two .plist and two .sqlite files.  (Under iOS 5.0.1 on my 3GS, only one .plist file under /User/Media/PhotoData/MISC seems to exist and it was named DCIM_APPLE.plist.)  In my case, I moved over all the files under /User/Media/PhotoData to a backup directory and then recreated just the directory structure, remembering to chown mobile.mobile all these newly created directories.

3) Now, reboot your iPhone and call up the Photos app.  At this point, nothing will still show up because iOS is busy recreating the files you deleted. You should wait for a few minutes (the more stuff you have, the longer you should wait), then the next time you go into the Photos/Camera Roll app, you should now see your old photos and movies!

Starting with Windows 8, all new development going forward is expected to take place with WinRT being the lowest level developer-accessible API. The way I understand it, newer iterations of the .NET Framework will be relying on WinRT underneath. As per [1], WinRT will be a COM-based API albeit supposedly more evolved.

In Stroustrup’s C++ FAQ [2], when asked what he thinks of C++/CLI – which is a way to get C++ to talk to the CLR, he characterizes it thus:

“C++/CLI … essentially augments C++ with a separate language feature for each feature of CLI (interfaces, properties, generics, pointers, inheritance, enumerations, etc…”

The above is essentially what it takes to get C++ to grok the CLR object model!

Thinking about the above, I suddenly realize that before Microsoft invented the One True Runtime To Bind Them All, C++ turned out to be SO INADEQUATE A SYSTEMS LANGUAGE that they essentially had to layer a whole infrastructure on top of it – COM – with its own huuuge panoply of conventions [3], in order to make it possible to use as an API substrate for the newer stuff they wanted to make available to Windows developers. Recall that COM was introduced because the more vanilla C++-based APIs, e.g. MFC, turned out to be inadequate (I have a very good reference discussing this which I can’t seem to recall right now…).

As a COM developer, you not only had to master the already humongous list of C++ dos and dont’s, you then had to do the same for COM’s conventions… but you basically have no choice if you intended to take advantage of Windows APIs from C++.

If one looks at the evolution of C++-based APIs on Linux, pretty much the same issues arise. VANILLA (if you could call the hideous chopsuey of syntax and conventions that is C++ ‘vanilla’) C++ alone NEVER CUTS IT, everyone has to layer some BIG piece of proprietary plumbing on top of it to get work done. You’ve got Qt with its meta object compiler moc (and god-knows-what-else), KDE with its DCOP, Mozilla’s XPCOM (and just for writing a browser!) etc…

Basically, each of these project/environment comes with its own reinvented object model/environment conventions that you have to pick up in addition to C++! So much for the notion of “C++ code portability”…

I believe much of the gunk above has to do with the lack of DYNAMIC BINDING in C++. It seems that Jobs, Tevanian, et al… made the right call way, way back when NeXTStep was born.

There seem to be two roads that one could have taken:

1) Objective-C with its “one syntax addition” and few dozen keyword additions to C, enabling dynamic dispatch and the other goodies of the Smalltalk object model (including concise, no-nonsense reflection facilities) to interoperate intimately with C.

2) Deal with all the gunk in C++ and then, additionally, reinvent a memory management model (e.g. reference counting in COM), method dispatch, reflection, and on and on and on and on… to put on top of C++.

In OS X, just about the only place where C++ lives is as a glorified template language (chuckle) for – ironically enough – device driver writing (to avoid the copy-paste of common driver code) in IOKit [4]. And this in the form of Stroustrup’s much hated Embedded C++ [5], while the rest of the APIs are implemented as either pure C (e.g. the CoreXXXXXX APIs) or Objective-C.

References:

[1] http://mdavey.wordpress.com/2011/09/19/win8-more-thoughts-on-winrt-projections-and-possible-roadmap/
[2] http://www2.research.att.com/~bs/bs_faq.html
[3] http://books.google.com/books/about/Essential_COM.html?id=kfRWvKSePmAC
[4] @18:15 – http://www.youtube.com/watch?v=-7GMHB3Plc8
[5] http://www2.research.att.com/~bs/bs_faq.html#EC++

After digesting the above, I’m suddenly a bit apprehensive about whether Microsoft know what they’re doing or not. The fact that they keep changing their API surface suggests, in fact, that they don’t.

In here we read that “Microsoft says it ‘reimagined’ every aspect of Windows, this new runtime, or application model” which seems to be an accurate characterization of WinRT.

The distressing part comes in the fact that WinRT is intended to replace Win32. WinRT definitely sounds like it adopts similar goals of iOS – sandboxing, asynchronous APIs, etc… which I agree are appropriate and modern abstractions suited to a mobile OS.

However, the big question is just how appropriate are these goals for a desktop OS?? The sandboxing is going to boost security even further and the asynchronous APIs are arguably much better suited for mobile UI idioms. However, the unstated caveat is that these models make programming considerably more tedious in many ways compared to the “old way” of doing things.

My main beef here with the way Microsoft are approaching things is that they seem to be reactionary whereas Apple are going about things in a far more deliberate and methodical manner. Apple seem to recognize that desktop Cocoa needs to maintain its character separate from iOS Cocoa Touch while they slowly sort out the best way to eventually merge both (IF even possible). Microsoft, on the other hand, seem to be basically saying to its developers to completely abandon the traditional desktop programming model asap. This really seems to me to be jumping the gun.

Granted, the CLR, while introduced amidst a great deal of resistance and whining, eventually proved to be an amazing platform going forward (but remember this was only when Jim Hugunin discovered – accidentally, in essence! - that it was great for implementing dynamic languages on) and the same may eventually come to apply to WinRT’s paradigms, but the roughshod way Microsoft are introducing/positioning this new API is definitely going to incur backlash and resistance whereas Apple’s attempts at merging their desktop and mobile APIs seem to be going far more smoothly and naturally among its developer community.

Is this more a problem with how Microsoft are communicating with their developers or does this really point to a “platform evolution ethic” over at Microsoft that is not as well-honed as Apple’s?

Apple have the sanest API/platform evolution and the best IDE. I have hated IDEs ever since they first came out in the 90s. Xcode circa 3.2 is the first IDE I will deign to use and frankly I find it amazing. Many reviews criticized Xcode for being crappy compared to Visual Studio and I could not fathom why so many people said the same thing, when I found Xcode’s auto-completion, etc… to be superior to Visual Studio’s. I later realized it wasn’t until Xcode 3.2 that Apple finally got it right. Visual Studio would have been fine, but that blasted PoS crashes on me even when I’m just doing something as innocuous as tweaking color syntax highlighting. As for Eclipse (what Android developers use), it is certainly supposed to have everything but the kitchen sink, but my impression is that it is even less elegant than Visual Studio and the UI exhibits the lag so typical of Java apps (at least this was how I remember it when using it for Flex).

Microsoft’s .Net CLR is by far the most advanced platform to program under and waaaaay ahead of Objective-C. Objective-C was the most advanced platform by far back when NeXT was just introduced (compared to the Stone Age Win32/MFC and pre-Stone Age OS 8/9 development tools) and this is what makes it still (barely) bearable to develop for today. But someone who’s used to programming under, say, Python or Ruby (both available under .NET) is going to kick, swear, and scream when taken back to the Bronze Age of Objective-C programming. C# programmers (Iron Age ;-D) might not kick or scream as much but will still definitely find plenty to cuss about.

HOWEVER – and this is the big caveat - it sadly seems to be the case that garbage collection – much less utilizing a VM – is still untenable on today’s mobile hardware. iOS programs have astoundingly smooth and responsive animation in comparison to the crApp available for Android. All the widely hyped JIT compiler advances for Java  just still can’t cut it for games up to this day. The next generation of Windows 8 Metro-based apps will developed using either .NET or JIT-compiled Javascript. Both of these technologies are VM-based and use GC and will definitely be easier for the programmer but it remains to be seen if games written with them will be as terribly jerky as for Android or if they will approach or – I fervently hope – equal the seamlessly smooth animation of games on iOS.

What is notable is how Microsoft opted to go with a (re-?)implementation of Javascript that runs on its own VM(?) as opposed to a CLR-based one (e.g. interestingly enough –  not the Javascript.NET which was already around before). This is very telling and it may hint at some specialized speed improvements.  Google may hype their JIT technology (e.g. V8 et al) to the high heavens, but the performance of games on Android tells us that their JIT technology is still a long, long, long way from native code performance.

On the other hand, while Microsoft is relatively quiet about their JIT work (or perhaps only because they eschew Youtube for Channel9), few people know that one of the most performant Java JIT-compiling VM ever made was the one Microsoft made for IE circa v4/v5 and that this remained faster than many Hotspot JVMs that came much later (and perhaps even to this day?).  Microsoft seems to have some superb compiler engineers and this may be (big maybe) why they have elected to go with a non-.NET Javascript on top of WinRT rather than use the CLR which, we hope, will be good enough for fast action games.  I think it is pretty obvious by now that the CLR – while clearly the technology of the future – still introduces too much overhead to get good performance on mobile hardware.

On the other hand, if Windows 8 action games will still need to be coded in C++, I think I’ll happily use Objective-C first and wait for the hardware to catch up to the CLR before venturing into games for the Metro environment. C++ is lipstick on a pig, garish and hideous, whereas Objective-C’s minimalist additions to C syntax together with its sanely designed runtime and library, are actually a significant enhancement over C even if still far from the convenience of its VM-based competitors – C#, Ruby, Python, etc…

I think that going forward, considering the following,

a) James Gosling and Jim Hugunin being on board Google
b) Google being a Java shop as much as it is a Python one
c) Java on JVM being controlled by Oracle (NOT a good thing)
d) dominance of Android and hence assured proliferation of Java the language, *BUT*, on the Dalvik VM rather than the JVM

I’d like to make a bold prediction:

Google plan (or *should* be planning) to enhance the Dalvik VM  to one day equal and eventually surpass the JVM’s abilities and give .NET/CLR a run for its money.

Jim Hugunin is very familiar with the advantages of .NET’s multilanguage hosting ability and it would be extremely ironic if he did not advocate the same for Dalvik ultimately.

If James Gosling is the architect behind Hotspot (is he though?), then Google have the key people they need to move the Android environment forward in preparation for the eventual extinction of the Microsoft ecosystem.

It should be painfully obvious to all but the most ostrich-headed observers within Microsoft that their company is not making the right moves anywhere near fast enough in the mobile area to stem the Android tsunami.  While it is likely that Windows Phone 7 may eventually be able to basically *buy* some market share (15-20% at least) in the phone area, what does this leave for the tablet/slate area for which Windows 7 (or any other Win32/64-based OS for that matter) is a very poor fit?  Apple was the first company to start actualizing the benefits of integrating across desktop, mobile, and phone, and Google are doing very well at bringing the latter two together (but still sucks at the first), whereas Microsoft still seem to be rather clueless as to how to play the otherwise excellent card (e.g. .NET) they hold.

The future will belong to whichever one of the 3 companies is able to cement all three environments under a unified development and app/media delivery platform.  (RIM should just forget it and go Android or WP7, and I predict they eventually will, but only once their market share has gone below 20%… or if Microsoft decides to offer them a Nokia-like deal, but either way, short of a revolutionary reinvention, RIM is destined to become a niche player in the smartphone/mobile device arena)  Currently, even though Apple is a bit ahead of the game by offering an App Store under OS X, my bet is on Google, because they are the ones who have the momentum in the emerging mobile and phone markets.  Linux has all but confirmed its viability for desktop usage so I feel that Google can make one major fumble with ChromeOS (which I think they are already in the process of making) and still be in a good position overall.

Initially, I thought that Apple, despite the stingy closedness of their ecosystem, stood a chance at dominating the future, but the new batch of excellent Android slates plus the dominance of Android on the phone market tells me that it is Google which stands to inherit the throne of Platform Emperor that Microsoft has been steadily relinquishing.  (Is it really coincidental that Google is starting to backtrack on the “Don’t be Evil?” mantra? e.g. Honeycomb’s “delayed” open-source release…)  It also seems likely that iPad 2 represents the peak of Apple slate/tablet market share, in the same way that iPhone 4 (maybe even 3GS) was for smartphone market share and that it’s all downhill from here on for Apple.

If the prediction I made at the start of the article is correct and Google do intend to evolve DalvikVM along the lines of the CLR, then they will at last possess the one remaining important trump card that only MS has right now.  Once this happens – barring a miraculous surge in MID (mobile internet device) market share for Microsoft – then the fate of Microsoft will have been sealed, while Google’s future will be all but cemented.

It is, in fact, very hard right now to see how Microsoft can win.  First, Microsoft don’t have a credible slate OS (not even a rumor of one on the horizon).  No amount of artificially purchased marketshare in the smartphone area will compensate for the lack of a proper slate OS to synergize with. Apple’s iOS confirmed the importance of this synergy and Google was very quick to realize the same.  When will Microsoft realize that a proper slate OS just cannot be Windows-desktop-based (or at least not Windows-desktop-UI based)?!  Now, even if Microsoft ultimately wakes up to their senses (this looks like it will be some time in the far future) and come up with a proper touch-supporting UI, they will still definitely have to bribe/buy market share, e.g. strike a deal to have their mobile OS on dominant slate devices like Kindle and Nook and Galaxy Tab, just to be able to remain relevant in an Android-dominated world.

If the prediction that DalvikVM will eventually evolve into a CLR-like multi-language hosting managed environment is not just wishful thinking, there in fact, remains just one reason for anyone to still root for Microsoft today, the fact that they seem to be the only ones around who believe in supporting the pen input mode. While I don’t see what incentive Google will have to support pen input, this differentiation alone will definitely not be enough to save Microsoft.

Microsoft really really need to get their mobile device strategy straightened out or they will confine themselves to a static or ever shrinking desktop device market share.  If Microsoft keeps executing in this lackluster manner, Apple is going to leverage their dominance of mobile device market *and* media distribution (e.g. iTunes and a reinvented, revitalized AppleTV) and use this to continue chomping away slowly but surely at the desktop market as well.

The new reality is that Microsoft no longer holds all the cards. Here are the “cards” that matter and who has them

0. Desktop/server – Microsoft are the desktop kings, and have some penetration in the server space.

A. Mobile phones – Google who now have more Android devices out there, then Apple, who still put out the more polished platform.

B. Mobile devices – Still owned by Apple, with the iPad, we will see when Android 3.0 comes out

What does Microsoft have for A. and B.?  Sadly, nothing strategic that Apple or Google haven’t already delivered.   Apart from the spiffier new UI, everything else is just copy-cat from Apple. Windows Phone 7 might win MS a bit of market share, but if Apple deliver with their rumored touch-driven iMac and further integrates iOS and OS X development, Microsoft will be in real danger of completely dropping the ball, strategically speaking.  Heck, there was a time when I laughed at the notion of Apple being able to beat Microsoft in the desktop market share, but today, Jobs’ reality distortion field has gotten soooo strong, I can even imagine Apple eventually competing with Microsoft in the server space!!

Apple completely understand that mobile phones and mobile devices are two quite different markets but for which having a shared development environment is essential to leveraging developer productivity. Hence, the use of a single iOS for what are essentially both ARM-based platforms just with different screen sizes.

Microsoft, on the other hand, seem to think that pen-based tablets and touch-based slates can be driven by Windows 7. They do have some great technologies for pen-based computing which are still considerably more advanced than Apple’s (cursive handwriting recognition – which OS X lacks – and usable speech recognition). But they have a blind spot when it comes to touch. The iOS/iPhone/iPod/iPad UI experience proves that touch requires a very different approach.

Microsoft have to execute a multi-pronged strategy whereby they combine the strengths of the Windows desktop ecosystem (drivers + .NET APIs), their pen-based technologies (voice and handwriting recognition), and the Surface/Courier UI innovations which they seem to have so foolishly cast by the wayside!!

Push out industrial strength tablet/slates running Windows 7 but with a touch-centric UI instead of Explorer (easily done).  These devices, by being able run the whole gamut of Windows desktop software as well as more touch-friendly Silverlight apps (whose ecosystem can be shared with Windows Phone 7 devices), should make both developers and end-users think really really hard about whether to commit to the iPad’s proprietary (but otherwise excellent) platform or stick with the ginormous universe of Windows/.NET tools and apps.  Windows is the one foot in the past and the desktop/server niche while Silverlight/desktop CLR points the way to the mobile device future.

Figure out how to scale the Zune/Windows Phone 7 UI metaphor to lower-spec’ed tablet/slates running Windows Phone 7 (or some mobile variant thereof).  Microsoft’s ace-up-the-sleeve is STILL .NET and its unparalleled multiple language interoperability.  Neither Google nor Apple are going to have anything like this in the near future, and this is the single most important thing that matters which  can still lure developers to Microsoft’s platforms.

Today’s 1Ghz low power devices should be able to run desktop CLR with some competence already, and the next-gen should be when Silverlight/desktop CLR based apps can finally start to shine and make sense.

C. The Web / Cloud – Time and again, Microsoft have proven that they STILL do not get get the web! Google’s much hyped “first wave” of “innovations”, e.g. Froogle, Google Checkout, Google Wave, SOAP-based APIs etc… have proven to be mostly duds. However, I believe Google have learned from their mistakes and that there is an up-and-coming next wave of innovations from Google that will put them so far ahead of Microsoft that it would make the latter realize that they should just give up on the cloud/web. While Microsoft is still struggling to figure out the Web (sigh…), Google are already well on their way to colonizing the The Cloud.

Google Docs is one of the few post-search engine innovations from Google which did turn out to have promise and it is a cloud technology. Besides this, you have Cloud APIs such as the Google Prediction API for which Microsoft really has no idea what these are about or for (or maybe they are doing such a poor job at marketing it, that developers remain unaware of them). While MS have done a lot of great engineering on their monolithic Visual Studio environment and made spectacular progress on their relatively open .NET development environment, these are STILL desktop-centric technologies whereas Google are obviously gunning for a future where applications live across the cloud. Applications of the future will not run on single machines, rather they will be “mashup”-driven and leverage APIs provided by 3rd parties analogous to how developers link in 3rd-party libraries to their apps today, the difference being that this time the linkage is “across the cloud”.

Looking at the new bunch of Google APIs, it is obvious they intend to finally bring the formerly half-delivered and half-baked promises of RPC/SOAP to developers everywhere (and not just enterprise niches) and via the far more enlightened REST paradigm.

Finally we get to search, where Bing is really turning out to be yet-another-dud despite the promising initial hype.  Meanwhile, Google continually applies spectacular refinements to their search experience (such as Google Instant Search) making it harder and harder for either Yahoo or Bing to catch up.  Search is core to Google in the same way that Windows is core to Microsoft, and at this point, I think Microsoft have nearly as much chance of being able to topple Google in Search as Google can of toppling Microsoft when it comes to the desktop OS – meaning, of course, close to zero.  If you can see, Google took a different route to attacking MS’ dominance of platforms (e.g. it took the mobile route… and ended up butting heads with Apple), so perhaps Microsoft really have to rethink their strategy as well.  My bet would be to somehow bring together social networking, the graph-based Semantic Web and something like Wolfram Alpha and use that to define the future of search rather than a futile attempt at copy-catting the current Google search engine experience.  Much as Google knew to target mobile devices rather than compete with MS on the desktop, MS should be smart enough to avoid tackling Google head on in Search as well.

Hardware-wise, the Asus EEE Pad proves that it is possible to run Win7 on a pad/slate. However there are two other important things that distinguish the slate experience from the desktop experience which Microsoft should pay attention to:

1) Fast “boot-up” speed – In reality this is actually just a fast restore-from-hibernate/suspend, so while Windows 7 may still not be as fast as an iPhone/iPad/Android device turning on, it might come close.

2) Touch/Gesture friendly UI – This can be as simple as just replacing Explorer with a touch-friendly version supporting gestures. Of course you will also need apps that are touch-compatible, but such apps written for Windows Phone 7 can easily run unmodified on Windows 7 as well as long as they are written for Silverlight and/or other CLR environments.

I also believe there will be a market for pen and touch based devices. People want to be able to draw and write notes and Apple has not addressed this market properly at all. The big question is if it will be possible to have a display that can be as smoothly responsive as a capacitive touchscreen is and supports precise pen input at the same time.

If Windows 7 can incorporate the above suggestions, we can get the best of all possible worlds.  A UI and OS power on/off response that can match the Android/iOS experience while retaining the tremendous advantages of being compatible with the desktop Windows ecosystem.  Microsoft, get to work!

Sun’s financial troubles meant that selling to Oracle was a proposition very difficult for the former’s shareholders to resist. Oracle’s products have a strategic dependence on Java so it also made a lot of sense for Oracle to do the acquisition (ownership of MySQL just made the whole package an even sweeter deal.)  However, I don’t see how Oracle’s corporate culture can be compatible with Java’s future as a general development platform.  Oracle is focused as a database company and will most certainly drive Java’s development in directions that mainly benefit the Oracle product ecosystem. This can’t help but be to the detriment of the Java platform’s abilities in areas that don’t directly have to do with these ends.  Many have blogged about the exodus of Sun’s top architects post-Oracle. This, to me, just paints a pretty clear picture of the overall trend.

It’s going to be a long time before Java completely fades away, and it is going to remain entrenched in the “enterprise” sector, but as a platform for all-purpose development, Java has been losing appeal for sometime now and I think this is the final nail in its coffin.

This  clears the way for Adobe’s Flash/Flex and .NET to duke it out in the desktop space. Nibbling at their heels (more like slithering up their feet already), are Apple’s iPhone/iPad OS and Android. Android developers can take heart in the fact that Android is only Java in the slightest sense such that Oracle owning the standard will barely matter to them. But of course, at the same time, Android is so barely Java that the ecosystem of the latter only has the slightest intersection with and of  benefit to Android. If a technology like Clojure for the CLR  eventually overtakes the maturity of Clojure for the JVM, I’d consider the prediction – and the fate of Java’s relevance to general computing – sealed.

The most likely reason you are getting billed for internet usage that you don’t believe you’re using is actually rather simple but easily overlooked, and it is: ADVERTISEMENT SERVED BY FREE APPS! Whenever an application shows an ad it loads it from the net and if you do not have wifi turned on, it will do a data connect using either 3G or GPRS (so turning off 3G will not help).  One way to make sure you don’t connect is to just stick an invalid Access Point Name (APN) in Settings -> General -> Network -> Cellular Data Network. If you have SBSettings, you can enable toggling of 3G and EDGE and toggle both off which is a more elegant of turning your data connection off as well as making it faster to turn on as well.

But… the withdrawal has to take place in PHP, which means your USD will be converted into PHP before being deposited to your account. Currently, you cannot withdraw USD even to a Philippines based USD account. Unfortunately, the exchange rate Paypal uses is terrible (2% supposedly). See http://www.yugatech.com/blog/the-internet/the-mysterious-php200-paypal-withdrawal-fee/

So how does one get around this? Well, what you can do is withdraw your Paypal balance into a USD account in a US bank. But how does one get a US bank account?? Ever since 9/11, opening a US bank account if you are a non-US resident has become very very difficult. If you do a search for “non-resident US bank account”, you will get a LOT of shady sites offering the info on how to do this (if you pay them). I ignore them all. Instead some more diligent searching reveals the following articles on how to solve the Paypal to USD withdrawal problem:

Opening an Etrade account is a widely suggested method:

http://www.mydigitallife.info/2008/03/19/how-to-add-etrade-investment-brokerage-trading-account-as-paypal-bank-account-for-withdrawal-and-deposit/

http://moneyblogger.net/blog/three-methods-to-withdraw-paypal-fund/

There are caveats to Etrade however, one of which is a USD40/quarter “Account Service Fee”, which is waived based on the following conditions:

https://us.etrade.com/e/t/estation/pricing?id=1206010000#AAF

Opening an E*Trade may be considerably easier than opening a US bank account but it supposedly serves as the same thing for the purposes of Paypal withdrawal.  Since this might be a loophole, I’m not sure if they will eventually close it.

If you don’t mind withdrawing as PHP, a list of banks and their bank codes are shown here: http://pages.ebay.ph/bankwithdrawal/bank_codes_ph.html and replicated below

ALLIED BANKING CORP 010320013
AUSTRALIA NEW ZEALAND 010700015
ASIA UNITED BANK 011020011
BANGKO SENTRAL NG PILIPINAS 010030015
BANGKOK BANK 010670019
BANK OF AMERICA 010120019
BANK OF CHINA 011140014
BANK OF TOKYO 010460012
BANCO DE ORO (& EPCIB) 010530667
BANK OF COMMERCE 010440016
BANK OF THE PHIL ISLANDS 010040018
CHINA BANKING CORP 010100013
CHINA TRUST COMML BANK 010690015
CITIBANK N.A. 010070017
DEVT BANK OF THE PHILS 010590018
DEUTSCHE BANK 010650013
EAST WEST BANK 010620014
EXPORT & INDUSTRY BANK 010860010
FUJI BANK 010640010
HONGKONG AND SHANGHAI BANK 010060014
INTL COMML BANK OF CHINA 010560019
INTL EXCHANGE BANK 010680012
JP MORGAN CHASE BANK 010720011
KOREA EXCHANGE BANK 010710018
INTL NEDERLAND BANK 010660016
LAND BANK OF THE PHILS 010350025
MAYBANK OF THE PHILS 010220016
METROPOLITAN BANK & TRUST CO 010269996
PHIL BANK OF COMMUNICATION 010110016
PHIL TRUST COMPANY 010090039
PHIL NATIONAL BANK 010080010
PRUDENTIAL BANK 010150018
PHIL VETERANS BANK 010330016
RIZAL COMML BANKING CORP 010280014
SECURITY BANK & TRUST CO 010140015
STANDARD CHARTERED BANK 010050011
UNITED COCONUT PLANTERS BANK 010299995
UNION BANK OF THE PHILS 010419995
UNITED OVERSEAS BANK 010270189