DEV332 .NET Framework: 64-Bit Development Today And Tomorrow

1. DEV332.NET Framework: 64-Bit Development Today And Tomorrow Kang Su Gatlin Visual C++ Program Manager Microsoft Corporation Geralyn Miller .NET Solutions Architect Microsoft Corporation

2. Agenda • A bit of motivation... and a state of play • Today: 64-bit Native C++ • State of Tools, Porting Code, Problem areas, Performance • Future: 64-bit .NET Framework and versus 2005 • State of Tools, Porting Code, COM Interop, Language Specifics

3. Why 64-Bit Architecture? • Larger Address Space • Larger values supported by primitive types 2^64 >> 2 ^32 18,446,744,073,709,551,616 >> 4,294,967,296 • Performance? • Possibly, but code size will increase

4. Where Are The Application Spaces? • … with data? • … with high performance computing workloads? • … with 32-bit primitive types? • These are all problem spaces where 64-bit solutions can make sense

5. State Of Play • Two mainstream 64bit architectures supported by Windows • Itanium Processor Family • x64 – a.k.a. AMD64, EM64T • Windows versions available (Itanium) and in beta (x64) today

6. “in-order” processor VLIW Bundling and templates Support for predication Support for control/data speculation Rotating register support for SWP Branch prediction Functional Units galore LOTS of registers 128 floating point 128 integer + predicate, branch, control registers… whew! Tough on assembly folks No addressing modes State Of Play: Itanium

7. State Of Play: x64 • Stretch x86 architecture • Runs legacy x86 at machine speeds • Increased register width of x86 registers to 64-bit • 8 additional general purpose registers • REX instruction prefix addresses the new registers • 8 additional 128 bit XMM registers • VC++ does not generate x87 nor MMX code

8. “OK, How Do I Get Started With 64-bit Development?” • Do you remember Win16 to Win32? • 32 to 64-bit much easier • The memory model has stayed the same • sizeof_x86(long) == sizeof_amd64(long) • Win64 is simply Windows • Essentially simple pointer stretch of Win32 API

9. Agenda • A bit of motivation... and a state of play • Today: 64-bit Native C++ • State of Tools, Porting Code, Problem areas, Performance • Future: 64-bit .NET Framework and versus 2005 • State of Tools, Porting Code, COM Interop, Language Specifics

10. WoW… It Works! • Windows on Windows 64 (WOW64) • Isolates 32-bit Applications • Notably file and registry isolation • Console • GUI • Services • Separate DLLs • Performance hit? • Substantial on Itanium • Little to none on x64

11. Wow64 Process Layout NT Executive Win32k.sys Kernel Mode User Mode Reserved Address Space 0x00000000`7FFEFFFF or 0x00000000`FFFEFFFF 64-bit ntdll.dll Wow64.dll Wow64win.dll Wow64cpu.dll 32-bit ntdll.dll 32-bit modules

12. Current Development Model x86-based Computer (or using WoW) • Develop and test 32bit code here • Cross compile for 64-bit • Send executable to 64-bit computer 64-bit Computer • Execute code here • Debug remaining bugs here

13. State Of The 64bit VC Dev Tools World

14. Porting Your App To 64-bit • Use compiler switch (-Wp64) • 64-bit brings differences – LLP64 • T *, size_t: 64 bit • int, long: built-in integers are ALL 32 bit • long long: 64bit always • Alignment changes • Misalignment can be fatal on Itanium • 32 and 64bit code can NOT be in same process

15. Porting Issues From32 To 64bit

16. Profile Guided Optimization? • Compiler can’t answer everything… if(a < b) foo(); else baz(); for(i = 0; i < count; ++i) bar(); How often is a < b? What is the typical value of count?

17. Profile Guided Optimization Compile with /GL Object files Source Object files Link with /LTCG:PGI Instrumented Image Scenarios Profile data Instrumented Image Output Profile data Link with /LTCG:PGO Optimized Image Object files

18. How Much Performance Does PGO Buy You? • Performance increase is architecture and application specific • Itanium tends to benefit the most • Large applications tend to benefit more than small • If you understand your real-world scenarios then PGO is almost always a win

19. PGO Improvement Over LTCG

20. Agenda • A bit of motivation... and a state of play • Today: 64-bit Native C++ • State of Tools, Porting Code, Problem areas, Performance • Future: 64-bit .NET Framework and versus 2005 • State of Tools, Porting Code, COM Interop, Language Specifics

21. Visual Studio.NET 2003 Visual Studio 2005 • “Everett Release” • Windows Server 2003 integration • Support for .NET Compact Framework and device development • Improved performance • “Whidbey” release • SQL Server 2005 integration • 64 bit Framework • Improved IDE productivity and community support • Extended support for XML Web services • Office programmability Visual Studio “Orcas” • Windows “Longhorn” integration • New UI tools and designers • Extensive managed interfaces (WinFX) Developer Roadmap

22. Availability Of 64-bit .NET Framework • Visual Studio 2005 timeframe • Servers and workstations • X64 and IA64 support • OS Dependency • >= Windows Server 2003 SP1 • No Windows 2000 Server 64 bit Edition • Future Windows 64 bit client releases • Longhorn, Windows XP

23. 64-bit .NET Framework And Tools Support • Parity w/ 32-bit product • Common Language Runtime • .NET Framework Class Libraries (including ASP .NET, Windows Forms, ADO .NET) • SDK Tools • Visual Studio .NET supported on WOW64 • New JIT, GC, exception handling, and debugging services

24. Moving 32-bit .NET Framework applications To 64-bit

25. Managed Code on 64 Bit • Verifiable code just runs • 32 bit Whidbey runs on WoW • 64 bit Whidbey runs native • Assemblies marked for ‘bitness‘ (32 bit, 64 bit, neutral) • COM Interop, P/Invoke, Floating Point may require changes • Images containing native code treated as native (Managed C++) • Nearly all cost is in test runs “The last automated test pass we did on 64 bit before the holidays produced results similar to those on 32 bit after one bug in a cross domain was fixed for us. Oh the joy of being fully managed! “ – Rok Yu, Jscript

26. Porting Cost To 64 bit

27. Writing Portable Managed Code • Verifiable • No native code (IL only) • No pointer arithmetic • Follow Interop Rules • Know Architecture Differences • Beware Floating Point

28. Interop Rules • Signatures • DllImport, Declare • ‘int’ and System.IntPtr • API’s must exist on all platforms • Marshaling • StructLayoutAttribute • Marshal.SizeOf

29. ‘Int’ And System.IntPtr • Int and IntPtr in import signatures • ‘int’ is System.Int32, 32 bit size • System.IntPtr is size of platform integer and pointer, may be 32 or 64, or ?

30. ‘Int’ And System.IntPtr [StructLayout(LayoutKind.Sequential)] internal class SECURITY_ATTRIBUTES { internal int nLength = 0; internal int lpSecurityDescriptor = 0; internal int bInheritHandle = 0; }

31. ‘Int’ And System.IntPtr [StructLayout(LayoutKind.Sequential)] internal class SECURITY_ATTRIBUTES { internal int nLength = 0; internal IntPtr lpSecurityDescriptor = IntPtr.Zero; internal int bInheritHandle = 0; }

32. StructLayoutAttribute • LayoutKind.Explicit • Determines Managed Layout • Use correct FieldOffset • Use with ‘fixed’ in C# • LayoutKind.Sequential • Determines Managed, Unmanaged Layout • Use correct PackingSize • Default for VB, C#

33. Correct Marshaling • Use Marshal.SizeOf • Struct Marshaling Size • Platform Pointer Size Examples: internal class OSVERSIONINFO { public OSVERSIONINFO() { OSVersionInfoSize = (int)Marshal.SizeOf(this); } Marshal.SizeOf(typeof(System.IntPtr))

34. Using COM Components • COM is native • Neutral apps may use platform specific COM components • No COM interop between architectures • Component may not exist on 64 bit • May elect to run in WoW only

35. Exposing To COM • No interop between architectures • 32 bit apps only exposed to 32 bit • May expose neutral apps on each architecture • Must register for each architecture • Type Libraries are not neutral

36. Language Specifics • Visual Basic .NET • C# • Managed Extensions to C++

37. Visual Basic • Creates platform-neutral IL • Safe, verifiable • Can ‘break’ portability • Explicit or Sequential Layout • Using ‘Declare’ or ‘DllImport’

38. C# • Creates platform-neutral IL • Mostly Safe, Verifiable • ‘Unsafe’ allows pointer arithmetic • Can ‘break’ portability • Explicit or Sequential Layout • Using ‘DllImport’

39. Managed C++ • 7.0 • Never verifiable • Contains native code • ‘IJW’ – doesn’t use DllImport • Uses native headers and libraries • 32-bit images • 7.1 • Use ‘cookbook’ • May create verifiable images • May be IL only • Still may use “IJW” • Whidbey • Create fully verifiable images • Greatly improved IJW

40. Closing Summary • int and long are 32-bits • Pointers are 64-bits • Don’t assume data sizes • Align data on natural boundaries • Native • Profile guided optimization can greatly help performance on IA/64 • Managed • Verifiable code just runs • The new power of the platform enables us to do even more!

41. Resources • 64-bit Windows Programming • “Getting ready for 64-bit Windows” • The New Data Types • “Designing 64-bit interfaces” • “Running 32-bit applications” • (wow64 registry redirection, debugging, performance, app installation) • “Migration Tips” (common compiler errors) • “Introduction to Developing Applications for the 64-bit Version of Windows” • “Windows Data Alignment on IPF, x86, and x86-64” • “Application Compatibility Guide”

42. Attend a free chat or web cast http://www.microsoft.com/communities/chats/default.mspx http://www.microsoft.com/usa/webcasts/default.asp List of newsgroups http://communities2.microsoft.com/ communities/newsgroups/en-us/default.aspx MS Community Sites http://www.microsoft.com/communities/default.mspx Locate Local User Groups http://www.microsoft.com/communities/usergroups/default.mspx Community sites http://www.microsoft.com/communities/related/default.mspx

43. Please fill out a session evaluation on CommNet Q1: Overall satisfaction with the session Q2: Usefulness of the information Q3: Presenter’s knowledge of the subject Q4: Presenter’s presentation skills Q5: Effectiveness of the presentation

44. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.