So the webcast went very well, we had about 40 people who asked very
interesting questions which I thought I would share with you. The
typing errors remain as I want the script to be the original one:
Question: Is there any general 64-coding info for starters?
Answer: You can find all kinds of programming info (C++/Managed
Code, etc.) on http://www64advantage.com. It is one of the best places
to start.
Question: does c# work on 64-bit at this moment?
Answer: Yes, C# and Visual Basic .Net are fully supported in 64-bit with the release of the 2.0 64-bit framework.
Question: Will this webcast be available for download?
Answer: yes in 24 hours at www.microsoft.com/webcasts
Question: From the Developers Perspective, What would be the learning curve from 32 bit programing to 64bit programing?
Answer: It really depends on your programming language. If you are
dealing with managed code, oftentimes things can be as easy as just
recompiling. With languages such as C++, the API has not changed that
much, so given that you watch out for common pitfalls, your 64-bit
learning curve should not very steep.
Question: Do we have to sign up for tomorrow's session or are we already registered ?
Answer: You need to sign up for each of the webcasts. The
information for tomorrow's webcast:
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032299373&EventCategory=4&culture=en-US&CountryCode=US
Question: I am running XP Pro at home. Can I write 64-bit code without a server?
Answer: You definitely can. Visual Studio and the PSDK will allow
you to write 64-bit executables from a 32-bit OS (Server or XP).
Remember to always use /wp64!
Starting today (like in 30 minutes ;) ), we will start the first
webcast in a series of three. These revolve around most of the
things we have discussed in the labs plus some new ones such as issues
with 64-bit installers, setting up VS for 64-bit deployment, and
multi-threading your application using OpenMP standards.
You can find the whole list
here. Tomorrow, Thursday 29th, I will be presenting a
webcast that
has many, many demos on how to preserve dependencies in 64-bit.
Feel free to stop by and let me know your comments once the session is
over.
If you really have no idea on what to expect when moving to 64-bit, then these webcasts are definitely worth listening to.
Did you know that you can get Intel's suite of tools such as VTune, the C/C++ compilers, and threading tools for free? These tools, when purchased are worth every cent. So how can you get them? Go to the
Intel Early Access program webpage at the Intel site and read on.
So we have mentioned that using the Intel compiler to generate 32 or 64-bit binaries is possible with Visual Studio, but we have not mentioned how to do it...until now.
I have found a web page on the Intel site that shows you step by step instructions on how to use it. The link can be found here.
Of course this brings the immediate question on whether this will work with Visual Studio 2005. Furthermore, if it does work, will it be a supported scenario? Stick around and I may have the answer to these and other questions on my next blog entry.
Even though we have talked quite a bit about POGO on our 64-bit sessions, we seldom have mentioned how you can actually weigh down the profiles that you use. In order to find this information, check
this link at the MSDN site that explains everything.
If you want to 'take it up a notch' when it comes to POGO and find exactly what is happening with your scenarios, check
this blog post from Kang Su Gatlin.
If there is anything you would like to know about POGO, just let me know and I'll more than happy to research it for you!
The Longhorn Server conference finishes today but we had to part yesterday since we had to be in Costa Rica today :( This means that we missed some of the sessions on the last day. The one we regret the most was the second part of Virtualization which has some cool stuff for the future. I will not dive into specifics because I am sure Jose will probably blog about this so keep visiting often to read about how virtualziation on Longhorn will change the ways things are done.
I also had the chance to attend the HPC session. This deals specifically with Windows Server Cluster Edition 2003 which is slated to be released in Summer 06. What does this have to do with 64-bit, you might ask? Well, this version of Windows Server only runs on x64 hardware. It is really cool to see everything pointing towards 64-bit. Applications have been starving for more memory for a long time, and now that we have the tools and OS to get things up and running, we just have to stand back and watch the transition happens.
One session we most definitely enjoyed was Monad, which is a shell that will ship with Longhorn Server. This environment makes it so easy to carry out many tasks that in Unix would require several visits to the man pages again and again. What makes Monad so special is that its a shell in which you type commands that actually make sense from a human perspective - no AWK, GREP. For instance, a Monad command 'get-services', does what you expect, gets the list of services. Once you get this listing, there is a plethora of things you can do by piping to other Monad commands. One that blew me (and the audience as well) was a command to output the result as a series of bar graphs in IE - pretty neat stuff!
I am writing this blog as I sit and am listening to the Virtualization session at the Longhorn Software Review. This one has been particularly interesting. The presenter has talked about what Longhorn develpers have done to make sure that the OS takes advantage of the Virtualization technology that is now offered with most mayor chip vendors.
If you want to take advantage of Virtualization with Longhorn, you will *NEED* a 64-bit box (x64) as this technology will not be supported in Longhorn 32-bit. Running Virtual machines does require a lot of memory and 64-bit is the way to go when you are going to be hosting lots of guest OS. There are many, many things that have happened under the hood to make sure Virtual Machines will run almost at full speed when running under Virtualization. This will definitely make things very interesting in the future for datacenter administrators and test servers. Can't wait to get my hands on one of those development versions
Some have asked in the past about building for 64-bit using previous IDEs such as Visual Studio 2003 and Visual C++ 6.0. Even though this is not a supported scenario, it is possible. Please follow this
link in order to get instructions on how to accomplish this.
I cannot stress this enough: if you need to build 64-bit binaries, please use Visual Studio 2005. By doing so, you know that you are dealing with a supported scenario, are most likely to find answers to your problems online, and will make sure you are using the most stable versions of several programming libraries such as ATL, MFC, etc.
It has been mentioned in the past that we use
Acronis True Image in order to manage our x64 imaging needs. The procedure on how this was done, involved a mix of boot disks and the 32-bit version of True Image.
A couple of weeks ago, TrueImage announced the 64-bit version of both its workstation and server software. I just imaged an x64 server on the fly and it worked like a charm. Keep in mind that TrueImage allows you to create images without the need to reboot, which is a real time saver.
Now if only we could get an Itanium version...
In our sessions, we have taught you to how to use the PSDK compiler and the compiler included with Visual Studio 2005. The Intel sessions have also taught you how to use the Intel compiler and many have asked me lately why would someone use the Intel compiler given that there is a Microsoft C/C++ compiler?
First off, do not think of the Intel and Microsoft compilers are mutually exclusive when it comes to writing code for the EM64T or the Itanium. The libraries and even debugging tools that are generated by both compilers can be used interchangeably without any problems. That being said, you may now start to think that these two compilers compliment each other instead of compete with each other - this is the mayor key giveaway that we want to teach during our sessions.
If you are ever working with matrix multiplication or code that has to do with products between arrays, you might want to give the Intel compiler a try. It can easily vectorize your loops and you will be taking advantage of the 16 SSE3 registers that are now available in the EM64T. Furthermore, if you need to write inline assembly in code that will compile for 64-bit, the Intel compiler will allow you to do this as well.
Hopefully this will clear some doubts...remember, you can use both compilers to your advantage and make them work together so that your code will run a lot faster than it did before.
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.
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.