Recommended Posts

It?s not much of a secret at this point, but CEO Steve Ballmer is expected to announce official availability of the closed Windows 7 Beta 1 release during his Consumer Electronics Show keynote address on January 7. The official (non-Torrented) Beta 1 bits should be available to pre-approved Windows 7 Beta 1 testers later Wednesday night or early on January 8.

Ditto with Windows 7 Server, a k a Windows Server 2008 R2. The private Beta 1 release of that product is scheduled for late January 7/early January 8, I?m hearing.

I?ve gotten a number of questions from readers this year already about the expected public betas of these products. I?ve made some discreet inquiries.

The public (the one and only) beta of Windows 7 client and server could be released simultaneously with the private Beta 1 builds this week, according to some of my sources. What?s the point of a simultaneous public and private beta? The private testers? feedback will get top priority; the public beta will be more of a milestone marker than anything else.

One source of mine said the Windows Server 2008 R2 code definitely will be available to the public this week, but was less sure about client. He said he thought the public beta of Windows 7 client might lag by a week or so.

Update: Nope. It?s going to be sooner, not later. The latest word: The public beta of Win 7 client is due to hit Friday, January 9, according to a source familiar with Microsoft?s plans. The public beta of Win 7 Server is due to hit a day earlier, January 8, the source added.

Microsoft officials declined to comment as to when testers ? public or private ? should expect to get the new Windows 7 client and server builds.

Bottom line: If the tipsters are on their game, anyone who wants to test Windows 7 client and Windows 7 server should be able to do so starting this week?. And if you?re a consumer in the market for a new Windows PC but want the flexibility to upgrade to Windows 7 for free, it sounds like you should wait until July 1, 2009, to make your purchase?.

http://blogs.zdnet.com/microsoft/?p=1792

Update: Nope. It?s going to be sooner, not later. The latest word: The public beta of Win 7 client is due to hit Friday, January 9, according to a source familiar with Microsoft?s plans. The public beta of Win 7 Server is due to hit a day earlier, January 8, the source added.

I heard that MS Netherlands informed the Dutch press in a meeting yesterday that the public beta of Win 7 will be released on January 9.

Fact: On average 64bit run programmes 10% faster than 32bit.

64bit apps also use more memory ;) Did you know that fact too?

Faster because 64bit apps can handle integers 4 words long instead of 2 words in 32bit. They are generally faster when it comes to crunching numbers.

Care to back that up with some sources? I've heard nothing but the contrary (I run 64-bit Vista, btw, so I'm in no way biased against it)

dword

http://msdn.microsoft.com/en-us/library/cc...PROT.10%29.aspx

qword

http://msdn.microsoft.com/en-us/library/2s70e2x4.aspx

If I use a pointer to a memory address in a 64bit OS my pointers will always be 8bytes. Same pointer to memory address in a 32bit OS is only 4 bytes.

Why? Because If I want to address 64bits of memory I need to use pointers that are 64bits long to hold the memory address of the type that its pointing to. So my pointers on the stack now take up two times as much stack seg memory.

it might not seem like much 4bytes here, 4 bytes there, but classes /structs with a lot of pointers and qword members slowly add up in size and that means you will use more memory to store that data.

programming 101.

[tin foil hat]Is there any thought on if these "leaked" copies of win7 found on torrent sites haven't been tempared with and have spyware/root kits on them?[/tin foil hat]

Care to back that up with some sources? I've heard nothing but the contrary (I run 64-bit Vista, btw, so I'm in no way biased against it)

Let me clarify some things about 64-bit.

The x64 (AMD) mode is not an emulation mode like IA64. That is, 32-bit Software run natively in a mode known as "Compatibility" mode of the 64-bit CPU. Therefore, any application as long as its code does not jump back and forth to 64/32 big segments, will run as fast (or as slow) as an 64-bit native one.

What happens with Win32 applications that make system calls or otherwise mess with the kernel? Because the kernel in x64 is only 64-bit (there is no WOW64 for kernel), the code has to jump into x64 and get back to 32-bit segments when they make a system call. Therefore they are slower in theory when running under x64.

The cost, if any, is negligible of course, but in exchange of that you get other features that may or may not increase the speed of the application, that is, SSE/SSE2 instructions by default, a full 4GB of address space of the 32-bit app, PAE by default and some (more developer-wise) stuff.

So an older 32-bit app that wasn't designed to be run under wow64 will probably run slower. The difference is not noticeable even with most developing testing tools and of course it is invisible to the end user. But a 32-bit app that can take care of the extra features under wow64 will probably run faster.

64-bit apps will surely run faster than their 32-bit counterparts under a 32-bit OS because of the nature of programming under x64, including additonal CPU registers, fast calls between procedures and some more. The % difference depends on the application. In notepad might be 0.0001% , in a time critical processing software it might be way over 100% as I 've tested. In addition, they have the entire address space and ram.

Conclusion: x64 at the moment is better than x86 if you have a reason. Most people don't have one currently. But If you have a reason, the x64 is the way to go.

[tin foil hat]Is there any thought on if these "leaked" copies of win7 found on torrent sites haven't been tempared with and have spyware/root kits on them?[/tin foil hat]

I guess that's just a risk some people are willing to take.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.