Well I can’t determine if it’s fact or not, but there’s a lot of internet discussion that apparently say even Quake 3 Arena doesn’t make use of SSE just MMX. So the only effect you might be testing is video driver level support.

Even if the cpuid instruction returns support for SSE, attempting to actually use SSE instructions may trigger a #UD fault if the OS hasn't configured the CPU for SSE usage i.e. set CR4.OSFXSR. The programs in question might be detecting this and falling back to MMX or lower.

The theory that SSE would be usable for only one program is incorrect; it wouldn't be usable for any program as the OS wouldn't know how to enable SSE in the first place.

alvaro84 wrote:

It must be the way it was designed, right to prevent unaware OSes from messing things up while switching between SSE optimized programs without saving the extra registers.

This is exactly right, even the FPU/MMX had to be explicitly enabled in configuration registers to make it usable.

jmarsh wrote:

The theory that SSE would be usable for only one program is incorrect;

It is not.
I think you are confusing two things here:
1) Enabling/disabling SSE at CPU-level.
2) Handling support of SSE in the OS and application levels.

Assuming 1) is enabled, and 2) is false, then only one program will be able to use it at a time.
As for 1), it could be possible that (some builds of) Windows 95 accidentally had SSE enabled, because the bit in that register had no meaning up to that point.
It is also possible for an application to use a ring0 hack in Windows 95, to modify the CR4 register and enable SSE.

jmarsh wrote:

This is exactly right, even the FPU/MMX had to be explicitly enabled in configuration registers to make it usable.

There is nothing explicit for MMX/3DNow! support though, so as long as an OS supports x87, they are automatically forward-compatible with MMX/3DNow! as well.

Scali wrote:

As for 1), it could be possible that (some builds of) Windows 95 accidentally had SSE enabled, because the bit in that register had no meaning up to that point.

"Could" be possible, but the reality is it simply never happened.
Configuration register bits that are undefined are routinely declared as "must be zero" and trying to set them often causes a fault, precisely to safeguard forward compatibility.

It is also possible for an application to use a ring0 hack in Windows 95, to modify the CR4 register and enable SSE.

Hardly a scenario worth caring about; if someone digs their own hole they get to sit in it.

There is nothing explicit for MMX/3DNow! support though, so as long as an OS supports x87, they are automatically forward-compatible with MMX/3DNow! as well.

I said FPU/MMX state - neither are usable unless co-processor emulation is turned off.

jmarsh wrote:

"Could" be possible, but the reality is it simply never happened.

It didn't? Did you research this?

jmarsh wrote:

Configuration register bits that are undefined are routinely declared as "must be zero" and trying to set them often causes a fault, precisely to safeguard forward compatibility.

Did you research whether or not it does in this specific case?
Because I can think of various examples where undefined bits can be set to 1 without causing a fault. In fact, that is how Intel recommends to detect CPUs that predate the CPUID instruction.

jmarsh wrote:

Hardly a scenario worth caring about;

Is it? Did you research it?
My experience with Win95 software is that quite a lot of it didn't work at all on any NT-based Windows, and sometimes not even on later Win9x versions, because of all the low-level hacks that were used.
You have to understand that especially with games, people came from a culture of DOS, home computers and consoles, where you would own the entire system, and (ab)use the hardware to your heart's delight, to extract the maximum performance out of it.

I said FPU/MMX state - neither are usable unless co-processor emulation is turned off.

What's your point?

Scali wrote:

What's your point?

To prevent misinformation. SSE is not usable on win95 regardless of whether multiple or single program(s) attempt to use it.

jmarsh wrote:

To prevent misinformation. SSE is not usable on win95 regardless of whether multiple or single program(s) attempt to use it.

Firstly, we disagree on that point, as my previous posts have already made clear: it is possible for a program to use a ring0-hack to enable SSE by manipulating CR4 (assuming it was not enabled already). Once that is done, SSE will work, but context will not be preserved between task switches, so it will work as long as only one task uses SSE.
Secondly, I was referring specifically to the remark I quoted.

Maybe jmarsh is speaking from a "practical" perspective - like "No programs/games/drivers (to date) use SSE under Win95" rather than "it's theoretically possible and could happen in the future".

I was googling this topic and noticed Falconsoft makes a dos utility (falcosoft.hu/sse.zip) that enabled the SSE(2,3) instruction sets under DOS, Win3.1, or Win95. Interesting.

BinaryDemon wrote:

Maybe jmarsh is speaking from a "practical" perspective - like "No programs/games/drivers (to date) use SSE under Win95" rather than "it's theoretically possible and could happen in the future".

In that case he is phrasing it very poorly: "regardless of whether multiple or single program(s) attempt to use it."
If a program attempts to use it in the right way, it is usable.

BinaryDemon wrote:

I was googling this topic and noticed Falconsoft makes a dos utility (falcosoft.hu/sse.zip) that enabled the SSE(2,3) instruction sets under DOS, Win3.1, or Win95. Interesting.

My point exactly.
I disassembled the code, and it looks like this:

1mov     eax, cr4
2or      eax, 200h
3mov     cr4, eax
4xor     eax, eax
5mov     ax, 4C00h
6int     21h

So it basically just toggles the bit in CR4, as mentioned, it's that simple. I'd be surprised if Falcosoft is the only one who ever used this.

Using a kernel exploit to fiddle with control registers is not "the right way."
Why not say win95 supports AVX-512? All you have to do is hack the OS to actually allow it.

it's that simple. I'd be surprised if Falcosoft is the only one who ever used this.

Except if the CPU is already in protected mode (thanks to EMM386 or such), it'll just crash.

jmarsh wrote:

Using a kernel exploit to fiddle with control registers is not "the right way."

Now you are moving the goalposts. You never said "the right way" before, nor did I.
You were arguing that it was categorically impossible, which it isn't.
Also, it's just a DOS .com file, so I wonder how that works... Perhaps the DOS prompt just runs under enough privileges that you can globablly modify CR4 this way? Then you wouldn't even need a ring0 hack at all. Just execute the .com file from a Win32 process, and Bob's yer uncle.
Heck, perhaps CR4 isn't even protected from Win32 processes in Win95 anyway.

jmarsh wrote:

Why not say win95 supports AVX-512? All you have to do is hack the OS to actually allow it.

Nobody said Win95 *supports* SSE.
What I said was this:

Scali wrote:

SSE is a different story, it has its own registers. The OS needs to specifically save and restore them at every context switch, else you will get problems when more than one program tries to use SSE at the same time.
Windows 95 does not support SSE.

Scali wrote:

Now you are moving the goalposts. You never said "the right way" before, nor did I.
You were arguing that it was categorically impossible, which it isn't.

I said it was incorrect to say it would work with only one program. Under regular Win95 (i.e. no hacky patching or whatever) it will not work at all.

jmarsh wrote:

I said it was incorrect to say it would work with only one program. Under regular Win95 (i.e. no hacky patching or whatever) it will not work at all.

But then I explained that it is possible to enable the flag in CR4, after which the 'one program' scenario takes effect. And then you still denied it flatout:

jmarsh wrote:

To prevent misinformation. SSE is not usable on win95 regardless of whether multiple or single program(s) attempt to use it.

You're the one spreading misinformation here:
It is possible to use SSE in Windows 95, under certain circumstances, and some people have actually done this in the past (I know the 'one program' rule from back in the late 90s when Win95 and SSE were a real issue).

Give me a win95 program that uses SSE then.

jmarsh wrote:

Give me a win95 program that uses SSE then.

I can make a proof-of-concept for you sometime. But right now I'm too busy with other projects.
Perhaps you can ask Falcosoft, as he has this tool on his website. He's probably used it.

Scali wrote:

Perhaps you can ask Falcosoft, as he has this tool on his website. He's probably used it.

Falcosoft website wrote:

Warning!

Don't use this program when EMM386 is loaded!

With a warning like that do you really think it works when run inside windows? (Hint: it doesn't.)

jmarsh wrote:

With a warning like that do you really think it works when run inside windows? (Hint: it doesn't.)

You tried?

Scali wrote:

You tried?

I said it doesn't work, didn't I? The mov instructions to/from CR4 have no effect, likely because they fault and the kernel skips over them to keep dodgy software happy.

jmarsh wrote:

With a warning like that do you really think it works when run inside windows? (Hint: it doesn't.)

It won't. But it will run from autoexec.bat if emm386.exe isn't loaded in config.sys. Then you can have it under the GUI too.

jmarsh wrote:

I said it doesn't work, didn't I?

That can be an assumption.