Users to Microsoft: 'Just make Windows faster'

[HawkMan]

For the Userit might seem better in Apple's solution.

but really it's not, and it's not as if 64 bit drivers are in short supply since Vista anyway. and WOW64/32 whtever does an awesoem job. Technically Apple's solution doesn't come near to MS, and that's beside the fact that Vista IS actually i 64 bit OS, while OSX just pretends to be, it's mostly the opposite ot Vista that is 64 bit and pretends to be 32 when needed.

[Brandon Live Veteran]

  CrimsonBetrayal said:

Really? Winlogin handles ctrl+alt+del? Well isn't that handy. I need a whole bloody process running to handle one keystroke combination? It also has changed roles significantly from XP to Vista. The point I was trying to make here was "Transparency!"

He meant that it handles the screen you see when you press Ctrl+Alt+Del, and its functions. Without it you wouldn't be able to login to your machine. Or once you're logged in, you wouldn't be able to switch users, remote in, log off, or do other useful things like that. Winlogin is the parent process for the shell and responsible for creating your user session. You can't just shut it off while user sessions are in progress, as it owns those sessions and is responsible for cleaning up after them.

  giga said:

And what's the problem--a bit more overhead on the kernel? I'd take the convenience of compatibility any day, to be practical.

Everyone says that Microsoft should not drag legacy "cruft" into modern OSes, but when we do cut that stuff, you complain that things aren't compatible! Just can't win I suppose.

[giga Veteran]

  HawkMan said:

For the Userit might seem better in Apple's solution.

but really it's not, and it's not as if 64 bit drivers are in short supply since Vista anyway. and WOW64/32 whtever does an awesoem job. Technically Apple's solution doesn't come near to MS, and that's beside the fact that Vista IS actually i 64 bit OS, while OSX just pretends to be, it's mostly the opposite ot Vista that is 64 bit and pretends to be 32 when needed.

Yes, most modern hardware ship with 64-bit drivers, but one can't immediately judge that the majority of consumers are all running hardware purchased in 2007 or newer. (printers would be a good example)

How does Leopard pretend to be 64-bit? Yes, it's running a 32-bit kernel (which limits itself to max 32GB ram sadly, Snow Leopard is changing this since they're going for two 32/64-bit executables now), but it can still take advantage and run 64-bit applications/processes fine.

If anything though, Apple's solution is a more elegant approach--just run whichever binary needed depending on the system. (that's how they've been able to support both 32 and 64-bit flavors of PPC and Intel since 2006 with just one shipping OS box)

[+Gary7 Subscriber²]

  Brandon Live said:

He meant that it handles the screen you see when you press Ctrl+Alt+Del, and its functions. Without it you wouldn't be able to login to your machine. Or once you're logged in, you wouldn't be able to switch users, remote in, log off, or do other useful things like that. Winlogin is the parent process for the shell and responsible for creating your user session. You can't just shut it off while user sessions are in progress, as it owns those sessions and is responsible for cleaning up after them.

Everyone says that Microsoft should not drag legacy "cruft" into modern OSes, but when we do cut that stuff, you complain that things aren't compatible! Just can't win I suppose.

It takes my machine over two minutes to boot up using Vista Business. This is with a P4 3.0Ghz CPU and 3 GB of ram. This is not acceptable. When I had WinXp pro I could have booted it and read all my email during the time Vista takes to boot.

I Beta tested builds that were better than the final product and booted up a great deal faster.

[Brandon Live Veteran]

  1759 said:

I think how Apple handles 64-bit is way better than MS too. MS seems to go forward by dragging 20 years of legacy cruft with it, and that's it's largest asset and hindrance IMO.

You realize the irony in this statement, right?

Windows went full-on 64-bit, making the entire OS be 64-bit code and cutting tons of legacy support (16-bit Windows, DOS, OS/2 support are all gone, 32-bit drivers are gone). The entire system is 64-bit and a thin virtual machine layer was created to support 32-bit applications.

Contrast this with OS X, which has no 64-bit version yet. They have a 32-bit OS that does the same kind of tricks that DOS / Windows 3.1 did to be "sort of 32-bit." People like you claimed that DOS / Windows 3.x, and heck even Windows 9x were all crap because they had a 16-bit core.

Now when things are reversed you defend Apple for doing hacks to add "64-bit support" to a 32-bit kernel and OS? And you criticize Microsoft for doing what you said we should be doing all along and dropping all sorts of legacy support?

Sorry, you can't have it both ways.

[HawkMan]

Again, if they're running on legacy hardware they shouldn't be runnign Vista anyway, well cetainly not 64 bit :p

and besides it cost less to buy a new compatible printer than to buy new ink for the one you hve, and you'll get better prints to boot.

[Ci7]

  giga said:

How does Leopard pretend to be 64-bit? Yes, it's running a 32-bit kernel (which limits itself to max 32GB ram sadly, Snow Leopard is changing this since they're going for two 32/64-bit executables now), but it can still take advantage and run 64-bit applications/processes fine.

32GB ???

32bit limit you to 4GB or after all address go cut you will be limited with 3.2gb

[giga Veteran]

  HawkMan said:

Again, if they're running on legacy hardware they shouldn't be runnign Vista anyway, well cetainly not 64 bit :p

and besides it cost less to buy a new compatible printer than to buy new ink for the one you hve, and you'll get better prints to boot.

We use laser printers at work--save far more money than dishing out on ripoff inkjets. ;)

  Quote

32bit limit you to 4GB or after all address go cut you will be limited with 3.2gb

Mac Pros/Xserves can address 32GB of ram. 64-bit applications running on those systems can take advantage of it as well. (Lightroom being an example)

Edited August 20, 2008 by giga

[Brandon Live Veteran]

  giga said:

Yes, most modern hardware ship with 64-bit drivers, but one can't immediately judge that the majority of consumers are all running hardware purchased in 2007 or newer. (printers would be a good example)

Moot point. The only machines that come with a 64-bit OS are vetted to support it.

  Quote

If anything though, Apple's solution is a more elegant approach--just run whichever binary needed depending on the system. (that's how they've been able to support both 32 and 64-bit flavors of PPC and Intel since 2006 with just one shipping OS box)

Did you just call fat binaries elegant?

No, elegant is the Windows model, where the entire OS is pure 64-bit code and .NET assemblies are in a processor-neutral form and compiled at run time into 32-bit or 64-bit code depending on the system.

[giga Veteran]

  Brandon Live said:

Moot point. The only machines that come with a 64-bit OS are vetted to support it.

Did you just call fat binaries elegant?

No, elegant is the Windows model, where the entire OS is pure 64-bit code and .NET assemblies are in a processor-neutral form and compiled at run time into 32-bit or 64-bit code depending on the system.

You assume all printers and soundcards have 64-bit drivers?

And yeah, universal binaries that package small executables are pretty elegant compared to having two different shipping versions. They support 4 different system types all in one.

  Quote

Contrast this with OS X, which has no 64-bit version yet. They have a 32-bit OS that does the same kind of tricks that DOS / Windows 3.1 did to be "sort of 32-bit." People like you claimed that DOS / Windows 3.x, and heck even Windows 9x were all crap because they had a 16-bit core.

I didn't claim anything about DOS or 3.x, but I don't see a big deal with the tradeoff they made with Leopard. It can run both 64 and 32-bit processes/applications/libraries just fine if needed, but still maintains full compatibility with 32-bit drivers.

[+Warwagon MVC]

I think vista's speed is just fine. To the person complaining about SVCHOSt taking up 30megs of ram, well buy more ram its cheap.

One problem with vista and this is not a fault with Microsoft but the the fault of the restarted pc manufactures who ship vista on a PC's with 512 megs of ram WITH onboard video which steels what little ram vista has. Which then leaves the the person with only 450 or less of ram. I've had people sit down their computer with that type of situation after I've set it up for them and have them ask me "Why is this computer so slow"

The other problem with vista which IS Microsoft's fault is the number of versions. They don't even tell the user on the side of the manufacture box the difference between the the 4+ are. Microsoft If you are listening, we need 2 versions. One that ships on ALL home machines (home edition) and one for business (pro version)

The home user is to stupid to have to make a choice between 4+ versions of Windows.

Example

a customer was going to go to get a new computer.

I said there is only 2 things you have to look for when buying a new computer.

Vista home Premium and 2 gigs of ram or more if you can afford it.

So they get the computer and call me to come setup it up, they said they found a machine that has everything I said.

I get there. Find the machine has 2 gigs of ram and Vista home Basic. Which then in return came with a single core celeron. I only gave them 2 god damn things they had to keep track of!!! JUST 2!!! and they still ****ed it up.

[Ci7]

  giga said:

You assume all printers and soundcards have 64-bit drivers?

And yeah, universal binaries that package small executables are pretty elegant compared to having two different shipping versions. They support 4 different system types all in one.

in a other word OSX is bloated with useless codes

[HawkMan]

  giga said:

We use laser printers at work--save far more money than dishing out of ripoff inkjets. ;)

Mac Pros/Xserves can address 32GB of ram. 64-bit applications running on those systems can take advantage of it as well. (Lightroom being an example)

And you haven't really checked the prices for the laser cartridges have you ? unless you run the large floor models of LAser printer (and I'm nto talkign the regular ones with several paper cartridges, but the actual MFP floor models).

yeah sureon the larger laser printrs it's cheaper to buy cartridges, but not by a lot.

[giga Veteran]

  Skynetfuture said:

in a other word OSX is bloated with useless codes

Exactly.

  Quote

And you haven't really checked the prices for the laser cartridges have you ? unless you run the large floor models of LAser printer (and I'm nto talkign the regular ones with several paper cartridges, but the actual MFP floor models).

yeah sureon the larger laser printrs it's cheaper to buy cartridges, but not by a lot.

I'm not sure what you just said, but lasers can print 4-5k pages easily without a cartridge change.

[Brandon Live Veteran]

  giga said:

You assume all printers and soundcards have 64-bit drivers?

Did you even read what I said? No one sells a system running 64-bit Windows with an incompatible sound card. Printers by and large don't need printer-specific drivers, there are only a handful of protocols (PostScript and what not) that are all supported by 64-bit Windows. Other printers use only user-mode drivers so they work fine too (user-mode 32-bit drivers are still supported).

Is it 100% compatibility for everybody? Nope. But it's a hell of a lot better than, say, going from OS 9 to OS X.

  Quote

And yeah, universal binaries that package small executables are pretty elegant compared to having two different shipping versions. They support 4 different system types all in one.

That's not elegant at all! It's a total kludge. A hack to support legacy at the expense of on-disk size and performance. Hell, can you imagine the flack Windows would get if they took that approach?

  Quote

I didn't claim anything about DOS or 3.x, but I don't see a big deal with the tradeoff they made with Leopard. It can run both 64 and 32-bit processes/applications/libraries just fine if needed, but still maintains full compatibility with 32-bit drivers.

But it is horribly inefficient. All that legacy 32-bit code at the core of the OS, and all the PAE-like tricks to make the virtual memory system work, is very costly! Some of the greatest improvements in the AMD64 platform are only realized if you have a kernel compiled against that instruction set.

[giga Veteran]

  Brandon Live said:

Did you even read what I said? No one sells a system running 64-bit Windows with an incompatible sound card. Printers by and large don't need printer-specific drivers, there are only a handful of protocols (PostScript and what not) that are all supported by 64-bit Windows. Other printers use only user-mode drivers so they work fine too (user-mode 32-bit drivers are still supported).

Is it 100% compatibility for everybody? Nope. But it's a hell of a lot better than, say, going from OS 9 to OS X.

That's not elegant at all! It's a total kludge. A hack to support legacy at the expense of on-disk size and performance. Hell, can you imagine the flack Windows would get if they took that approach?

But it is horribly inefficient. All that legacy 32-bit code at the core of the OS, and all the PAE-like tricks to make the virtual memory system work, is very costly! Some of the greatest improvements in the AMD64 platform are only realized if you have a kernel compiled against that instruction set.

OS 9 to OS 10 was a mess. Just a total change in the entire architecture of the OS.

But you can't say for sure that everything will work right out of the box for existing hardware that people had before they bought their 64-bit PCs. (example of my dad who wanted to use his TV Tuner on his new PC, but of course there weren't any drivers)

How is it a hack though? The universal binary will only execute if needed depending on your system. It's not kludging your system at all--when was the last time you took a look at mach_kernel?

If you have some solid evidence that you're losing performance because they packed two executables in the UB--please do show. :laugh:

[Brandon Live Veteran]

  giga said:

How is it a hack though? The universal binary will only execute if needed depending on your system. It's not kludging your system at all--when was the last time you took a look at mach_kernel?

Of course it's a kludge. It's the very definition of the word. We can't figure out how to make a single distribution support both 32-bit and 64-bit, so we'll duct tape them together so everybody gets double the amount of code they need. Oh wait, but now we switched architectures, so it's actually four times the filesize they needed! Wow, brilliant! :p

  Quote

If you have some solid evidence that you're losing performance because they packed two executables in the UB--please do show. :laugh:

You lose disk space. Having ever binary be four times as large means that there is 3/4 of the code that goes unused and the disk head must travel over it. In fact I bet they compress the whole thing together on disk which means all that extra code gets loaded into memory and decompressed.

  giga said:

OS 9 to OS 10 was a mess. Just a total change in the entire architecture of the OS.

But you can't say for sure that everything will work right out of the box for existing hardware that people had before they bought their 64-bit PCs. (example of my dad who wanted to use his TV Tuner on his new PC, but of course there weren't any drivers)

Yeah but Vista was a massive architectural change as well, and it broke some legacy hardware support.

So regardless of whether you want to go 32-bit or 64-bit, your best bet is to go with Vista certified hardware. And guess what? Vista certification requires 64-bit support.

[giga Veteran]

The small binary file in the universal binary is the smallest part of the application. It's not a straight multiply by 4 for four supported architectures.

As you can see, the actual resources of Mail (languages, images) make up the largest part of the application, not the executable.

Sure, it won't be near as clean as just supporting one architecture, but that's the tradeoff for convenience on consumers. One version for all (ppc32, ppc64, x86, x86-64)--done.

[Brandon Live Veteran]

  giga said:

The small binary file in the universal binary is the smallest part of the application. It's not a straight multiply by 4 for four supported architectures.

As you can see, the actual resources of Mail (languages, images) make up the largest part of the application, not the executable.

Sure, it won't be near as clean as just supporting one architecture, but that's the tradeoff for convenience on consumers. One version for all (ppc32, ppc64, x86, x86-64)--done.

The executable isn't the only binary... there are also any libraries that it loads. That means any application start and any library load involves executing more code to determine which bits it needs and to do any decompression / extraction work. There's performance overhead for that, that's all I was saying.

[giga Veteran]

  Brandon Live said:

The executable isn't the only binary... there are also any libraries that it loads. That means any application start and any library load involves executing more code to determine which bits it needs and do any decompression / extraction work. There's performance overhead for that, that's all I was saying.

Right, one of my first statement in this thread was that there will be a slight overhead on the kernel. ;)

[abcdefg]

  HawkMan said:

you turned off winlogon.... I don't think so :)

I'm writing this after killing winlogon. What did I win?

[toadeater]

  7Dash8 said:

and Vista does just that. Seriously what are people running Vista on that makes them say it runs slowly?

Even though it is kind of sad that a desktop OS like Vista runs slower and uses more resources than as server OS like Windows Server 2003, that's not what's bothering people. What they have been asking is for Windows 7 to not be yet ANOTHER enlargement of Windows. By 2010 Vista's requirements would be as low as XP's is considered today, but if Windows 7 is yet again bigger and slower, it's going to yet again run like crap and yet again require hardware upgrades. That is what people don't want, another bigger and slower OS that doesn't add much of anything worthwhile. E.g if DX10 was ported to XP, no one would give a damn about Vista. Most of Vista's other features were either not really wanted (DRM & kill switches), or terribly implemented (UAC). On top of that, hundreds of issues left since as far back as Win95 have remained.

So WTF has MS been doing all these years? They keep adding stuff, but they never bothered to fix the foundation.

From what I've read, it seems some of these design decisions have been political. MS has teams implementing these various "features" and every team wants their feature to get precedence, or become popular. You've got middle managers that fight over what's going to be in Windows and whose design to use. There's no real single vision for Windows, it's made by different teams with different agendas. You can see this in how they can't even agree on a consistent look for the GUI.

Feature teams for Windows 7 include (alphabetically):

* Applets and Gadgets

* Assistance and Support Technologies

* Core User Experience

* Customer Engineering and Telemetry

* Deployment and Component Platform

* Desktop Graphics

* Devices and Media

* Devices and Storage

* Documents and Printing

* Engineering System and Tools

* File System

* Find and Organize

* Fundamentals

* Internet Explorer (including IE 8 down-level)

* International

* Kernel & VM

* Media Center

* Networking - Core

* Networking - Enterprise

* Networking - Wireless

* Security

* User Interface Platform

* Windows App Platform

http://blogs.msdn.com/e7/archive/2008/08/1..._5F00_team.aspx

[markwolfe Veteran]

  toadeater said:

...

From what I've read, it seems some of these design decisions have been political. MS has teams implementing these various "features" and every team wants their feature to get precedence, or become popular. You've got middle managers that fight over what's going to be in Windows and whose design to use. There's no real single vision for Windows, it's made by different teams with different agendas. You can see this in how they can't even agree on a consistent look for the GUI.

...

So, what you are saying is that the variety of input and programming philosophies makes the Windows overall UI experience somewhat inconsistent? I guess Apple's much stricter (almost authoritarian) control makes a more consistent UI? And Linux, with the variety of philosophies (KDE, Gnome, e17, fluxbox) yeilds the least consistent experience? *

I fail to see the shocking revelation. :unsure:

* _{for the record, I love my customized Linux desktop and how it works - for me choice is good, but not so for everyone.}

[Brandon Live Veteran]

  giga said:

Right, one of my first statement in this thread was that there will be a slight overhead on the kernel. ;)

Err, no this isn't overhead in the kernel. This is in the loader and in the apps.

The kernel has lots of other overhead because of their design, such as the overhead for managing virtual memory for 64-bit applications, handling long pointers from 32-bit code, switching in and out of long mode, etc. Nevermind the fact that the kernel (and indeed the rest of the OS) and drivers can't actually reap any of the benefits of running on a 64-bit processor.

Then again, I'm not aware of any actual 64-bit applications for the Mac :)

[giga Veteran]

  Brandon Live said:

Err, no this isn't overhead in the kernel. This is in the loader and in the apps.

The kernel has lots of other overhead because of their design, such as the overhead for managing virtual memory for 64-bit applications, handling long pointers from 32-bit code, switching in and out of long mode, etc. Nevermind the fact that the kernel (and indeed the rest of the OS) and drivers can't actually reap any of the benefits of running on a 64-bit processor.

Then again, I'm not aware of any actual 64-bit applications for the Mac :)

I've removed PPC code from my apps before--really not a difference other than a slightly smaller size in the binary. No measurable difference in speed for someone to really care.

Sure the kernel isn't fully 64-bit [yet, till 10.6], but that's not to say that the OS isn't 64-bit. Cocoa, one of the core frameworks of Leopard supports 64-bit. (as well as quartz, opengl, posix, x11 gui, etc) Old and outdated frameworks are already being depreciated--QuickDraw and Carbon for example.

Lightroom is a fully 64-bit application, as is XCode, Mathematica--yes, they take advantage of 64-bit addressing and the increased registers. And no, it's not some jumbled 32 and 64-bit mode. (a 64-bit process can't load 32-bit plugins, etc. )

By the way, it would be more accurate to describe 10.5's kernel as a hybrid 32/64.

  Quote

While i386 support in XNU has existed since the mid-90s, and has been a shipping feature of OpenStep, the i386 part had not been used in Mac OS X until the advent of Intel machines in 2005/2006. And with the introduction of the 64 bit Mac Pro in 2006, x86_64 (AMD64, Intel64, EM64T, x64, ...) support has been added to XNU - but XNU is not a 64 bit kernel, though. XNU supports 64 bit user mode applications, but it is 32 bit itself. Since porting a 32 bit kernel to 64 bit is a big task, it could not be donein just half a year between the introduction of the first Intel machines in January of 2006 (until then, Apple developers had worked on finalizing the 32 bit i386 version) and the introduction of the Mac Pro in August.

There is just a single kernel image for 32 and 64 bit Intel: It is loaded as a 32 bit process in 32 bit protected mode on both kinds of machines, and if 64 bit support is detected, the kernel switches into long mode compatibility mode - a mode that supports running 32 bit code, but also allows easy switching to 64 bit code. So the whole kernel code is still unmodified 32 bit code, but tiny stubs that deal with copying between user address spaces (which can be 64 bit), and the syscall and trap handlers are 64 bit code. Next to being an easy port, this has the extra advantages that the 64 bit capable kernel can still easily support 32 bit KEXTs, and conserves memory by being able to use 32 bit pointers throughout a large part of kernel code. On the flip side, the kernel cannot use the extended x86_64 register set and is restricted to a 32 bit address space.

http://events.ccc.de/congress/2007/Fahrpla..._osx_kernel.pdf