Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Best 32-Bit Windows System In 2012?

timothy posted about 2 years ago | from the looking-backwards-fondly dept.

Operating Systems 313

First time accepted submitter justthinkit writes "I have a number of applications that will not run on 64-bit Windows, but I would like to gain the benefits (most better caching) of having more than 4GB of RAM. Am I stuck with these Windows operating systems? And why is Windows Server 2008 Datacenter and Enterprise not included on that page? Should I go with a Linux or Win 7/8 system, and run a VM of Windows XP? Is this a solved problem or a lost cause?"

Sorry! There are no comments related to the filter you selected.

Windows 7 compatibility mode (5, Interesting)

pak9rabid (1011935) | about 2 years ago | (#41967797)

What's wrong with running Windows 7 x64, and running your 32-bit applications in compatibility mode?

Re:Windows 7 compatibility mode (4, Interesting)

mastershake82 (948396) | about 2 years ago | (#41967869)

Generally, if they have applications that will not run on 64-bit Windows, it is because the applications are 16-bit, not 32-bit.

Re:Windows 7 compatibility mode (5, Informative)

Spad (470073) | about 2 years ago | (#41967961)

Or they have shoddy legacy code that checks for 64-bit systems and refuses to run on them in the same way that a lot of older websites still keep insisting that you upgrade to IE6 in order to view them in their full glory because someone did a != instead of a =

Re:Windows 7 compatibility mode (3, Informative)

Spad (470073) | about 2 years ago | (#41967987)

<=, obviously

Re:Windows 7 compatibility mode (-1, Flamebait)

Impy the Impiuos Imp (442658) | about 2 years ago | (#41968695)

All these dozens of posts.

Just recompile the stuff.

"I don't know how, I mean, how will that fix it?"

Force int to 16 or 32-bit accordingly and...

"We don't have the source code."

Well, just rewrite it. Good god.

"I don't know ho..."

MOOOOOOOOOVE!!!

Re:Windows 7 compatibility mode (4, Informative)

adonoman (624929) | about 2 years ago | (#41968057)

XP mode on 64-bit Windows 7 can run most 16-bit apps.

Re:Windows 7 compatibility mode (0)

neokushan (932374) | about 2 years ago | (#41968099)

Do you have a link or source to back that up? The last time I tried running a 16bit application, it was years ago and didn't work at all. I was under the belief that all 16bit stuff wouldn't work.

Re:Windows 7 compatibility mode (1)

HarrySquatter (1698416) | about 2 years ago | (#41968525)

Did you run it in "XP mode"?

Re:Windows 7 compatibility mode (0, Redundant)

neokushan (932374) | about 2 years ago | (#41968585)

Yes.

See here: http://support.microsoft.com/kb/896458?wa=wsignin1.0 [microsoft.com]

64-bit versions of Windows do not support 16-bit components, 16-bit processes, or 16-bit applications

You are the first person I've seen to ever claim otherwise which is why I'm keen to hear more.

Windows 3.1 Mode (1)

tepples (727027) | about 2 years ago | (#41968609)

Say I were to install VirtualBox on a PC running the x86-64 version of Windows 7. And say I were to buy a USB floppy drive in order to read an authentic set of Windows 3.1 install media. Could I run Windows 3.1 in this VirtualBox?

Re:Windows 7 compatibility mode (2, Informative)

Anonymous Coward | about 2 years ago | (#41968645)

Did you try it in Windows 7's XP mode, which actually starts a copy of XP in a virtual machine?

Re:Windows 7 compatibility mode (4, Informative)

neokushan (932374) | about 2 years ago | (#41968741)

Ahhh, I think I understand what you mean now. By "XP mode", you're in fact referring to this: http://windows.microsoft.com/is-IS/windows7/products/features/windows-xp-mode [microsoft.com]

When silly me was thinking of this: http://filext.com/images/vista_compatibility_mode.gif [filext.com]

Yes, the former will work for 16-bit applications. For those reading this thread, I should point out that "XP Mode" is not installed by default in Windows 7 or anything but it is a worthwhile addon if you run legacy apps.

Re:Windows 7 compatibility mode (0)

Anonymous Coward | about 2 years ago | (#41968701)

I run old (Pascal) 16-bit applications in XP Mode (Virtual PC) under Windows 7 64-bit. It's the very reason I installed XP mode and it works perfectly.

Re:Windows 7 compatibility mode (1)

Anonymous Coward | about 2 years ago | (#41968753)

Yes.

See here: http://support.microsoft.com/kb/896458?wa=wsignin1.0 [microsoft.com]

64-bit versions of Windows do not support 16-bit components, 16-bit processes, or 16-bit applications

You are the first person I've seen to ever claim otherwise which is why I'm keen to hear more.

Windows XP Mode is NOT running 64-bit. It is a 32-bit VM running under Windows 7, which may be running either 32 or 64-bit.

Re:Windows 7 compatibility mode (2)

Chris Mattern (191822) | about 2 years ago | (#41968125)

No, it can't. I don't think you realize how archaic 16-bit mode is. 16-bit mode was for running on *286* Windows. If you had a 386 you ran in 32 bits.

Re:Windows 7 compatibility mode (4, Informative)

tgd (2822) | about 2 years ago | (#41968203)

No, it can't. I don't think you realize how archaic 16-bit mode is. 16-bit mode was for running on *286* Windows. If you had a 386 you ran in 32 bits.

No, he's correct. You're talking about WoW32, he's talking about XP Mode. XP Mode is "Windows Virtual PC" and runs XP. 16 bit apps run fine in there.

They won't run in WoW, because the 16 bit support is a different subsystem in Windows, its not part of Win32.

Re:Windows 7 compatibility mode (1)

medv4380 (1604309) | about 2 years ago | (#41968241)

16 Bit is for Windows 3.1x and earlier in this case. We didn't have a 32 bit Windows OS until Windows 95/NT. The 386 may have been a 32bit chip in 85 but we didn't have 32 bit windows until 10 years later. I'm sure there is some technical reason for not keeping the number in sync with the chip, or maybe fools where in charge then and were upgrading their feet on upgrading. However, a 16bit windows application is for 3.1x which were the target market for many 386 and 486 processors.

Re:Windows 7 compatibility mode (2)

0123456 (636235) | about 2 years ago | (#41968569)

No, Windows 3.x could also run 32-bit apps. Windows 95 just replaced some of the 16-bit layer with 32-bit code, for example display drivers were still 16-bit.

NT was the first fully 32-bit Windows, and the biggest issue with Windows 95 programs is that many of them were 32-bit but used 16-bit installers; you can run them on 64-bit Windows 7, but you can't install them.

Re:Windows 7 compatibility mode (1)

guruevi (827432) | about 2 years ago | (#41968723)

There was no 32-bit Windows until NT and no consumer Windows was fully 32-bit until XP. Windows 95 introduced (some) 32-bit drivers and an interface that would allow you to run (some) 32-bit applications (a lot like DOS4GW did way better back then) but the underlying system was still MS-DOS.

The reason 8-bit and 16-bit (pure DOS and early Windows) applications are nigh impossible to run on 64-bit systems is because they request a switch to real mode from the CPU which means direct access to the full memory space and hardware.

DOSBox might be a solution here.

Re:Windows 7 compatibility mode (1)

DJRumpy (1345787) | about 2 years ago | (#41968549)

I'm a bit surprised everyone is looking for a software solution when a simple hardware solution would probably meet the needs posed by this question. Specifically they were looking for the benefits of caching for disk access. Simply provide a server with higher capacity SSD's. In essence, you get the perks of having data 'cached' in memory without having to beat yourself up looking to cram a square peg in a round hole.

That will at least buy you some time to beat some sense into whoever is keeping this legacy software around that it's well beyond time to get it upgraded to something more current than a few decades old.

Remember 16-bit games? (1)

tepples (727027) | about 2 years ago | (#41968633)

That will at least buy you some time to beat some sense into whoever is keeping this legacy software around that it's well beyond time to get it upgraded to something more current than a few decades old.

Sometimes legacy software has no still-maintained close substitute, and some sort of virtual machine is the answer. True, the OP probably isn't asking about games, but I'll still give an example of a 16-bit app that hasn't been upgraded: Is New Super Mario Bros. Wii for Wii an adequate substitute for an old 16-bit app like Super Mario World for Super NES?

Re:Windows 7 compatibility mode (0)

Anonymous Coward | about 2 years ago | (#41967939)

It doesnt work that easy way. If yes, then he wont be here asking for help.

Re:Windows 7 compatibility mode (1)

medv4380 (1604309) | about 2 years ago | (#41967967)

Compatibility mode doesn't work if the program uses 16bit Legacy Code. Yea, I know, it should have been eliminated back about 15 years ago, but my employer has to run data though a clients "checker" and it will not install on Any 64bit windows for that very issue. If that is what the problem is then the program in question must be updated, or you are married to a 32bit Windows OS.

Re:Windows 7 compatibility mode (1)

dmacleod808 (729707) | about 2 years ago | (#41968343)

I would be unhappily married if I was limited to how much of my "Ram" size i could use in this marriage.

Re: Windows 7 compatibility mode (0)

Anonymous Coward | about 2 years ago | (#41968327)

A lot of my companies software written before the spread of 64 bit Windows liked to assume that files were in Program Files, not Program Files (x86).

Im sure a lot of software just has various bugs along these lines. It is not because the APIs are missing.

Re:Windows 7 compatibility mode (2)

Runaway1956 (1322357) | about 2 years ago | (#41968503)

I've scrolled down the page, and read a lot of good answers. With a little consideration, I have to agree with those who suggest, "It's time to upgrade your software!" As has already been pointed out, 16 bit software was on it's way out when the 386 processor came of the manufacturing lines. 16 bit software was carried by sneakernet on floppy drives - both 5 and 3 inch. 16 bit software predates Windows 3.1. Dump that shit, and pay some zit-faced intern to code something to do what you need. The intern can give you something at least as reliable as the crap that was written to run on a 286 or earlier processor.

If you need something more reliable than zit-face can offer, then hire a programmer. Any job that was done once, can be done again. Your software is replaceable.

Start over, choose an operating system, tell the programmer what you need to do, let him choose a language, then get the hell out of his way. He'll call you when he has questions, or needs you to test something.

Re:Windows 7 compatibility mode (5, Insightful)

Anonymous Coward | about 2 years ago | (#41968761)

For all you know he's got a 15 year old piece of industrial kit that needs 15 year old software to interface with it. Assembly line equipment maybe, oil drilling gear, CNC stuff, who the hell knows. A lot of this stuff is unsupported or the original vendor has vanished. Maybe this hardware still has years of life left in it, and the replacement value could be in the millions.

Re:Windows 7 compatibility mode (0)

Anonymous Coward | about 2 years ago | (#41968575)

Just buy win7 32 bit version... It exists... I think the full box edition lets you pick. OEM you usually get one or the other...

PAE-intolerant drivers (1)

tepples (727027) | about 2 years ago | (#41968677)

OP wrote:

I would like to gain the benefits (most better caching) of having more than 4GB of RAM.

Anonymous Coward wrote:

Just buy win7 32 bit version

The 32-bit version of Windows 7 won't use much more than 3 GB of RAM because too many 32-bit drivers for desktop PC hardware are intolerant of PAE.

I'm not an expert (0)

Anonymous Coward | about 2 years ago | (#41967815)

But you should check if the PAE [microsoft.com] patches would work for you.

Re:I'm not an expert (1)

Jawbox (113491) | about 2 years ago | (#41967907)

Just go with Server 2003 with PAE support. Same base as XP really with PAE support built in.

Re:I'm not an expert (1)

kthreadd (1558445) | about 2 years ago | (#41968019)

A problem with both Server 2003 and XP is that they will be unsupported as of April 2014. If 32 bit Windows is still required in 2012, then my guess is it will be in 2014 as well. So if possible I would go with something more modern.

VM + WinXP ? (0)

Anonymous Coward | about 2 years ago | (#41967821)

I fail to see how running Windows XP will help you whatsoever. It'll have the same limitation as Windows XP "stand-alone". Unless you meant "running several VM in parallel, each with an instance of WinXP" ?

Depends on the 3D (5, Informative)

Krneki (1192201) | about 2 years ago | (#41967823)

Do you need 3D accelerated graphics? If not, VM is the way to go. Just RDP to the machine and do what you have to do.

Re:Depends on the 3D (0)

Anonymous Coward | about 2 years ago | (#41967953)

VM? Really? If you are looking to deploy to one or two users then maybe. Anything larger, your costs for hardware will be quite high. A TS or RDS environment may be better suited to your needs and will give you a MUCH higher concurrency level.

Re:Depends on the 3D (1)

h4rr4r (612664) | about 2 years ago | (#41968013)

You would still want to vm the TS or RDS machines. Since you will have trouble finding drivers for such outdated operating systems.

VMs are not CPU emulators (0)

Anonymous Coward | about 2 years ago | (#41967839)

The guest CPU is the same as the host CPU on all popular VM solutions. If there is something in your applications that fails in the presence of a 64bit CPU, a VM isn't going to solve your problem.

Re:VMs are not CPU emulators (3, Insightful)

Joce640k (829181) | about 2 years ago | (#41967919)

A VM can have a 32-bit OS installed.

Re:VMs are not CPU emulators (4, Funny)

djsmiley (752149) | about 2 years ago | (#41967943)

VM's can fake a 32bit cpu.... its almost like there isn't a real CPU and someone is just pretending or something...

Re:VMs are not CPU emulators (1)

Gr8Apes (679165) | about 2 years ago | (#41968117)

VM's can fake a 32bit cpu.... its almost like there isn't a real CPU and someone is just pretending or something...

Guess the OP failed to comprehend the "Virtual" machine....

Re:VMs are not CPU emulators (0)

Anonymous Coward | about 2 years ago | (#41968349)

Where do I set the type of CPU for the VM, for example in Virtualbox? Can't find it? Wonder why not.

Re:VMs are not CPU emulators (1)

Gr8Apes (679165) | about 2 years ago | (#41968697)

VMWare used to use software emulated CPUs, at least on OSX. It's why they were an order of magnitude slower than Parallels. You could also have more logical CPUs than actual cores on your system - at a huge performance hit, of course. I don't recall if you could set the specific CPU type, or if it was fixed - to a 32 bit CPU. So there was definitely some emulation going on there.

Real mode to protected mode to long mode (1)

tepples (727027) | about 2 years ago | (#41968717)

All x86 and x86-64 CPUs boot into 16-bit "real mode". A 16-bit or 32-bit OS just never bothers to switch it into 64-bit "long mode", the point of no return from which only a reboot can take the CPU back to real mode.

Re:VMs are not CPU emulators (0)

Anonymous Coward | about 2 years ago | (#41968177)

A 64bit CPU can have a 32bit OS installed. That's not the point. If the 64bit CPU is what causes his applications to fail (and not some software environment problem), then running the OS in a VM won't help because it doesn't change the CPU that the application will see. VMs are not CPU emulators. The code inside the VM runs on the host CPU.

Re:VMs are not CPU emulators (1)

hawkinspeter (831501) | about 2 years ago | (#41968425)

Really?

Re:VMs are not CPU emulators (3, Interesting)

fuzzyfuzzyfungus (1223518) | about 2 years ago | (#41968519)

A 64bit CPU can have a 32bit OS installed. That's not the point. If the 64bit CPU is what causes his applications to fail (and not some software environment problem), then running the OS in a VM won't help because it doesn't change the CPU that the application will see. VMs are not CPU emulators. The code inside the VM runs on the host CPU.

No VM built for resource management convenience in a standard production environment is a CPU emulator, because that's horribly inefficient compared to doing passthrough. If you don't mind incurring substantial overhead, though, something like QEMU can do full emulation of an x86, ARM, MIPS, or SPARC CPU. Not at all fast, compared to passthrough(also supported with KVM or xen); but it can be done.

Re:VMs are not CPU emulators (0)

Anonymous Coward | about 2 years ago | (#41968043)

AMD64 CPUs can run in IA32 mode, but while 64-bit operating systems often do not perfectly mimic their 32-bit variants, virtualization allows you to run a full 32-bit operating system instead.

Re:VMs are not CPU emulators (2)

fuzzyfuzzyfungus (1223518) | about 2 years ago | (#41968369)

The guest CPU is the same as the host CPU on all popular VM solutions. If there is something in your applications that fails in the presence of a 64bit CPU, a VM isn't going to solve your problem.

I'm sure some thrifty assembly jockey writing vital-but-dreadful line of business applications in the 80s has a counterexample; but the mere presence of a 64bit CPU shouldn't cause any trouble for 16 bit applications. The issue is that MS dropped support for 16 bit applications on all 64-bit OS builds. A 32-bit OS on a CPU that supports 64 bits will run 16 bit applications without incident; but will only be able to use the first 4GB of address space without PAE, hence the poster's desire for a 32 bit OS with PAE support.

All 32-bit Windows support PAE (0)

Anonymous Coward | about 2 years ago | (#41967865)

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366796%28v=vs.85%29.aspx

The story seems to link to an outdated document. PAE is definitely supported on 32-bit Windows 7 and Server 2008.

Re:All 32-bit Windows support PAE (0)

Anonymous Coward | about 2 years ago | (#41967969)

More than 4GB is a bad idea if you're running a 32bit Windows. The drivers just aren't reliable if there is more RAM than can be linearly addressed with 32 bits. Some drivers will DMA to the wrong physical memory. Don't do it. When you need more address bits, add address bits. Only people who have no low level programming experience even consider memory segmentation.

Re:All 32-bit Windows support PAE (1)

afidel (530433) | about 2 years ago | (#41968115)

Nope, Windows 7 32bit limits you to 4GB [microsoft.com] of ram for driver compatibility reasons. The last 32bit consumer OS from MS that actually supported greater than 4GB of ram was Windows XP SP1.

You do realize you can run things in 32 bit mode? (0)

Anonymous Coward | about 2 years ago | (#41967877)

However you also have to deal with developers who's apps actually check what version you're running and won't even try to install.

Re:You do realize you can run things in 32 bit mod (4, Informative)

fuzzyfuzzyfungus (1223518) | about 2 years ago | (#41968579)

However you also have to deal with developers who's apps actually check what version you're running and won't even try to install.

It isn't much fun; but the Microsoft Application Compatibility Toolkit provides a mechanism for telling a large number of potentially useful lies to a program about the environment it is living in... Figuring out which ones you need is an exercise for the reader; but if you manage it you can then have the OS automatically furnish those little falsehoods every time the designated program runs.

It's a more powerful and granular version of the 'run in compatibility mode' feature, designed to keep the whiny enterprise customers happy.

applications (0)

Anonymous Coward | about 2 years ago | (#41967889)

Buy applications that will do the same but work on 64-bit operating systems.
If they are in house applications, change them to accommodate 64-bit operating systems.

If changing application is not possible you'll have a struggle, so don't just brush off the cost of changing the application, changing OS will cost you as well.

Based on just the info you gave any further advice is useless. If your applications don't run on 64-bit, will they run on another OS? We don't know, you didn't tell us.
Are there any other requirements for your OS? You want office, MS exchange, outlook, domain services, ...

I think you have no idea what you want or need, asking strangers won't change that.

Re:applications (0)

Anonymous Coward | about 2 years ago | (#41968229)

Buy applications that will do the same but work on 64-bit operating systems.
If they are in house applications, change them to accommodate 64-bit operating systems.

Ooh.... thank you for that "useful" non-advice that I'm sure no-one else had considered. Nice pat reply that lets you feel smug and superior while doing the easy part ("simply rewrite all your apps as 64-bit compatible!") while not acknowledging that this would likely be a major- if not impossible- undertaking and offering no help as to how it might be done.

Based on just the info you gave any further advice is useless. If your applications don't run on 64-bit, will they run on another OS? We don't know, you didn't tell us.
Are there any other requirements for your OS? You want office, MS exchange, outlook, domain services, ...

This may have been a reasonable and legitimate request for clarification if it hadn't already been obvious that you weren't really interested in helping.

Re:applications (0)

MadChicken (36468) | about 2 years ago | (#41968799)

I don't think that was unreasonable. If you have critical business apps running 16-bit code you need to prioritize their replacements IMMEDIATELY. That's certainly not impossible, though you will need someone skilled with both legacy and modern code.

Changing them to accommodate 64-bit OSes doesn't necessarily mean totally rewriting them, either. Maybe there are some non-compatible libraries that need to be swapped out, with a few code changes.

Re:applications (1)

Teun (17872) | about 2 years ago | (#41968771)

If they are in house applications, change them to accommodate 64-bit operating systems.

Hehe, during the last 10 years we were twice able to convince the guys with the budget to spend some on a new version of the software.
Both times they forgot to communicate with 'the field' and came up with something totally unacceptable.

The original software was developed by a field engineer (Hi Q!), right there on the job and he was always looking for input by the users and clients, it's near perfect but new engineers do have to get their head around the 8.3 file naming convention :)

http://serverfault.com/ (1, Insightful)

Anonymous Coward | about 2 years ago | (#41967891)

Ask at http://serverfault.com/ and describe your problem in greater detail.

4GB memory vs. 32-bit apps... (3, Informative)

xxxJonBoyxxx (565205) | about 2 years ago | (#41967893)

>> I have a number of applications that will not run on 64-bit Windows, but I would like...more than 4GB of RAM

Do you realize that many of your 32-bit applications would freak out in a 4GB memory space?

Re:4GB memory vs. 32-bit apps... (0)

Anonymous Coward | about 2 years ago | (#41967941)

I don't think he wants his 32-bit apps to have more than the usual 2GB memory space. He just wants the system as a whole to have more than 4GB of RAM for things like disk access caches.

Re:4GB memory vs. 32-bit apps... (2)

The MAZZTer (911996) | about 2 years ago | (#41967945)

Each process is limited to 2gb but you can run multiple processes.

Re:4GB memory vs. 32-bit apps... (0)

Anonymous Coward | about 2 years ago | (#41967965)

It's called PAE. Ugly way for each app to have 32-bit address space, but the aggregate available memory to be higher. So no, a single process couldn't have more than 4GB of ram, but no 32-bit only app obviously needs that anyway, but the total available memory would actually be fine.

Re:4GB memory vs. 32-bit apps... (2)

Minwee (522556) | about 2 years ago | (#41967993)

>> I have a number of applications that will not run on 64-bit Windows, but I would like...more than 4GB of RAM

Do you realize that many of your 32-bit applications would freak out in a 4GB memory space?

"...to gain the benefits (most better caching) of having...". That's the part you cut out, and it clearly points out one example of how the operating system can benefit from having more physical memory without having to assign it all to a single process. That's the way that virtual memory works -- The OS can have a huge pool of memory while each process only sees a small portion of it.

Re:4GB memory vs. 32-bit apps... (1)

sl4shd0rk (755837) | about 2 years ago | (#41968421)

Do you realize that many of your 32-bit applications would freak out in a 4GB memory space?

Precisely how? A 32-bit app, architecturally, is designed to access up to 4Gig of addressable Memory. This is the reason for 32 bits. If the application in question is "freaking out" then it's either not a true 32-bit application, or it's been written with heavy use of kludge.

Re:4GB memory vs. 32-bit apps... (2)

0123456 (636235) | about 2 years ago | (#41968599)

Some Windows apps do stupid things and crash when they see a 'negative' memory address (i.e. > 2GB). But they're pretty rare these days since so many people run 32-bit apps on 64-bit Windows.

Re:4GB memory vs. 32-bit apps... (0)

Anonymous Coward | about 2 years ago | (#41968521)

You can't have more then 3.2 or something GB of memory.

And there is an even lower band for each process (1.2 or 1.4), memory eludes me, it was a long time ago I had those issues.

If you need more memory then that, sorry... can't do. It is not a question of OS... is a question of address space and CPUs (what the OS can do just reflects it on).

It is a lost cause. (-1)

Anonymous Coward | about 2 years ago | (#41967903)

The controlling interest of the Microsoft "universe" does not give a rat's ass about your old 32-bit legacy apps.
You are expected to ditch them all, repurchase everything 64-bit Windows compatible or you are guaranteed to be left behind.

SysWOW64 (2)

VIPERsssss (907375) | about 2 years ago | (#41967909)

I've gotten some cranky Win32 apps to work on Win7 64 by getting the 32-bit dll files in the C:\Windows\SysWOW64 folder instead of C:\Windows\System32.

The naming conventions don't make any damn sense; they should have kept System32 for 32-bit files and created System64 for 64-bit files. But that's just me.

Re:SysWOW64 (1)

neokushan (932374) | about 2 years ago | (#41968211)

I remember reading somewhere that System32 is called that for another reason (it isn't anything to do with the shift to 32bit windows back in the mid-90's). I can't for the life of me remember what that reason was, though. Nor can I remember where I read it.

It's entirely possible I just made that up, but if anyone knows what I'm talking about, I'd love to be reminded.

Re:SysWOW64 (2)

neokushan (932374) | about 2 years ago | (#41968387)

Actually I think I've found a reasonable source that explains it:

http://technet.microsoft.com/en-us/magazine/ff955767.aspx [microsoft.com]

So originally it was for 32bit DLLS, then Windows 95 went and ruined it anyway by putting 16 and 32bit stuff together (gj, microsoft). However these days the reason they do it is for .bat scripts that were hard coded to use System32 to do things like update the registry - the .bat would be running as a 64bit process but the hardcoded path to System32 would mean it would attempt to run a 32bit regedit.exe (for example), causing it to fail in doing what it was meant to do. So basically, the whole SysWOW64 thing is for backwards compatibility.

WOW! (1)

Iniamyen (2440798) | about 2 years ago | (#41967911)

I never knew that I had so many 64-bit applications. Thanks, Microsoft!

Graphics problems (1)

Russ1642 (1087959) | about 2 years ago | (#41967929)

We have some crappy in-house database software that will only run properly if the graphics depth is set to 16bit. Without that change the window rendering gets all messed up. I never ever would have guessed that's what the problem was.

Use a VM for all older software. (4, Insightful)

concealment (2447304) | about 2 years ago | (#41967951)

Think about this critically: you probably want your operating system to be the master of its new hardware, and then you want it to interpret the needs of your older software.

If compatibility mode won't do it, set yourself up a VM and run everything in there. You can share a drive with the host OS and thus be nearly transparent.

It doesn't make sense to me to hobble the OS in order to run older software, when the newer OS is better with the newer hardware.

Your answers with as much detail as you provided. (5, Funny)

djsmiley (752149) | about 2 years ago | (#41967983)

1. Yes
2. Dunno
3. Yes
4. Yes
5.... errm yes?

Recommendation (0)

Anonymous Coward | about 2 years ago | (#41967985)

In my opinion stay with Windows 7 32 bits. It can reconigze until 3.2 GB and my guess is that your old apps arent that demanding. Or go back in time and install windows XP 32 bits and your apps will run natively. Stay away from windows Vista.

Re:Recommendation (0)

Anonymous Coward | about 2 years ago | (#41968419)

There are relatively simple hacks around that allow it to use far more than 4 GB, though it's up to you to make sure the drivers are compatible with real PAE.

Windows 2008 Enteprise (0)

Anonymous Coward | about 2 years ago | (#41967995)

Sounds like you have a mess on your hands.

Windows 2008 Datacenter and Enteprise do not use the /PAE flag (its always on). That is why its not on that list.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#physical_memory_limits_windows_server_2008

I would buy 2008 ent and virtualize it on Hyper-V Server 2012 (the free one) or Windows Server 2012. I would do this even if its the only guest on the box. It makes for easy hardware upgrades later.

WineHQ (0)

Anonymous Coward | about 2 years ago | (#41968001)

Wine has made tremendous progress in the past few years. Search winehq to see how well the applications you need are supported, and read the comments to see what others had to do to get them to work correctly.

Linux with some kind of compatibility layer (1)

kthreadd (1558445) | about 2 years ago | (#41968047)

I would try running it under Linux with Wine. Windows may not be necessary if it's just for a couple of applications.

Re:Linux with some kind of compatibility layer (2)

hobarrera (2008506) | about 2 years ago | (#41968453)

Indeed. I've found that some old applications (especially games from around 1999), tend to work on wine, while they fail to run on Windows > XP.

They may be few, but it's worth a try.

What the OP (1)

liquidweaver (1988660) | about 2 years ago | (#41968055)

It's implied that they have userland software that for some reason won't work in 64 bit windows. The asker then goes on to suggest using 6 different OS's as well, as if their finicky software has no problem with linux or windows from XP to 8. Is the real question about PAE? I feel like we are missing something here.

Re:What the OP (2)

damnbunni (1215350) | about 2 years ago | (#41968175)

I suspect their problem is that they have 16 bit Windows code to run. 64 bit Windows can't run 16 bit code.

16 bit Windows code will work in 32 bit Windows (any version) or a 32 bit Windows running in a virtual machine on a 64 bit OS.

(Myself, I keep an old Win98 laptop around to run Quicken 6 on. Why? It's the only thing that can sync with the version of Pocket Quicken I have decades of checkbook data in. And it's 16 bit Windows 3.1 code.)

Re:What the OP (1)

NJRoadfan (1254248) | about 2 years ago | (#41968333)

The latest version of Pocket Quicken (2.5) can apparently sync with Quicken 2010. Of course both OSes Pocket Quicken supported are just as obsolete as Windows 98 at this point!

Re:What the OP (1)

damnbunni (1215350) | about 2 years ago | (#41968493)

I think Pocket Quicken's version has reset to 1 several times, each time PQ changed developers, it seems.

Mine is, obviously, very old. However, it still works well, which is the reason I use it. (I don't use desktop Quicken, really; I just synch to it to back up my PQ data.)

And desktop Quicken never seems to support a given Pocket Quicken very long. (The Pocket Quicken I have was sold for longer than a desktop Quicken that synchs with it. Gah.)

Yet another stupid Ask Slashdot question (-1, Flamebait)

vinn (4370) | about 2 years ago | (#41968083)

I'm getting really sick of the quality of "Ask Slashdot" submissions. Things really seem to have gone downhill in the past year in this category. This is a retarded question that quite a few 8th graders could answer. In other words, your apps probably work fine and for the very few that don't, run a VM. Why you're still on XP is beyond me.

Re:Yet another stupid Ask Slashdot question (0)

Anonymous Coward | about 2 years ago | (#41968385)

Then go to another forum that suits your fancy. Not all people who come here are as experienced, smart or arrogant as you.

Cloud duh... (1)

Anonymous Coward | about 2 years ago | (#41968093)

Just VM and RDS with a RDP on the "cloud" your apps and issue Surface pads to everyone including your mailman. Also, you owe me $120,000 in consulting fees. And I do not expect company stock well not your companies anyway.

Windows memory limitations (3, Informative)

ilsaloving (1534307) | about 2 years ago | (#41968123)

First and foremost, all consumer 32-bit windows versions are licensed to top out at 4GB. If you want more than 4GB, you will have to buy a (reassuringly expensive) server edition that permits it. Done. End of story.

The only other alternative is to get a 64-bit version of Windows 7 Pro. The Professional (and up) versions of Windows include something called compatibility mode, which is a free copy of Windows XP 32-bit, running inside a virtual machine. That's probably going to be your most cost-effective way of running your legacy apps on top of a 64-bit machine with oodles of RAM.

Re:Windows memory limitations (1)

ilsaloving (1534307) | about 2 years ago | (#41968163)

I forgot to mention... if you go the virtual machine route, then there's no functional difference between what I stated, or using a Linux machine or a Mac and running VM software on top of that instead. There is a difference in cost, however, because you'll need to get VM software which may or may not be free, and you'll need to purchase a retail copy of Windows XP.

Re:Windows memory limitations (0)

Anonymous Coward | about 2 years ago | (#41968531)

> If you want more than 4GB, you will have to buy a (reassuringly expensive) server edition that permits it.

Or remove that restriction. Not that difficult to do really, though the code signing causes some annoyance.

How About SSD's (0)

Anonymous Coward | about 2 years ago | (#41968259)

If you wanted faster system performance, maybe using ssd's or even a small ssd as your swap & temp drive should give quite a speed increase. Surely not as fast as real ram, but your not stuck to 4GB. Also, use a video card or set the onboard video with a minimum amount of ram, 32gb or less. I think the 4gb limit is total ram, so 4GB - 512MB video card leaves only 3.5GB system ram available.

Go with linux (0)

Anonymous Coward | about 2 years ago | (#41968361)

I'm sure all the 32 bit windows apps that don't run under 64 bit windows will work just fine on unga bunga linux 2.0

Windows 7 32bit 4GB Kernel Hack (2)

mcnazar (1231382) | about 2 years ago | (#41968383)

Not sure if this is of any use but the Windows 7 32bit Kernel can be hacked to properly support PAE and allow 64GB accessible memory under W7 32bit. W7 32bit was supposed include full PAE support but was nurfed at the last moment due to third party device drivers getting confused over the > 4GB memory space (I never had this issue).

A couple caveats come to mind:

# You have to patch the 32bit Kernel. Linky: http://superuser.com/a/95309 [superuser.com]
# Although you have access to >4GB of memory, no single process can use more than 4GB (minus graphics card memory)

I have used such a setup under W7 32bit SP1 for the last six months without issue as I needed the extra memory to run multiple VMs simultaneously.

HTH and good luck!

See if you can upgrade or replace them (2)

Sycraft-fu (314770) | about 2 years ago | (#41968411)

Seriously, it is real, real hard for me to find programs that don't run on 64-bit Windows these days. Windows has a flawless 32-bit user mode compatibility layer, so all 32-bit apps run no problem. The only cases that you have problems are:

1) Kernel mode stuff. There is no 32-bit kernel mode shit on 64-bit.

2) 16-bit programs. 64-bit Windows does have the 16-bit compatibility layer since there's no 16-bit mode you can access form long mode on the CPU.

3) Stupid programs that check the version and fail out, even though they'd actually run.

There just aren't many of those anymore. We use some amazingly fussy engineering programs at work, and they all run on 64-bit Windows these days.

So if your software really won't work, look and see if there's an update, or something else that'll do the job. If you just haven't tried it, then try it. Get a copy of 7 64-bit and see. I bet you have no problems. If you really have old 16-bit programs you need to run, do it in a VM, they can't benefit from modern system resources anyhow.

Depends on the exact usage...but still VM (0)

Anonymous Coward | about 2 years ago | (#41968431)

What kind of applications? for whom, only for 1 person, 20? What load? Why would you need more than 4gb for a 32bit app? It depends

I would go for Windows XP (there is a unoffical stripped down version that is to 500mb when installed, taking around 200mb ram .i.e http://www.youtube.com/watch?v=m8ipsEdk-Hk) on VirtualBox that you can run on anything (Linux, Macos, Windows 2008), with 32gb you can run at least 10 of those, of course it depends on the use case, etc

That's at least what I did with a vpn client that would run only on a 32bit windows.

Extra memory (1)

Maximum Prophet (716608) | about 2 years ago | (#41968533)

There's a commercial product, I can't remember the name, that allows you to run Windows XP on a machine with >4GB of memory. Processes still have their usual memory limit, but the extra memory is used for disk cache and page space cache. Your processes will essentially be paging to RAM disk, which seems silly, it but works.

Re:Extra memory (0)

Anonymous Coward | about 2 years ago | (#41968641)

There is some product like that:
But I just use the /3GB and /PAE switch on XP,
or if I have a compatibity problem:
I either switch to Windows 2000 Advanced Server ( 34-bit addressing ),
or run DOS BOX. ( Windows 286 2.1.1 runs fine in it. ).

But compatiblity is the problem, not the amount of memory,
and for that, Windows 2000 Advanced Server seems to fit my needs.

Best of luck

Why is Server 2008 not on the PAE list? (1)

Aphrika (756248) | about 2 years ago | (#41968767)

Because 2008 and 2008 R2 are only available in 64-bit flavours, they do not need to support Physical Address Extension (PAE), which by definition is a way of allowing a 32-bit OS to address more than 4GB RAM.

By caching You mean faster reading??? (0)

Anonymous Coward | about 2 years ago | (#41968801)

If you really want more caching then why not buy a Battery Backed Raid card. You can get ones that take 16GB+ ram and work with somewhat legacy systems. You don't need the batteries if you are just using it for caching reads. Throw in a raid of SSDs (at least for redundancy). SSDs giving 500+ MB read/writes are very budget friendly; 500GB with redundancy at under $600. I would probably try throwing SSDs at the problem first running whatever OS I know will work. Not only will it give you faster reads but you'll get faster writes, too. The speed difference is extreme especially if your apps are doing a lot of random reads and writes. One SSD will saturate 100baseT Ethernet but am guessing it's more of a latency issue*. Another solution is to use a NAS or a VM. But unless I wanted the other benefits of a VM environment, I would try to sticking to running straight on the hardware. Even if you go with a VM solution you'll still get huge speed benefits from setting up the hardware as describe.

*I think you haven't accurately describe what the core issue is it's more I want to run the system with more RAM which is really not a problem but a solution that creates problems while not accomplishing much. But if you just we need faster database returns???? Then it's becomes an easy fix. You don't need more ram for your app which if you do then it's seems only a rewrite would solve you problems.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?