During Tech Ed in Orlando next week there will be a session on migrating VB6 to VB.NET. If you are going to Tech Ed and reading this BLOG you will probably find it very interesting. Details can be found here: http://weblogs.asp.net/kpleas/archive/2005/06/01/410028.aspx Tuesday night from 6:30 to 7:30
Cheers!
Consider this hypothetical question posed to a career advisor:
----------
I've been working with Visual Basic on application development at a company that is considering a migration to .NET. The new IT environment involves Web-enabled applications. Do you have suggestions to help me take advantage of this transition? - Thrilled VB Developer
Dear Thrilled:
Managers need to understand the challenges of migrating applications when they're changing their businesses environments. Right now, your value lies in being a bridge to the new entity, helping in the task of migrating applications and moving the data from one entity to another.
Your knowledge of the original code, plus your understanding of the business logic and business processes of your current company, are the skills that will probably help you climb the job ladder and give you some breathing room to learn new technologies. Once you understand how the older technologies map to the new ones, you could be quite helpful, not just to your company but to other companies and government entities involved in similar projects.
----------
From the developer's perspective it makes a lot of sense to embrace Visual Basic .NET while still leveraging as much as possible the value embedded in the application written in Visual Basic 6.
Jay Roxe is the VB Product Manager at Microsoft. He also has at his heart the topic of Visual Basic Migrations. Check out his BLOG to see what I mean!
http://blogs.msdn.com/JRoxe/
A related topic around Visual Basic 6.0 migration is the migration of VBA code. This article: http://msdn.microsoft.com/office/default.aspx?pull=/library/en-us/odc_vsto2005_ta/html/OfficeVSTOLanguageMigrationFromVBA.asp refers to the low level approach of VBA migrations for Microsoft Office. This article is relevant to the topic of this blog because VBA code is essentially Visual Basic code with a special Object Model to access Office elements. Most of the strategies around VB migrations can be applied to the migration of VBA. Soon there will be 2 other articles that will go into more high level details around the VBA application migration.
Again, more support to destroy the Myths around VB Migrations!
Let's comment it!
I recommend the following article: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/appmigrationstrat.asp. It contains a holistic view around Visual Basic migrations and how to approach the migration task. Please read it and let's comment it here!
Well, x64 Windows XP and Server 2K3 versions have long been awaited and they are finally here. Two days ago, at the WinHec convention, Bill Gates introduced these two versions into the Windows OS family. Now we only need Whidbey and Yukon on 64-bit and the rest will follow. You can watch a webcast at the following url:
http://www.microsoft.com/events/executives/billgates.mspx
I received the feedback forms from the Paris event a while back and noticed the comments from
Gilles Vollant in which he suggested we touched a bit more on the 64-bit alignment issues.
After exchanging mails back and forth a bit, it seems that it is possible enable x64 exceptions on an x64 machines (by default, these machines handle the exceptions in-hardware and only suffer a performance hit). Why on Earth would you like to change this? Well, if you are a developer writing software for 64-bit systems and would like to rid your software of alignment faults, it would be quite difficult to do so without knowing where/when they occur.
Here is an excellent article
Gilles Vollant wrote about alignment on both architectures:
http://forum.winimage.com/viewtopic.php?t=137
I have not yet tested this and once I get my hands on some machines next week at the Canada event next week, I’ll investigate some more and post any issues I may find.
"Do not sleep during the day, that will only make your jetlag worse!". That's what I've been told numerous times - I wished I had given attention to the advice. It is now midnight here in Copenhagen, a day prior to the event and I am nowhere close to falling asleep.
So I thought I should make something productive and that will quickly send me to bed, which is why I am going to talk about imaging an x64 workstation.
Many, if not all, imaging programs out there will not work under Windows-64 bit at the time of this writing. We have booted from floppies that used Drive Image in DOS mode in the past, but this method is super slow and I personally have something against floppies – no one should use them anymore!
In order to automate the imaging process for our workstations, I decided to install a secondary OS on these images – Windows-32 bit. Once this was done, I used Macro Express to automate the restoring procedure with Drive Image once the machine was booted in 32-bit mode. The process takes now 5 minutes (vs. the 60 that it took before) and requires no floppies.
Some may ask why not use TrueImage or Ghost instead of the discontinued Powerquest Drive Image. It’s just a matter of preference – I have found Drive Image’s installation and usage a lot simpler than its competitors. Feel free to use your personal image restoring procedure, your outcome should work just the same.
It really takes no culinary experience to discern what the following ingredients are a recipe for:
-24 Machines
-26 attendees
-24 Missing Power Cords
-1 Faulty Projector
-26 Missing Booklets
-2 Tons of Stress (1 per presenter)
It certainly sounds like a perfect recipe for disaster. The first day at Paris has been the most stressful – no doubt about it. It would seem that with the aforementioned ingredients, we would be destined to fail miserably, but thanks to very hard work and support from a lot of people, we managed to find solutions for every one of the problems we faced in the time required. .
Au contraire to most events, we had a Microsoft speaker who has been involved with
Route64 for some time –
Christophe Lauer. Mark from HP and Laurent from Intel (who kindly helped us with power cable issues) followed with their respective keynotes that presented the HP offers and information on Intel’s commitment to their customers who are porting to 64-bit.
The C++ was of particular interest to the presenters. Even
Gilles Vollant (Microsoft C++ MVP) mentioned that had learned quite a bit, specifically in the alignment/padding section. Many people were interested with VAS and had a plethora of questions which were correctly addressed.
It seems as in every event there is something unique - in the case of Paris, it was the fact that the hotel almost burned down - and no, our machines were not the ones responsible :) The fire alarm went off during the last day at 3:00 p.m; it seems a room on the third floor was on fire. Firemen came over to the Marriot at Champs Elysee and managed to put the situation under control. Make sure you check out the Paris gallery to see the pics of the firetruck in front of the Marriot, quite an unusual site!
Two weeks ago we had the great opportunity of flying across the Atlantic and head out to London for the 3rd
Route64 event. We flew on a Sunday and arrived Monday completely jet-lagged. The people from
WinGear had some issues finding power cables for the 24 machines that we needed for the event. Fortunately for us, the people at
Microsoft Chertsey had plenty of spare ones and made our life a lot easier.
We were astonished on how punctual the English lads are - some were waiting at the venue 1.5 hours before the event started! The
Microsoft Chertsey training center was amazing. We had three projectors that simultaneously displayed our presentations – this made it possible for all attendees to have a perfect view of what was going on. The projection system was created by
Barco Designs, which coincidentally had sent one of its employees to the
Route64 event. He had most of his code ported and reached brick wall when he found that he did not have some required libraries for his project.
Overall, the labs went extremely well. We received great comments such as “information provided was clean and concise” to “well structured examples with enough ideas and examples for relative novices to grasp the fundamentals of porting 32-bit to 64-bit. Thanks!” We really enjoy receiving positive feedback at the events, it makes everything worthwhile. Make sure you check out the London Gallery Section of pictures of the event!
A while ago was the first event in the
Route64 series and I am very happy to say that it went great! We had a great audience, very interesting people quenching for 64-bit knowledge. I talked with many of them and they really liked how the content was given. Some mentioned that these trainings had been the best that they had attended in 10 years or so – really cool stuff!
So what’s so different from these training events to other ones out there? I believe that the best part of our training is that there is no marketing mumbo jumbo – we want you to learn and we start teaching you in the first session. Another thing that separates our labs from the rest is way in which we present the sessions: we lay the theory on the table, show you how this will affect you and the problems that will arise and we give you not one, but many solutions for you to chose from. You also get to take home booklets from all sessions with ALL the covered information – this way you can always have reference materials to which you can come back when in doubt. Make sure and read some of the
attendee comments from the Seattle event, I think they are great.
Hello and welcome to my first blog entry. Let’s start with a little introduction…my name is Christian Saborío and I work in San Jose, Costa Rica with a company called Artinsoft. I have been a trainer for the HP/Intel/Microsoft 64-bit developer forum for quite some time now…I believe it will be a year very soon, amazing how time flies The 64-bit developer forum is a joint effort by Microsoft, Hewlett Packard, and Intel to raise awareness on 64-bit and to train people in specific areas when porting applications to 64-bit.
The first event on these series was in Boston. The tour then followed Santa Clara, Phoenix, New Jersey. There are other events planned for this year but have not yet been confirmed. I’ll make sure to keep you posted when I find out the exact dates.
So what’s the difference between this forum and
Route64? In a nutshell, we offer the same courses and have the same support. These courses are not meant to compete with one another; but rather to bring these great labs to a wider audience. The forum offers an introductory price and you get to take a 64-bit machine with you.
Route64 price is not bundled with a machine, but get a special discount when you sign up for this event.
VB6 programmer Mort is scared by the news he reads about the complexity of VB migrations and he is filled with mixed feelings about Microsoft. How could Microsoft have abandoned me? How am I going to transition my skills and my applications to .NET without completely disrupting my life? The only solution available is either to stay behind of the technology curve or start an enormous effort to re-write my applications!!
A lot of Visual Basic programmers have posed themselves some of the questions above and feel frustrated about the situation. The frustration is often based on a lack of understanding of the alternatives that exist to smoothly migrate Visual Basic 6 application and skills to .NET.
The myths about Visual Basic migration make it easy to play the “blame” game instead of trying to understand the issue. Often, in making the wrong assumptions, we “write off” some alternatives without even considering them. However, with training, support from automatic migration products and the use of a comprehensive migration methodology, the migration is not only possible using a fraction of the resources required for a rewrite, but it is also the right choice to reduce the Total Cost of Operation and prepare applications to maximize their future business value.
To help continue the realization of the value of an application when it transitions to VB6 to .NET we must first learn the facts about the proper way of executing automatically assisted migrations.
· It is false that to move an application to .NET the only alternative is to re-write it. (This is the core of the myth I am chasing!)
· It is false that Microsoft has abandoned the Visual Basic 6 programmers (Links to many available resources will be posted in this BLOG).
· It is true that a proven methodology exists to migrate applications to .NET in an automatically assisted way (This methodology will be covered in future posts).
· It is true that the Visual Basic 6 programmers CAN make the transition to .NET and they will obtain many advantages from it.
This is the first post and I think it is good enough to start the discussion. I plan to post a lot of evidence to support the thesis presented above and erase once and for all the Visual Basic migration myth.
Do you relate to this story? Do you agree with my comments? I would like to hear from you.
Do you disagree with my comments? I would like to start a discussion and chase the Visual Basic 6 migration myth until it disappears.
Help me in this quest for the truth!
So it seems that with the release of Visual Studio 2005 Beta 1, Microsoft in all it's wisdom has seen fit to deprecate around one hundred standard C functions. The following is a short list some functions that have been deprecated:
Some string manipulation functions like sprintf, strcpy, and strcat.
Some string conversion functions like asctime, itoa, and fcvt.
Some input functions like scanf and cgets.
Some memory manipulation functions like memcpy and memmove.
The rand number generation function rand().
Other apparently harmless functions like printf and fopen.
All these functions have been replaced with functions that are followed by an “_s”. For example, uses of strcpy should be replaced by the function strcpy_s. Calls to rand() should be replaced by calls to rand_s(). The return types and parameter lists change also - so a simple find/replace will not work. You need to to this by hand. You can a full list of these functions here: http://msdn2.microsoft.com/library/wd3wzwts.aspx
The reason they have done this is, in a word, Security. Each of these functions and all the others that have been deprecated behave in a way that makes the production of secure code more difficult.
Many of the functions that involve copying strings in to char* variables have had a maximum allowable size argument added for example. One group of functions in particular to look out for here is the scanf() family of functions and their friends that take as parameters a destination char*, a format string, and a series of other parameters. They all have been changed in similar ways. As an example I will mention just scanf() which has been replaced by the more secure scanf_s(). The new function's signature seems to be the same as it always was:
int scanf_s
(
const char *format,
...
);
The elipsis (...) indicates an unspecified list of parameters that correspond to items (type specifiers) in the format string. In the older scanf() function there was a single parameter for each item. In the new scanf_s() a second parameter is required for each one. The second item specifies the size of the buffer or variable into which the input data is copied. This is not clear from the signature and can be easily forgotten, giving usually odd results. You can read more about scanf_s() here: http://msdn2.microsoft.com/library/w40768et.aspx.
Other changes that have been made are the random number generator must be replaced with a function that creates more cryptographically secure random numbers and also many functions that used to supply information as a return value have been replaced by functions that return an error code while writing their result to an appropriate parameter pointer.
If you wish you can always turn off the security warnings by defining _CRT_SECURE_NO_DEPRACATE in your code. But this may not work forever...deprecated usually means that some day the functions will not exist anymore.
I saw one person call this modification of standard C functions “insane“. I initially though it was at the very least completely obnoxious. But it seems that there is wisdom in Microsoft's madness. So much so that the C standards committee agrees with them. Have a look at this draft Technical Report:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1088.pdf
Though it's still only a working draft I suggest that we C programmers get used to it - a major chunk of the standard C library will soon be a fond memory. Just what will take it's place may change as far as ISO is concerned but Microsoft will soon have Visual Studio 2005 ready and after that the new functions will be written in stone - as difficult to change as, well, as the C standard runtime library.
I was surprised to find - and you might be surprised to hear - that Microsoft decided not to allow even pure .NET applications that were built on 32-bit machines with certain versions of Visual Studio to run on the 64-bit CLR.
“What are you talking about?” I hear you ask. Well, I mean that if you have a C# application that is pure, safe, 100% .NET intermediate language it may still only be allowed to run on the 32-bit CLR. Applications built by newer versions of Visual Studio .NET 2005 (code named Whidbey), however, will be allowed to run in the 64-bit CLR. Don’t worry, these same applications will work fine on 32-bit CLRs too.
“But”, I hear you insist, “.NET provides platform independence! It has no native machine code! It is pure IL that runs on the CLR. The IL has not changed in 64-bit – so why wouldn’t run on the 64-bit CLR?”
These are good questions. The answer to these questions is, unfortunately, “Just in case!” It is possible, for example, to create pure .NET code that makes use of in-process COM objects that are not pure .NET. In fact it is possible to try to load DLL’s that were not even compiled for the same platform that your .NET application is running on – if you do this your application will not find the DLL or, worse, it will die a horrible death. And the key is that it’s possible to do it without the CLR knowing that you are going to do it at application load time.
So, for example, you can create a C# application that load’s a 32-bit DLL and calls some of the functions in that DLL. If that C# application is loaded into the 64-bit CLR then any attempt to load the same 32-bit DLL will fail.
Clearly, if the OS knew FOR SURE at load time that you had no 32-bit dependencies then your application could be loaded quite safely into the 64-bit CLR. However, 1.0 and 1.1 assemblies no nothing of “bitness” – they were built by compilers that do not know anything about the 64-bit edition of Windows. So, although they can be marked as containing only IL, they may still have 32-bit dependencies in there somewhere. So, to prevent older .NET applications from breaking in unexpected ways on 64-bit Windows the CLR team decided to force them to run in the WOW on the 32-bit CLR.
Interestingly this restriction does not extend to DLL’s that are loaded by applications that manage to be executed by the 64-bit CLR. If I compile my application with Whidbey and target AnyCPU the application will load into the 64-bit CLR. If I then reference any older assemblies from my application they will be allowed to load. So be careful doing this, if the older referenced assemblies do anything that is x86 specific your application may crash.
So, let’s look at the application loading policy used by the new Windows 64-bit operating system and the .NET Framework. The loading policy is just starting to get complicated enough that a diagram would help a lot here…
The flow chart above goes like this…
- First, the file format is checked. If it is PE32+ then it is clearly a 64-bit application. PE32+ is the new 64-bit executable file format. If you target AnyCPU or x86 in Whidbey then the PE32 file format is used to ensure that it will run in 32-bit Windows.
- Next, if the file is not a .NET application then it is loaded into the WOW.
- If it is a .NET application but it is not marked as ILONLY it is loaded into the WOW.
- If it IS marked as ILONLY, but was compiled by an older compiler then, “just in case”, it is loaded into the WOW.
- Finally, if it is an ILONLY .NET assembly and was compiled by Whidbey then it checks to see if it was explicitly marked by Whidbey as requiring the 32-bit runtime. If so then it is loaded in the WOW.
- Otherwise it is loaded into the 64-bit runtime.
There is an interesting aside here. As I mentioned earlier, assemblies that were compiled by Whidbey and marked as AnyCPU use the PE32 format for executable files. Some skullduggery is required to allow this file to load into the 64-bit runtime which expects the PE32+ format. A process that has “hack” written all over it has the CLR modify the format of the file and then pass it back to the OS which eventually passes it pack to the CLR for execution.
So, the take away here is if you want your .NET applications to load in the 64-bit CLR on 64-bit machines and still work on 32-bit machines then compile them with Visual Studio 2005 and mark them as AnyCPU (which sets the ILONLY flag).
?>
So, it’s Monday evening (21st February,2005). I want to go a friend’s house for our regular Monday night get-together. But before I go I should tell you a bit about our first Route64 event which just took place in Redmond, Wasington.
It was a great success! One comment we got was “these training sessions set the standards to what all Microsoft training events should strive for”! If that doesn’t irritate the hell out of some hardworking MS trainers out there I will eat my hat! Other comments were “Mind-blowing” and “WOW!”. As you can imagine we are more than a little pleased. Though I can’t help wondering if someone slipped something into the lunch boxes we gave them during the event…
All joking aside, it was great to see some real world applications being ported. It was also encouraging to see people making progress during the only three days of the event.
One of the original programmers of Autocad was there with his new product and, with the help of the instruction that he received during the training, managed to port his entire application to the x64 servers by the end of the second day. Some alignment problems slowed down the port to the Itaniums. Visual Studio couldn’t debug the peculiar problem that we were getting - not sure why – but we got a closer look with the help of the native 64-bit compiler WinDBG. Although the port to the Itanium was not completed by the end of the third day this attendee went home a very happy customer.
Another attendee was quite surprised to see so many warnings about the standard printf() functions. The warning said that these functions were deprecated! What’s going on he wanted to know – is Microsoft deprecating standard C now? Well, in a nutshell, the answer is “Yes“. But they are getting a lot of support for these efforts. I will write something on this shortly - watch this space.
Other noteworthy revelations from this event? How about free ice cream hidden in the small kitchen beside the “Thunder” conference room? It seems that there has been a refrigerator there for a year or two – well I never saw it before – it was so well hidden. Only accessible by those privileged few who knew where to look! Terrible elitism I call it. Snobbery in fact. Having said that, I am not giving any more information about how to find it – lest it all be gone the next time I look for my favorite sweet, icey, sugary snack...