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)

"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.

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.

"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.

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
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")

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.

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.

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.

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.

In article , am says...

"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

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?

"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!

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

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).

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."

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."