I will be giving a live webcast next week!!
The webcast is titled Proven Techniques to automatically convert your J2EE code to C# and .NET, and it is as part of Microsoft's nxt initiative, aimed at moving ISVs to Microsoft's platforms.
The webcast is next Tuesday at 10:00AM PST. You can register for the event here: Event Link
For those of you who didn't know, ArtinSoft's main operation is based in San Jose, Costa Rica. Here in Costa Rica we've been on a technology boom in the last few years, starting with Intel opening up a big plant here in the country and with the appearance of several software companies doing business abroad during the 90's. There's a lot of outsourced development going on around here, and people everywhere in the world are taking notice.
Here is a nice article at the Los Angeles Times that talks about the phenomenon. There's a couple of quotes from our CEO, Dr. Carlos Araya, and from our Project Director, Roberto Leiton, in the article.
Enjoy the read: Costa Rica Rides High-Tech Wave
Yep, it is official. Vista will not be widely available until January 2007. It will be available for corporate customers on November 2006, so there's still a chance that I'll be able to get my hands on it before Christmas :-)
Press Release
The Atlas framework is now
available!!
For those of you that are not familiar with Atlas, it is an
AJAX-based framework for ASP.NET. I've been playing with it a little bit, and it has a lot of potential for bringing rich, interactive Web 2.0 technolgies to the mainstream. There's a nice video demonstration on the Atlas website that will give you a better idea of how it works.
I recommend you give it a try!
Hi All!
Welcome to my brand-new blog. Even though I have been blogging for the last few weeks on the 64-bit Advantage site, I finally decided to have my own blog. I work in the consulting side of the company here at ArtinSoft, so I will be mainly blogging about my experiences with customers. I will also be talking about the different technologies we get to work with here at ArtinSoft.
If you have any particular interest on which you want me to comment or research, feel free to leave a comment!!
During our interoperability sessions we have talked plenty about the WoW64. We have touched base on topics such as changes that happen in the file system and in the registry. Of particular interest is the topic of registry reflection, which is the mirroring of keys from the 32-bit and 64-bit sections of the registry so that they share same information. If you recall, one of the many reasons why registry reflection happens is so that an out-of-process COM LocalServer (aka COM EXE) can be accessed by a 32-bit or 64-bit application.
Even though this works like a charm, there are some cases in which you might not want your COM LocalServer to be registered to both 32-bit binaries and 64-bit binaries. Since Windows Server 2003 SP1, you can disable registry reflection on a specific key by using the following function:
RegDisableReflectionKey
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/regdisablereflectionkey.asp
By doing so, when this key is registered, it will not be reflected. Why on Earth would you want to do something like this? Say for example you are registering a 64-bit COM server that handles and sends data segments that are bigger than 4 GB to the caller. You would not want this COM server being accessed by a 32-bit application at all. That’s one I can think on top of my head, can you think of any other reasons on why you would like to use this function?
In our Intro to 64-bit, we mention that the limit for a 32-bit process (by default) in Win-32 is 2 GB. Likewise, we mention that the limit for a 64-bit process is 8 TB. I recently received a mail in which the author was telling me that he wrote a 64-bit app that requested memory by means of malloc and that it would stop around 6 GB, which was nowhere close to the 8 TB we talked about.
After some e-mails back and forth I found the specs for his system: EM64T with 4 GB of memory. It just so happens, that the memory your application can use is limited by how big your page file is + the amount of physical RAM you have.
In this case, the machine had 4 GB of RAM, the page file size was about 4 GB. If you open your task manager and look under the performance tab, you will find stats for "Limit" which is how much memory is available in your system. This number should be very close to your page file size + your physical RAM.
You can change the Page file size under the performance properties of your computer, and by doing so, you could modify the settings so that your "Limit" can increment.
In our tests we incremented the page file size to 11 GB. When our "memory hog" application was running, the limit was dynamically increased and could allocate about 17 GB of RAM. Keep in mind that the more paging you are doing, the slower things will be.
It has been about 4 years and still the article that pops up first in Google when searching for "VB Migrations" is an article published in the dawn of .NET: Lori Piquet's "Abandoning the Fantasy of VB Migration Wizardry" (http://www.devx.com/vb/article/16822 ).
It is clear that the article was published to drive readers more than to provide a tool to help customers make a decision. Since I was the person who supposedly provided the reasons to demonstrate that a VB conversion was not possible and since it has been 4 years, it is about time I "defend" myself against her claims.
So, if you have read this blog, you must know by now that VB upgrades are not only possible, but they are actually a very good option for companies that wish to leverage their software assets. In fact, during the past 4 years there have been many demonstrations of this fact and corporations are doing VB6 conversions and they are quite happy with the results. With the publication of the VB Upgrade Guide from Microsoft (with strong input from ArtinSoft), the assessment tool, and ArtinSoft VB Upgrade Companion the magic is actually happening!
Lori said: "After a developer is sufficiently comfortable with .NET and has spent several weeks in studying the migration process with the tool, Zoufaly says that a migration should progress at an average rate of just 7,000 to 10,000 lines of code per week. Therefore, a 1 million-line VB6 application will take 100 weeks—two years—to upgrade. Seems a little slow for something that Microsoft had the hubris to dub a migration "wizard."".
Well, how many production quality lines does a great software developer writes per week? A few hundreds maybe? So, if there is a process that automatically allows you to pretty much rewrite your application to a new platform in a very consistent way, allows you to bridge the obsolescence gap at a rate that is more than an order of magnitude the normal rate of development? How would you call it? I think “Wizard” is not such a bad name after all. I am certainly not trying to say the process is magic and I also believe that "File-Open-Convert" from inside Visual Studio might not be the right gesture to set up proper expectations in terms of a conversion project, but it is true that the process is there and it works very well.
By the way, I am not making up the productivity statistics for software developers. The Software Productivity Research Institute (www.spr.com ) publishes such statistics and they more than confirm what I am saying.
I guess time was on my side and, today, nobody would argue about weather VB6 automatic conversions are magical or not. It is clear that there is a methodology behind, it is clear that they cannot be approached as ad-hoc projects and it is clear that they benefit customers and are less risky, and more cost-effective than manual software rewrites.
As always, I invite you to share your experiences. Don’t forget that I still have prizes for you!
Getting started: Tips for VB6 to VB.NET 2.0 migration
Another PODCAST with more information on VB migration. Your comments welcome.
Mark M. Baker
Federico Zoufaly promotes automated migration to .NET for significant investments in legacy apps. Federico also discusses the advanced ArtinSoft VB Companion tool.(MP3, 16:23 mins.)
http://devnet.developerpipeline.com/podcasts/dotnetcast/
Another POD CAST. Listen how customers have done it. And remember if you share your migration story with me I'll send you a PRIZE!
Mark M. Baker
Federico Zoufaly of ArtinSoft discusses the unique challenges in migrating large VB6 applications to .NET including a real life example of a 5 million line VB6 application that was successfully ported by a client. (MP3, 16:23 mins.)
http://odeo.com/channel/33292/view
In these pod casts you will find an interesting interview of myself talking about ArtinSoft's experience on .NET migrations. Many of the basis are covered. Please send your feedback and enjoy!
http://devnet.developerpipeline.com/podcasts/dotnetcast/
Mark Baker and Nik Hemdal interview Windows and .NET experts on techniques for getting the most out of the .NET platform.
Audio is provided in MP3 files. Listen online or subscribe to the DevNet .NET Cast feed
Mark M. Baker
Federico Zoufaly of Artinsoft discusses its Ready-Set-Go! methodology for migrating VB6 applications to .NET and how its extensive experience with migration was a key reason Microsoft selected Artinsoft to develop the VB6 Upgrade Wizard and provide key guidance in the VB6 Migration Guide. Learn how to approach migration as a systematic and thoughtful manner to ensure success. (MP3, 17:23 mins.)
Mark M. Baker
Federico Zoufaly of Artinsoft, the developers of the Microsoft VB6 Upgrade Wizard, describes the benefits of iterative upgrading -- refactoring your VB6 code each time to refine the result from the wizard. He also digs into the internals and improvements of the VS 2005 Upgrade Wizard. (MP3, 16:45 mins.)
Today ArtinSoft added a new solution to its portfolio. We are now able to provide consulting services to migrate from C# to VB.NET. This is in recognition of the broad spectrum of programmers, solutions and customers preferring VB.NET.
http://www.artinsoft.com/ne_view.aspx?idn=26
Share your opinons!
This comment comes from: http://weblogs.asp.net/israelio/archive/2005/11/29/431788.aspx
" I had to migrate some vb6 app to Visual Studio 2005, I was very afraid things might stop working and that i will have lots of work to do after the conversion
B U T
Everything just worked great on first round!
It seems that someone in Redmond has done pretty good job on the conversion wizard as I now have vb.net app !
,,, hmm and don’t mistake me as a vb.net user its being translated as i write this post to c# :-)
"
Share your stories with us!
This is a recent interview with Jay Roxe, the Microsoft PM for Visual Basic .NET. You will find some good pointers on how to approach the migration.
Take a look: http://www.ddj.com/documents/s=9776/ddj1129914421813/swigart2.htm
Hi all!
I am continously looking for stories about Visual Basic Migrations. If you share a story with us I'll send you a very nice ArtinSoft beach handbag for your effort.
I want to know the good, the bad and the rest. The most interesting story will get an additional surprise gift.
Let's start sharing.
Oscar's BLOG is also another interesting resource for Visual Basic Migrations. Check it out and don't be afraid to ask questions. Oscar is super knowledgeable and willing to help.
http://blogs.artinsoft.net/ocalvo/articles/168.aspx
Enjoy, Federico.
<a href="http://www.technorati.com/claim/3y9amdvwm4" rel="me">Technorati Profile</a>
Upgrading Visual Basic 6.0 to Visual Basic .NET and Visual Basic 2005 guide is ready!!!.
The guide teaches you a predictable process that can be followed to migrate your Visual Basic 6 code to .NET. It contains a lot of experience from many migration projects and I am sure it will benefit your project.
This guide was developed jointly by the Microsoft patterns & practices team and ArtinSoft, a company with vast experience in Visual Basic upgrades and the developer of the Visual Basic Upgrade Wizard and the Visual Basic Upgrade Wizard Companion. This guide provides valuable information for organizations who are considering upgrading their Visual Basic 6.0-based applications and components to Visual Basic .NET. It provides proven practices to reach functional equivalence with a minimal amount of effort and cost and guidance for common advancements after the application is running on the .NET framework.
In addition to the guidance itself, a new tool, the Visual Basic 6.0 Upgrade Assessment Tool, is provided to give your organization assistance in identifying common upgrade issues and estimating the cost and effort required to upgrade your Visual Basic 6.0 code.
Let me know what you think!