Why is WOW not recursive (and 16, 8 bit)?
In another thread,
In message , VanguardLH writes: [] 32-bit programs run on both 32- and 64-bit versions of Windows. It's the 16-bit programs (whether the program itself or its installer) that will not run on 64-bit versions of Windows (but will run on the 32-bit versions of Windows) due to the WOW (Windows On Windows) emulator: 32-bit Windows comes with its 16-bit WOW32 (Windows 16-bit on Windows 32-bit) emulation aka NTVDM layer while 64-bit Windows comes with its 32-bit WOW64 (Windows 32-bit on Windows 64-bit) emulation layer. There is no WOW32 with 64-bit Windows, just WOW64. https://en.wikipedia.org/wiki/Windows_on_Windows. 32-bit Windows: Runs 16-bit (using WOW32) or native 32-bit programs. 64-bit Windows: Runs 32-bit (using WOW64) or native 64-bit programs but no 16-bit (WOW32) support. (From reading the Wikipedia article, I understand WOW involves virtual machines (sandboxes), intercepts for system calls, dummy zero-size files, and so on, all so the old softwares can run happily.) Why does the 64-bit system not have WOW32 (that can run 16-bit software) - even if it has to itself run under WOW64? (Was there ever 8-bit software for x86 machines - if so, was/is there ever a "WOW16"? If so, same question.) Is there a technical reason, or is it just a meanness decision by Microsoft? [On a separate but related matter: the email/news/etc. software I use - Turnpike - requires the 32-bit shell, which is why I run 32-bit W7. (TP - or part of it - runs as an Explorer extension.) According to the Turnpike newsgroup (I didn't try myself), right up to the last pre-release version of 7-64, it ran fine: when it ran, it invoked the 32-bit shell, which was included with 7-64. However, in the final release version of 7-64, some change had been introduced which stopped TP from functioning properly. TP is 32-bit software; I assume it's its Explorer integration that is the problem (I don't know enough about it to say more). We'd hoped the 7.1 release might fix it, but it didn't. I just mention it out of interest - that there is at least one 32-bit software that _won't_ run under 64.] -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf I'd rather trust the guys in the lab coats who aren't demanding that I get up early on Sundays to apologize for being human. -- Captain Splendid (quoted by "The Real Bev" in mozilla.general, 2014-11-16) |
Why is WOW not recursive (and 16, 8 bit)?
"J. P. Gilliver (John)" wrote
| | Why does the 64-bit system not have WOW32 (that can run 16-bit software) | - even if it has to itself run under WOW64? (Was there ever 8-bit | software for x86 machines - if so, was/is there ever a "WOW16"? If so, | same question.) | | Is there a technical reason, or is it just a meanness decision by | Microsoft? | It's probably possible, but would be a lot of work. And for what? So that a few people can play DOS games. The 32-bit adaptation is referred to as a "shim". In other words, not a VM but rather a kind of hook or in-between step that directs a 32-bit API call to the appropriate DLL. They did the same thing from 16 to 32. It makes sense because otherwise there could be no continuity between systems. Many popular software programs didn't have a 64-bit version until long after MS made the switch. But continuing 16-bit would have been irrelevant to almost everyone. | [On a separate but related matter: the email/news/etc. software I use - | Turnpike - requires the 32-bit shell, which is why I run 32-bit W7. (TP | - or part of it - runs as an Explorer extension.) According to the | Turnpike newsgroup (I didn't try myself), right up to the last | pre-release version of 7-64, it ran fine: when it ran, it invoked the | 32-bit shell Explorer extensions, or shell extensions, run in-process. A process has its own environment or context; its own memory space. If you start abc.exe that's a process. It's private. An in-process component would be something like a DLL that's loaded by a program. Memory is addressed as numerical offsets. Much of programming involves "pointers" to memory. Example: You want to add an s to apple. x = "apple" z = x & "s" x in that case is a pointer. It's actual value is a number that points to the offset or location of memory *in the process's context* where the actual bytes are stored for the word "apple" so that they can be accessed to calculate the value of z. In other words, the content of x is not "apple". It's something like 8,234,548. That's the place in RAM where the bytes for "apple" are going to be stored. So abc.exe has it's own process environment and Windows will handle whether it's 32 or 64 bit. But a shell extension is in Explorer's process. It must match bit-ness because things like pointers are 64-bit in Win64 and 32-bit in Win32. (Pointers and numeric datatypes are mainly what differs from 32 to 64.) The pointer x would either overflow 32-bit capacity or be misread. (Which is why 32-bit can only access about 4 GB of RAM. A 32-bit number can only count to about 4 billion, so there's no way to pass a pointer -- memory address -- at something like an offset of 5 billion.) You can run a 32-bit shell extension under 32-bit Explorer. If I remember correctly, Win64 at first defaulted to 32-bit Expolrer/IE for that reason: There were not yet any 64-bit ActiveX controls or browser extensions. Then later one had to specifically choose to use Explorer32. I don't know where it stands these days -- whether it's still possible to use Explorer32. But of course that would block you from using 64-bit shell extensions. Shell extensions include things like Explorer bars, property sheets (tabs on right-click - Properties), context menu handlers, drop handlers, BHOs, etc. While the link between Explorer and IE is no longer stressed, it's still there. So running 32-bit Explorer would also mean running 32-bit IE. I wrote an Explorer Bar at one point to replace XP's nearly useless version with more functionality. (It was customizable in Win98 and I missed that.) My bar is 32-bit. It runs fine on Win7-32. When a shell extension loads it tells Windows what it is and gets set up as needed. An Explorer Bar will get access to Explorer's ShellFolderView as well as to IE's browser window. That means that whether you start IE or open a folder, my Explorer Bar can access that process. For instance, it needs to know when you select a file in a folder window and what that file is. So it gets access of any such events happening in folder windows. That's the reason that shell extensions can't mix 32 and 64. They're running "in-process". (That's another reason you should never use IE online. Between shell extensions, BHOs and components like mime filters, there are just too many ways for 3rd-party software to hitch a ride. I have to actually deliberately block my Explorer Bar in order to prevent it loading in all IE windows and only showing up in Explorer windows. But the functionality is there. There's nothing stopping my bar from accessing webpages loaded in IE. And indeed, it's *supposed* to do that in order to provide functionality.) What Turnpike should do is to just stop the integration and write a normal EXE. There's no need to integrate with Explorer in most cases. The only really good reason is if something is augmenting Explorer's own functionality. They have no right to ask for the trust you have to give them to allow them sit in the drivers seat of IE. And there's no reason I can think of that they have to integrate with Explorer in order to provide news/email. That means your TP software is probably vulnerable to IE exploits. ..... Probably more than you wanted to know, but the whole topic of shell extensions has functionality and security implications that are worthwhile knowing about and it's information that's not easily accessible to the general public because it gets into a slightly nitty-gritty level of programming. |
Why is WOW not recursive (and 16, 8 bit)?
J. P. Gilliver (John) wrote:
(From reading the Wikipedia article, I understand WOW involves virtual machines (sandboxes), intercepts for system calls, dummy zero-size files, and so on, all so the old softwares can run happily.) Why does the 64-bit system not have WOW32 (that can run 16-bit software) - even if it has to itself run under WOW64? (Was there ever 8-bit software for x86 machines - if so, was/is there ever a "WOW16"? If so, same question.) Is there a technical reason, or is it just a meanness decision by Microsoft? [On a separate but related matter: the email/news/etc. software I use - Turnpike - requires the 32-bit shell, which is why I run 32-bit W7. (TP - or part of it - runs as an Explorer extension.) 32-bit programs run under Windowss x64 due to the WOW64 (Windows 32-bit On Windows 64-bit) emulation layer. According to the Turnpike newsgroup (I didn't try myself), right up to the last pre-release version of 7-64, it ran fine: when it ran, it invoked the 32-bit shell, which was included with 7-64. However, in the final release version of 7-64, some change had been introduced which stopped TP from functioning properly. TP is 32-bit software; I assume it's its Explorer integration that is the problem (I don't know enough about it to say more). Backwards compatibility is typical for a couple OS version. It is not for every version of the OS that ever existed. They provide the emulation layer for temporarily compatibility, like over the span of a decade. If you want to run 8- and 16-bit programs then you need to use an old OS version that supports that bitness. For one thing, emulation will slow down a program. Running emulation inside of emulation (chaining) would further slowdown a program. For another, when a company drops support for an older product, having to keep maintaining, securing, or repairing the old OS would definitely not have them dropping support for it. When support ends, they are obviously not going to continue supplying it in later versions where they would have to continue supporting it. Support ENDED! That they continue providing some backwards compatibility is them being nice, not being mean, along with ensuring survivability of their new OS version. We'd hoped the 7.1 release might fix it, but it didn't. I just mention it out of interest - that there is at least one 32-bit software that _won't_ run under 64.] There is no 7.1 version of Windows 7. Perhaps the real problem is Turnpike relies on the old scheme of allowing programs installed under the Program Files folder to store their data there. Windows 7 protects some folder against abuse like that. The Programs Files folder is for *programs*, not data storage, and never was. It was lazy programmers that didn't bother creating their own data folder separate of the program folder, and they got used to doing it that way (just like a lot of programmers would dump some of the program's files under \Windows\system32 rather than keep them it the program's own install folder). I use 40tude Dialog and its author made the same old assumptions about using the program's *program* folder to store its data files. Windows 7 protects the programs folder. For old programs that mixed program and data files together, you need to choose a different folder into which to install the program. For example, I installed Dialog into the \Programs\Dialog folder. I created a new folder called \Programs where old programs, like Dialog, would get installed and which Windows 7 doesn't protect. There are other reasons why I might not want a program installed under the protected "\Program Files" folder and instead install them under my unprotected "\Programs" folder. Protecting the "\Program Files" folders (2 of them under 64-bit Windows) is a security feature that was introduced in Windows Vista. You might circumvent the security feature by changing the security permissions on the folder to allow writes to non-elevated user account or groups, like changing ownership from the TrustedInstaller account to your own account or to the Administrators or other security group depending on who you want to allow to write there; however, there could be repercussions from changing permissions. Instead it is a lot easier to create your own folder, like \Programs, and install the old badly coded programs that mix program with data to store them under the unprotected folder. When you create that special folder, it will get the permissions of your Windows account. If you are in the Administrators security group then only other Windows accounts in the same security group can write to that folder. If your Windows account is in the Users security group then any Windows account can read and write in that folder you created. Permissions still come into play even when you create your own folders. |
Why is WOW not recursive (and 16, 8 bit)?
"VanguardLH" wrote \
| Perhaps the real problem is Turnpike relies on the old scheme of | allowing programs installed under the Program Files folder to store | their data there. Windows 7 protects some folder against abuse like | that. I'm afraid you're wandering off on a red herring issue there. https://en.wikipedia.org/wiki/Turnpike_%28software%29 It's just as John said. With v. 6 it became a shell extension. See my explanation above. A 32-bit shell extension can't run in Win64. The issue of program folders holding data is a relatively minor problem. You can install it elsewhere. You can change the permissions on the folder. Since the default is read-only, it only means that your software might malfunction in small ways or not save settings. It won't be prevented from running. Shell extension bitness is an entirely different issue with no workaround. Some people feel very strongly about no data in program folders, but it never was a problem. I actually like to save settings to a subfolder in the program folder. I do the same for temp files. At install I set both subfolders with no restrictions. That way Windows doesn't interfere and I don't have to worry about running into restrictions because I'm doing everything in my own folders. I leave the restrictions on the parent folder where the EXE and DLLs are. The only credible reason to restrict data from program folders (the possibility of malware altering the program executable is not a credible threat) is for corporate workers who move around between computers and only have a right to access their personal folders. Those people need to be able to have their personal settings on any machine they use. For the rest of us -- people who own their own computer -- there's really no reason not to use program folders. It keeps a program's files in one place rather than spreading them around to locations where no one can find them. In fact, with Windows Vista+ lackey user mode there actually isn't any approved way to set machine-wide settings. HKLM in the Registry and all users app data are both read-only. So anyone who writes software and wants to provide the option to save settings for all users has to circumvent Microsoft's corporate workstation design. A typical example of that would be a family, where everyone is a different user who picks their own desktop background, but Dad wants to configure MS Word, the video player, the image editor and the browser for the whole family. How does he do that? If they don't provide an option then he has to boot into each account and configure them all separately. Just because Microsoft says something is an official rule that doesn't mean you have to take their word for it without question. MS serves MS. |
Why is WOW not recursive (and 16, 8 bit)?
In message , Mayayana
writes: "J. P. Gilliver (John)" wrote | | Why does the 64-bit system not have WOW32 (that can run 16-bit software) | - even if it has to itself run under WOW64? (Was there ever 8-bit | software for x86 machines - if so, was/is there ever a "WOW16"? If so, | same question.) | | Is there a technical reason, or is it just a meanness decision by | Microsoft? | It's probably possible, but would be a lot of work. I'm not quite sure why the effort (of allowing WOW32 to run _through_ WOW64) would be that great ... And for what? So that a few people can play DOS .... but I genuinely don't know how much 16-bit software there is (more than just games, but I _think_ not a lot). [FWIW, last time I tried, "adventure" ran - and I think even DOOM did.] [] | [On a separate but related matter: the email/news/etc. software I use - | Turnpike - requires the 32-bit shell, which is why I run 32-bit W7. (TP | - or part of it - runs as an Explorer extension.) According to the | Turnpike newsgroup (I didn't try myself), right up to the last | pre-release version of 7-64, it ran fine: when it ran, it invoked the | 32-bit shell Explorer extensions, or shell extensions, run I _think_ "extension" was what it was described as. I "see" this: Desktop Libraries Homegroup Computer C: D: Network Control Panel Recycle Bin Turnpike mail folders news newsgroups [] You can run a 32-bit shell extension under 32-bit Explorer. If I remember correctly, Win64 at first defaulted to 32-bit Expolrer/IE for that reason: There were not yet any 64-bit ActiveX controls or browser extensions. Then later one had to specifically choose to use Explorer32. I don't know where it stands these days -- whether it's still possible to use Explorer32. But of course that would block you from using 64-bit shell extensions. That might explain why Turnpike worked under all but the final release of W7-64. [] What Turnpike should do is to just stop the integration and write a normal EXE. There's no need to integrate with Explorer in most cases. The only really good reason is if something is augmenting Explorer's own functionality. They have no right to ask for the trust you have to give them to allow them sit in the drivers seat of IE. And there's no reason I can think of that they have to integrate with Explorer in order to provide news/email. That means your TP software is probably vulnerable to IE exploits. They're not asking anything; Turnpike stopped any development in 2007 (-:! [] -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf "quidquid latine dictum sit, altum viditur". ("Anything is more impressive if you say it in Latin") |
Why is WOW not recursive (and 16, 8 bit)?
In message , VanguardLH
writes: J. P. Gilliver (John) wrote: (From reading the Wikipedia article, I understand WOW involves virtual machines (sandboxes), intercepts for system calls, dummy zero-size files, and so on, all so the old softwares can run happily.) Why does the 64-bit system not have WOW32 (that can run 16-bit software) - even if it has to itself run under WOW64? (Was there ever 8-bit software for x86 machines - if so, was/is there ever a "WOW16"? If so, same question.) Is there a technical reason, or is it just a meanness decision by Microsoft? [On a separate but related matter: the email/news/etc. software I use - Turnpike - requires the 32-bit shell, which is why I run 32-bit W7. (TP - or part of it - runs as an Explorer extension.) 32-bit programs run under Windowss x64 due to the WOW64 (Windows 32-bit On Windows 64-bit) emulation layer. So why can't 16-bit prog.s run in WOW32 running in WOW64. (Don't try to answer that - Mayayana has tried, and my brain hurts [not that that means there's anything wrong with his explanation!].) The Turnpike matter is separate. [] For one thing, emulation will slow down a program. Running emulation inside of emulation (chaining) would further slowdown a program. For But on the whole, hardware developments - initially processor clock speeds, and now multiple cores - often mean that even nested emulations run as fast or faster than the original software and hardware. [] We'd hoped the 7.1 release might fix it, but it didn't. I just mention it out of interest - that there is at least one 32-bit software that _won't_ run under 64.] There is no 7.1 version of Windows 7. Sorry, I meant SP1. Perhaps the real problem is Turnpike relies on the old scheme of allowing programs installed under the Program Files folder to store their data there. Windows 7 protects some folder against abuse like No, it isn't that. TP runs under Vista and later (32 bit only though) if you run a couple of ICACLS commands at a fairly early stage of install. (And those are included in the help file.) [] As one of you pointed out in a later post, Turnpike became an explorer extension (?) at the transition from v5 to v6; many of us thought this was a bad idea at the time, and of course have been proved right, but most went with it for other improvements. Some stuck with v5; some, still using that, have rather smugly told us that it's fine under 64-bit W7 (and 10). -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf Sometimes you win, sometimes you learn. |
Why is WOW not recursive (and 16, 8 bit)?
J. P. Gilliver (John) wrote:
I can't see why they can't be sandboxed/emulated/whatever, Sure they can. Get a VMM (virtual machine manager), like VMWare Player or VirtualBox, and install your OS bitwidth of choice in a VM where you run old programs that require that particular OS. A vendor isn't going to continue supporting a product that they discontinued. YOU become the support team thereafter. It's up to you to find a solution. Looks like your solutions are, so far: Run Windows 32-bit in a VM where you use Turnpike 6 or use the older Turnpike 5 on Windows 64-bit. Yep, making TP 6 rely on shell extension functionality for it to work was a bad move, as for those programs that operate as HTAs (HTML Applications) that rely on the IE libraries. |
Why is WOW not recursive (and 16, 8 bit)?
VanguardLH wrote:
J. P. Gilliver (John) wrote: I can't see why they can't be sandboxed/emulated/whatever, Sure they can. Get a VMM (virtual machine manager), like VMWare Player or VirtualBox, and install your OS bitwidth of choice in a VM where you run old programs that require that particular OS. A vendor isn't going to continue supporting a product that they discontinued. YOU become the support team thereafter. It's up to you to find a solution. Looks like your solutions are, so far: Run Windows 32-bit in a VM where you use Turnpike 6 or use the older Turnpike 5 on Windows 64-bit. Yep, making TP 6 rely on shell extension functionality for it to work was a bad move, as for those programs that operate as HTAs (HTML Applications) that rely on the IE libraries. https://www.morovia.com/kb/Howto-Lau...ows-10610.html That's another program that uses a shell extension but the author only provides a 32-bit dll. I don't know if the trick works to load a 32-bit version of Windows Explorer. When you look in Task Manager's Processes tab, a process name is followed by "*32" to indicate it is a 32-bit process. I didn't see that when I used the article's trick. I also used SysInternals' Process Explorer: right-click on a process, select Properties, and check the value of PROCESSOR_ARCHITECTURE (x86 for 32-bit, AMD64 for 64-bit). Nope, that instance of explorer.exe was still 32-bit. "64-bit Windows" doesn't say which version of Windows. Windows XP had a 64-bit version. It was Windows 2003 Server x64 crippled down to the features of a workstation version of Windows with the Windows XP GUI slapped atop. That it was really a server version is why some programs would not run on Windows XP x64. Could be the article was written for getting that program to work under Windows Vista x64. I tested using Windows 7 Home SP-1 x64. |
Why is WOW not recursive (and 16, 8 bit)?
In message , VanguardLH
writes: J. P. Gilliver (John) wrote: I can't see why they can't be sandboxed/emulated/whatever, Sure they can. Get a VMM (virtual machine manager), like VMWare Player or VirtualBox, and install your OS bitwidth of choice in a VM where you run old programs that require that particular OS. I got the impression that the WOWs were, in effect, something like a VMM - not exactly do, hence my "whatever". A vendor isn't going to continue supporting a product that they discontinued. YOU become the support team thereafter. It's up to you to find a solution. True. I thought the WOWs were tools I/users could use towards that end. Looks like your solutions are, so far: Run Windows 32-bit in a VM where you use Turnpike 6 or use the older Turnpike 5 on Windows 64-bit. I was asking the question out of more general interest; I only mentioned Turnpike specifically in passing, as an example of even a 32-bit software that doesn't run under 64-bit Windows (for reasons different to most). (I'm actually running it in a real - not virtual - 32-bit machine; this 32-bit W7 SP1 is more than adequate for my needs. [It has well under 4G of RAM - 3, I think. I don't think 64-bit W7 would give me any benefit.]) Yep, making TP 6 rely on shell extension functionality for it to work was a bad move, as for those programs that operate as HTAs (HTML Applications) that rely on the IE libraries. Indeed. -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf Sometimes you win, sometimes you learn. |
Why is WOW not recursive (and 16, 8 bit)?
"pjp" wrote
| Delphi 7 wouldn't run until I gave it permission in the Program Files | folder where it was installed. It wanted to overwrite some config file | of some sort and would exit when it couldn't. Once it had permission for | the folder( & subfolders) it had no problem. Makes me wonder why | everywhere online people stated it wouldn't run under Win7 when it was | so easy a fix? It didn't tell you why it was having trouble? If it just quits then it's not surprising that it would seem to be broken on Win7. It's surprising how much software is poorly designed that way. There was a similar kind of problem with Visual Studio 6. There wasn't a permission issue, as far as I know, but on Win7 it looks for a system file called msjava.dll. I think it was part of Microsoft's Java, back when VS had Visual J++. The install works fine if a dummy file named msjava.dll is put into the system folder, but the installer never informs that's what it's looking for. It just quits! |
Why is WOW not recursive (and 16, 8 bit)?
Mayayana wrote:
"pjp" wrote | Delphi 7 wouldn't run until I gave it permission in the Program Files | folder where it was installed. It wanted to overwrite some config file | of some sort and would exit when it couldn't. Once it had permission for | the folder( & subfolders) it had no problem. Makes me wonder why | everywhere online people stated it wouldn't run under Win7 when it was | so easy a fix? It didn't tell you why it was having trouble? If it just quits then it's not surprising that it would seem to be broken on Win7. It's surprising how much software is poorly designed that way. There was a similar kind of problem with Visual Studio 6. There wasn't a permission issue, as far as I know, but on Win7 it looks for a system file called msjava.dll. I think it was part of Microsoft's Java, back when VS had Visual J++. The install works fine if a dummy file named msjava.dll is put into the system folder, but the installer never informs that's what it's looking for. It just quits! Msjava.dll constantly shows up in my copy of DependencyWalker as missing. It's the poster boy for "missing". You'd think there was a milk carton with Msjava.dll on the side. Microsoft had to remove their flavor of java from the WinXP installer, which created something called SP1a. There was a court case. And with no Java to flog, that's why we have ..NET today. Paul |
Why is WOW not recursive (and 16, 8 bit)?
J. P. Gilliver (John) wrote:
I got the impression that the WOWs were, in effect, something like a VMM - not exactly do, hence my "whatever". VMs virtualize all the hardware except the CPU. 32-bit processes using the WOW64 emulation layer have can get at all the hardware. They run just like 64-bit processes regarding hardware access. There is no isolation with WOW. I was asking the question out of more general interest; I only mentioned Turnpike specifically in passing, as an example of even a 32-bit software that doesn't run under 64-bit Windows (for reasons different to most). I've used VMs in the past to run old programs on old versions of Windows. Some users, especially small companies, have vertical market software (they bought or contracted to get built) that is critical to their business operations, they would have to contract someone to recode to a new OS but that's expensive, so they use a VM with and old OS where the old software will run. Some users run Linux in the guest OS (VM), so they can run Linux programs along with Windows programs. Some people use VMs for testing unknown or untrusted software, like something they just downloaded, to see if it behaves rudely or maliciously. VirtualBox can run software inside a VM but pretty much mask that is happening, so the user thinks they are running VM'ed programs in a guest OS just like the other programs that are running in the host OS. I've done that with some family that had ancient greeting card software, wanted to keep using it, but just had to get a later version of Windows (sometimes with valid reason because other software they wanted to use wouldn't run on the ancient OS version). |
Why is WOW not recursive (and 16, 8 bit)?
On 08/11/2018 03:17 PM, VanguardLH wrote:
J. P. Gilliver (John) wrote: [snp] There is no 7.1 version of Windows 7. There isn't, but I'd expect that to mean SP1. [snip] -- Mark Lloyd http://notstupid.us/ "[Belief in] the supernatural was the recourse of an insufficuent imagination, a derelection of duty, a childish evasion of the difficulty and wonders of the real." |
Why is WOW not recursive (and 16, 8 bit)?
On 08/11/2018 05:07 PM, J. P. Gilliver (John) wrote:
[snip] I can't see why they can't be sandboxed/emulated/whatever, so each runs in its own block of memory. Using two layers of -/-/- if necessary. Wherever the "handles" have different bit lengths, if WOW32 and WOW64 can handle the differences for one level of change, then surely together they should be able to handle both. You could always run a virtual machine with 16 or 32 bit Windows. -- Mark Lloyd http://notstupid.us/ "[Belief in] the supernatural was the recourse of an insufficuent imagination, a derelection of duty, a childish evasion of the difficulty and wonders of the real." |
All times are GMT +1. The time now is 01:10 PM. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © 2004 - 2006 PCbanter
Comments are property of their posters