Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Lars

Pages: [1] 2 3 ... 69
General Discussion / Re: SCOUG
« on: Today at 11:34:47 am »
Try to sacrifice a black cat at midnight, maybe that helps.
Just kidding, I don't want an innocent black cat do die...

Being an OS/2 user is a little bit like being a drug addict:
you know that it's bad for your health but you just can't let go.

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 03, 2022, 10:32:26 am »
You can. Until you end up with a system where you can no longer remove directories where directory names were manipulated without UNICODE.SYS being loaded. That messes up the unicode character string on a very basic filesystem level. And then, DFSee is your last resort to rectify that.

If you always use en_US locale, you will very likely NEVER run into this problem, because codepage 437 is the default for about anything that relates to an ASCII string in OS/2. This is about people that either have to use a different codepage or where the OS installation installs a different codepage as the primary codepage. For a german OS/2, codepage 850 is installed as the default (with 437 as a secondary codepage) even though codepage 437 would also do for most of the things (german umlauts are also supported with codepage 437 and even have the same byte value as in codepage 850).
In short, for a few special characters, codepage 437 and 850 are identical. For the lower 128 characters, 437 and 850 are also identical (and that includes 0-9 a-z A-Z : \ .).
For a french codepage this will be comparable but certainly not for any cyrillic codepage.
Which also makes it clear why no modern operating system is using codepages anymore.

I repeat: this is an absolute NOGO for a commercial operating system.

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 02, 2022, 03:48:55 pm »
If that attach fails you know that UNICODE.SYS is not loaded, display a warning message and even force the user to hit Return to continue boot process.


I agree that it should be very useful for JFS.IFS to display a warning message if UNICODE.SYS is not loaded. For what I know UNICODE is very important for JFS. But I'm not complete sure about if had to pause the boot process forcing the user to hit "return".

But I think I can open the ticket and let the implementation decisions to Arca Noae, since it is their product.

By the way, as far as it was discussed AN JFS.IFS is closed source and they treat the IBM source code base of it as the IBM DDK license.


Waiting for a keypress was a suggestion. You could also do a simple delay of say 30 seconds or so (that would also be possible).

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 02, 2022, 03:44:46 pm »
There are device drivers that do not continue silently in case of error (I think MAC drivers often expect user confirmation to continue). So this is a general shortcoming and can hit you on all sorts of other occasions.
Yes it is a problem with other drivers too. That's why I'm think about. Specifically with ethernet drivers I often observed this when f.i. they do not find the correct chip. But other drivers too. I think PAUSEONERROR (or similar) can prevent stop the boot process. But using this is no good solution too because you probably wouldn't recognize the error message then as it flies away much to fast on current (< 10 years :-) ) hardware.

Does your system no longer have "legacy USB" support ? I can use the USB keyboard before OS/2 takes over the USB host
controllers ...
It does as long as something (ACPI, USB, ...?) very early in the boot process takes over control until the time when all the USB stuff, including usbhid is initialized (very late). In any case there is a big window during boot where USB keyboards do not work. From all what I understand and all the discussions about that (testers list, AN tickets) this window (non working usb keyboard) can not be eliminated. I never figured out how to sort config.sys to make this window as small a possible. But I got the impression it's impossible to cover all these places where device drivers may fire up this "hit return" message. We have to life with this when we want (or have) to use USB keyboards instead PS/2.

1) it's not PAUSEONERROR that influences the driver behaviour. It is what error code a driver returns from its INIT routine. It can report either "OK" or "NON_CRITICAL_ERROR" or "SOME_ERROR" (various different errors). "OK" and "NON_CRITICAL_ERROR" means to continue without interruption, "SOME_ERROR" means to stop and wait for keypress.
Obviously, the idea is that a severe error should prevent booting from continuing without the user noticing.

2) I don' t have a long time window of USB not working. I have a short time window of USB not working where the OS/2 HC drivers are loading and turning off legacy USB (start of time window) and finally have taken over the HC HW and the relevant USB devices mouse/keyboard have been enumerated (end of time window). On my system, that time window is about 5 seconds, keyboard works before and after that time window (that is, in particular during the bootup process where the video is in text mode). But I am using my USB drivers and I don't know if the AN drivers have a different behaviour.

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 02, 2022, 12:11:39 pm »
It may have a sense to convert UNICODE.SYS from "DEVICE" to "BASEDEV".

That is only going to remove the ordering dependency (UNICODE.SYS has to come before JFS.IFS). I can live with that ordering dependency but I cannot live with data loss because a vital driver wasn't loaded.

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 02, 2022, 12:10:00 pm »
I wouldn't call it ridiculous. I would say this is another shortcoming/bug/problem/nuisance of one part/program of our platform. Of course it may be easy to improve this situation with Lars proposed changes. No clue if David will implement it when Lars creates a ticket.

It's good that Lars shares his experience here to tell others about some problems and how to circumvent it. That's what a forum is good for.

But I also see a lot of other shortcomings. And when I were in the position to give priorities, this one would have a low priority. We only can wait and see what David says about this. Or is there any chance to get access to the latest JFS sources?

display a warning message and even force the user to hit Return to continue boot process
I fear this can be a problem with USB keyboards. The systems I have do not serve USB keyboards (with OS/2) until the end of the boot process. Every such "hit return to continue" condition while booting (while loading all the drivers from config.sys) needs the old PS/2 keyboard which luckily is also attached to step over. Here there is no chance to respond to such messages with the USB keyboard.

There are device drivers that do not continue silently in case of error (I think MAC drivers often expect user confirmation to continue). So this is a general shortcoming and can hit you on all sorts of other occasions.
Does your system no longer have "legacy USB" support ? I can use the USB keyboard before OS/2 takes over the USB host
controllers ...

By the way: I cannot create a ticket as I am no paying AN customer. Somebody with an AN license would need to do that.

Hardware / Re: panorama not remembering monotor resolution
« on: December 02, 2022, 08:18:15 am »
I have a very annoying problem.  If I boot the computer without the monitor being on panorama reverts to something like 640 x 480 which is stupid on my 1920 x 1200 28 inch monitor. 
Is there a way to make panorama remember the monitor resolution?  I have no problems like this with Linux on the same monitor via a kvm switch.

Same happens for me. I doubt that there is an easy way to circumvent that.

Multimedia / Re: Rebuilds of MM Audio Pack
« on: December 02, 2022, 07:26:19 am »
That is already supported with installing USBAUDIO package. It adds the necessary SPI info so that MMPM can understand this new Samplerate/numchannels/bit depth format.

Here is a list of what formats have been added by now:

Code: [Select]
/* additional Subtypes for DATATYPE_WAVEFORM:*/
#define    WAVE_FORMAT_32M16        0x0011L   /*  32.0kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_48M16        0x0012L   /*  48.0kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_64M16        0x0013L   /*  64.0kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_882M16       0x0014L   /*  88.2kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_96M16        0x0015L   /*  96.0kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_1764M16      0x0016L   /* 176.4kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_192M16       0x0017L   /* 192.0kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_3528M16      0x0018L   /* 352.8kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_384M16       0x0019L   /* 384.0kHz  , Mono, 16-bit*/

#define    WAVE_FORMAT_32S16        0x001AL   /*  32.0kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_48S16        0x001BL   /*  48.0kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_64S16        0x001CL   /*  64.0kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_882S16       0x001DL   /*  88.2kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_96S16        0x001EL   /*  96.0kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_1764S16      0x001FL   /* 176.4kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_192S16       0x0020L   /* 192.0kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_3528S16      0x0021L   /* 352.8kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_384S16       0x0022L   /* 384.0kHz  , Stereo, 16-bit*/

#define    WAVE_FORMAT_32M24        0x0023L   /*  32.0kHz  , Mono, 24-bit*/
#define    WAVE_FORMAT_4M24         0x0024L   /*  44.1kHz  , Mono, 24-bit*/
#define    WAVE_FORMAT_48M24        0x0025L   /*  48.0kHz  , Mono, 24-bit*/
#define    WAVE_FORMAT_64M24        0x0026L   /*  64.0kHz  , Mono, 24-bit*/
#define    WAVE_FORMAT_882M24       0x0027L   /*  88.2kHz  , Mono, 24-bit*/
#define    WAVE_FORMAT_96M24        0x0028L   /*  96.0kHz  , Mono, 24-bit*/
#define    WAVE_FORMAT_1764M24      0x0029L   /* 176.4kHz  , Mono, 24-bit*/
#define    WAVE_FORMAT_192M24       0x002AL   /* 192.0kHz  , Mono, 24-bit*/
#define    WAVE_FORMAT_3528M24      0x002BL   /* 352.8kHz  , Mono, 24-bit*/
#define    WAVE_FORMAT_384M24       0x002CL   /* 384.0kHz  , Mono, 24-bit*/

#define    WAVE_FORMAT_32S24        0x002DL   /*  32.0kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_4S24         0x002EL   /*  44.1kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_48S24        0x002FL   /*  48.0kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_64S24        0x0030L   /*  64.0kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_882S24       0x0031L   /*  88.2kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_96S24        0x0032L   /*  96.0kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_1764S24      0x0033L   /* 176.4kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_192S24       0x0034L   /* 192.0kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_3528S24      0x0035L   /* 352.8kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_384S24       0x0036L   /* 384.0kHz  , Stereo, 24-bit*/

#define    WAVE_FORMAT_32M32        0x0037L   /*  32.0kHz  , Mono, 32-bit*/
#define    WAVE_FORMAT_4M32         0x0038L   /*  44.1kHz  , Mono, 32-bit*/
#define    WAVE_FORMAT_48M32        0x0039L   /*  48.0kHz  , Mono, 32-bit*/
#define    WAVE_FORMAT_64M32        0x003AL   /*  64.0kHz  , Mono, 32-bit*/
#define    WAVE_FORMAT_882M32       0x003BL   /*  88.2kHz  , Mono, 32-bit*/
#define    WAVE_FORMAT_96M32        0x003CL   /*  96.0kHz  , Mono, 32-bit*/
#define    WAVE_FORMAT_1764M32      0x003DL   /* 176.4kHz  , Mono, 32-bit*/
#define    WAVE_FORMAT_192M32       0x003EL   /* 192.0kHz  , Mono, 32-bit*/
#define    WAVE_FORMAT_3528M32      0x003FL   /* 352.8kHz  , Mono, 32-bit*/
#define    WAVE_FORMAT_384M32       0x0040L   /* 384.0kHz  , Mono, 32-bit*/

#define    WAVE_FORMAT_32S32        0x0041L   /*  32.0kHz  , Stereo, 32-bit*/
#define    WAVE_FORMAT_4S32         0x0042L   /*  44.1kHz  , Stereo, 32-bit*/
#define    WAVE_FORMAT_48S32        0x0043L   /*  48.0kHz  , Stereo, 32-bit*/
#define    WAVE_FORMAT_64S32        0x0044L   /*  64.0kHz  , Stereo, 32-bit*/
#define    WAVE_FORMAT_882S32       0x0045L   /*  88.2kHz  , Stereo, 32-bit*/
#define    WAVE_FORMAT_96S32        0x0046L   /*  96.0kHz  , Stereo, 32-bit*/
#define    WAVE_FORMAT_1764S32      0x0047L   /* 176.4kHz  , Stereo, 32-bit*/
#define    WAVE_FORMAT_192S32       0x0048L   /* 192.0kHz  , Stereo, 32-bit*/
#define    WAVE_FORMAT_3528S32      0x0049L   /* 352.8kHz  , Stereo, 32-bit*/
#define    WAVE_FORMAT_384S32       0x004AL   /* 384.0kHz  , Stereo, 32-bit*/

#define    WAVE_FORMAT_12M16        0x004BL   /*  12.0kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_16M16        0x004CL   /*  16.0kHz  , Mono, 16-bit*/
#define    WAVE_FORMAT_24M16        0x004DL   /*  24.0kHz  , Mono, 16-bit*/

#define    WAVE_FORMAT_12S16        0x004EL   /*  12.0kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_16S16        0x004FL   /*  16.0kHz  , Stereo, 16-bit*/
#define    WAVE_FORMAT_24S16        0x0050L   /*  24.0kHz  , Stereo, 16-bit*/

#define    WAVE_FORMAT_8M24         0x0051L   /*   8.0kHz  , Mono,   24-bit*/
#define    WAVE_FORMAT_8S24         0x0052L   /*   8.0kHz  , Stereo, 24-bit*/
#define    WAVE_FORMAT_8M32         0x0053L   /*   8.0kHz  , Mono,   32-bit*/
#define    WAVE_FORMAT_8S32         0x0054L   /*   8.0kHz  , Stereo, 32-bit*/

Additionally, of course, the sound driver has to understand the format. For the USB audio drivers, Wim implemented a (lengthy) routine to convert sample rate/num channels/bit depth to the closest match of what the USB audio HW supports. Works perfectly.
As far as I can tell UNIAUD typically supports 8000 Hz, 11025 Hz, 22050 Hz, 44100 Hz, 48000 Hz (cannot remember what bit depths are typically supported). The support depends on the actual audio HW as UNIAUD is a generic driver covering all sorts of different audio HW.

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 02, 2022, 07:10:45 am »
Sorry, but this is ridiculous.
If JFS.IFS can easily fail in a catastrophic way, then it is necessary to prevent that or at least to mediate the risk.
A new user would have no clue of what is going on. But maybe everyone has already accepted that there will be no new users...

Anyway, after thinking about it a bit more:
JFS.IFS can attempt to attach to UNICODE.SYS via a dehelp call and that can already be done on FS_INIT (call for initializing JFS.IFS) which is executed already on bootup.
If that attach fails you know that UNICODE.SYS is not loaded, display a warning message and even force the user to hit Return to continue boot process.
That takes around 10 lines of code in JFS.IFS.
But I am not the master of disaster. That is AN. They have the source code. And of course, it's closed source

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 01, 2022, 04:29:15 pm »

I quickly installed "" with Warpin 1.0.24 (ArcaOS 5.0.6) and I confirm it removed UNICODE.SYS from my config.sys.

Reverted everything, upgraded to WarpIn 1.0.26 and I got the same thing. UNICODE.SYS gets removed.

I also don't see anything strange on the CPUTEMP WarpIn script, just the "CONFIGSYS="DEVICE=?:\OS2\rdmsr.sys | UNIQUE" which should not remove UNICODE.SYS.

Should it be reported as WarpIn bug?


Warpin is working as it should based on discussion on the testers list. What happens is if rdmsr.sys is not installed, it matches up with the first *.sys in config.sys and replaces that with rdmsr.sys. Usually it is unicode.sys at the top of config.sys.

That is a very unfortunate side effect of specifying UNIQUE when "DEVICE" is the key string to look for because "DEVICE" will typically occur multiple times in config.sys. WarpIn should better be changed to do nothing if UNIQUE is specified and the key string is found multiple times. That is at least safe behaviour.
And if UNIQUE(xxxx) is specified, it should be changed to create the target string if no matching source string statement is found.

Storage / Re: JFS failing in a disastrous way - without the user knowing
« on: December 01, 2022, 04:22:45 pm »
Thanks for the feedback.

The second thing.
Will it makes sense to request Arca Noae to put a "Boot Warning Text" for JFS.IFS if it does not find UNICODE.SYS loaded ? Does it makes sense? Can it be possible in boot time to detect this for JFS.IFS?


Yes, that would definitely make sense.

I would need to check the OpenJFS source code, but I would think that JFS.IFS uses the KEE API calls "KernCreateUConvObject", "KernStrToUCS" and "KernStrFromUCS" to create a UConv object, convert from an ASCII string to a Unicode string (taking into account active system codepage), convert from a Unicode string to an ASCII string, respectively.

I would suspect that "KernCreateUConvObject" is called very early, in the IFS loading/initialization stage (but not already on FS_INIT as that executes in Ring 3 whereas calling "KernCreateUConvObject" requires executing in Ring 0). The call will definitely return with an error if UNICODE.SYS is not loaded (these KEE API calls are the ones that require UNICODE.SYS to be loaded !!!) and that would be the indirect way to find out.

If it is not possible to already display a message on boot, then there are options:
1) have a daemon executing that could show a warning message. But that requires to implement a daemon interface in JFS.IFS and also to start the daemon application itself which of course can also go wrong.
2) Another, potentially better option is to write to the system log (the syslog.exe thing that nobody ever uses ...) because that would be a persistent logging (logging happens to a file) but that in turn also requires an additional device driver and daemon (log.sys and logdaem.exe) when the logging is to be done from a device driver or IFS. I also do not know if that conflicts with the role of the IFS giving access to files (if log.sys buffers to memory and logdaem.exe writing much later in the process, then that could work). In that case, AN should ensure that LOG.SYS and LOGAEM.EXE are always added to config.sys on each install.
3) last but not least to use the low level file system device driver calls to write a file in the root directory (say with fixed string: "Attention: UNICODE.SYS NOT LOADED !"). I guess that is the best option as it requires no further components to be up and running. But I seem to remember that also requires ring 0 execution which again would mean, you'd need to delay the logging until the first IFS call executing in Ring0 and also after the filesystem has been mounted (obviously).

But the problem should be solvable.

Storage / JFS failing in a disastrous way - without the user knowing
« on: November 30, 2022, 01:01:18 pm »

I thought, I'd share this info with everybody.

Initial info:
0) as a standard case that is likely true for 99.9 % of all OS/2 systems in use today, my system/boot partition is JFS formatted
1) a long time ago, I had installed eCS as german NLS version. What that means for this error case is that some standard directories of the WPS are created with umlauts in their directory names, for example, "Desktop" becomes "Arbeitsoberfläche" in german.
2) as some of you might know, JFS.IFS saves its directory and file names in UNICODE and relies on the services of the UNICODE.SYS driver to properly convert between UNICODE and the default ASCII character set in use because effectively, the IFS interface only supports ASCII directory and filenames. The consequence of that is that you should NEVER hop between different character sets (by using the "chcp" command) when you create directories or files that have special characters in them (anything beyond the US437 character set).
3) for various reasons I have multiple boot configurations with different "config.sys" files, managed by the QSINIT selection menu. These files have different names: config.sys, config.smp, config.w4 etc.

Recently I decided to install this package:
That was the first error, because I have an AMD CPU and therefore this package was useless for me :-)

What followed next was the "cputemp" WPI package updating the default "config.sys" file by placing a driver into it. As it turned out later, it would not only add a driver load entry but also, apparently due to a bug in WarpIn (I later extracted the install script from the WPI file and found nothing wrong or suspicious in it), would remove the load line for UNICODE.SYS from the config.sys file. Because I had booted from a boot configuration that used another "config.sys" file (named, say "config.smp") this problem did not become apparent for as long as I was booting in the alternate boot configuration.

Eventually I booted into the standard boot config using file "config.sys". The base boot of loading all drivers and IFS (including JFS.IFS) went by without any problem but eventually, I was presented by the XWorkplace message that my desktop directory could not be found.
I was not too worried and suspected a simple OS2.INI or OS2SYS.INI corruption and decided to restore this set of files from a boot a few days earlier.

But on the next reboot, the error showed up again. From the commandline of the temporary desktop that had been created I decided to look directly at the filesystem naming of directories and files. And yes, "Arbeitsoberfläche" had been corrupted at the umlaut character. I then took the bad choice (in hindsight) and attempted to rename the directory back to what it was but it turned out that I was unable to do so. I was also unable to delete or rename that directory with any other tool like File Commander.
I decided to copy the desktop from a backup folder and was successful but intimidating enough, now I had two directories with the very same name "Arbeitsoberfläche" (on filesystem level !) but one of it could neither be renamed nor deleted. To remember: UNICODE.SYS driver was not loaded at this point.

It dawned on me that something had gone terribly wrong with the file system.Using DFSee, I triggered a chhdsk for the next reboot. The chkdsk would end without error but now I would directly run into a trap right after chkdsk was done. This was repeatable.

Fortunately, I had a completely different "development" boot partition that was completely intact (and both, UNICODE.SYS and JFS.IFS propery loading). And I had DFSee. But that was installed on the JFS partition that I could not boot from. Fortunately, as turned out later, that did not matter. The "broken" partition had directory naming problems but was intact as such and therefore I was able to readd the UNICODE.SYS load entry to "config.sys" on the "broken" partition.

I fired up the "development" boot partition and started DFSee. In one of its extended menus I found the possibility to rename directories and files on a very low file system level (so to say). Apparently, DFSee understands all low level structures of JFS and can directly overwrite sector content.

Subsequently it turned out that not only "Arbeitsoberfläche" had been "renamed" disastrously but also all OTHER DIRECTORIES below "Arbeitsoberfläche" that contained umlauts (yes there are quite a few directories below the "Desktop" directory ...).

For each of the affected directories, I had to hop back and forth between giving them an intermediate name like "Arbeitsoberflxxxx" and "Arbeitsoberfläche" to force the proper directory name (intermediate reboots required). After multiple reboots and some traps I was finally able to restore the partition to an acceptable state, but I had to recreate quite a few directories under the "Desktop" directory and move things to their proper place.

I think it would at least be helpful if JFS.IFS would, ideally already on bootup, report a warning if it fails in using UNICODE.SYS services instead of reporting nothing. That would have pointed me to the problem and would have saved me hours of work.
(I can understand that JFS.IFS will need to be able to continue nonetheless because otherwise you would not be able to fix the config.sys file and readd the UNICODE.SYS load entry ...).

This behaviour is surely an absolute NOGO for a new user (unless you only accept english speakers or people using the US/UK NLS version as new users).

Programming / Re: Building Qt5
« on: November 27, 2022, 12:24:46 pm »
Anyways. even for the later W4 kernels, OS support for SSE is in effect (I tried it and nothing crashed) and since we have 2022, that is sufficiently reliable information to build upon.

Sure. You even can try to build AVX branch - since you have a good way to detect an OS support for it. ;)

Obviously, gcc supports automatic vectorization from C/C++ code but VAC and Watcom compilers do not. Since I never use gcc, I always have to hand code vectorization in assembler (which I do seldomly enough).
I don`t feel like handcoding a SSE version and a AVX version. The speedup with SSE for suitable core functions, compared to using general purpose registers, is already a factor of typically 16 (when using all 8 available XMM registers under 32-bit code) or even much higher, depending on data type (byte, word, dword, qword, single precision float, double precision float).

Programming / Re: Building Qt5
« on: November 26, 2022, 05:24:15 pm »
You are right, that is the easiest and most straightforward way to detect OS support for AVX.
Unfortunately, there is nothing comparable to detect OS support for SSE (that is, CR4.OSFXSR being set instead of CR4.OSXSAVE being set). Looks like Intel never thinks any farther than up to the next corner.

Anyways. even for the later W4 kernels, OS support for SSE is in effect (I tried it and nothing crashed) and since we have 2022, that is sufficiently reliable information to build upon.

Pages: [1] 2 3 ... 69