Suppress hardware errors if AUTOFAIL is missing from CONFIG.SYS

[Dmitry A. Kuminov]

There's already been some discussion about whether we should issue DosError(FERR_DISABLEHARDERR) or not upon Qt initialization. Back then, I decided that we should not. Now I think that we may satisfy all parties by doing this call if there is no explicit AUTOFAIL setting in CONFIG.SYS which will:

1. Disable these annoying error notification dialogs on systems where it is implicitly on by default (i.e. no AUTOFAIL setting in CONFIG.SYS, which is equivalent to AUTOFAIL=NO). This is the case for old Warp installations.
2. Won't change the behavior on modern eCS systems which put AUTOFAIL=YES in CONFIG.SYS by default.
3. Let people that want these notifications have them by explicitly putting AUTOFAIL=NO to CONFIG.SYS.

​This thread contains some recent discussion on this topic.

[Dmitry A. Kuminov]

Adding support for watching drive list changes to the polling file system watcher and using this feature in QFileDialog to get instant drive change notifications in "My Computer" causes QFileSystemWatcher to check for drive changes every 3 seconds which will just the people having anything else but AUTOFAIL=YES in CONFIG.SYS -- these nasty error popoups will also appear every 3 seconds for drives with no media.

Therefore, we must disable these popups for our process completely and unconditionally.

[Dmitry A. Kuminov]

...will just kill the people... (fun, the "kill" word disappeared somehow)

[Dmitry A. Kuminov]

Just for reference, the changeset with the file watcher changes is r613.

And here is the hint Steven Levine gave me that will help to restore the state of hard error notifications upon Qt application termination (just to be consistent):

// 27 - Get process DosError setting
ULONG SavedDosError = 1;
DosSysCtl((ULONG)27, (ULONG)&SavedDosError);

[Dmitry A. Kuminov]

Done in r615. Tested with no AUTOFAIL, AUTOFAIL=NO and AUTOFAIL=YES. Goodbye, popups!

BTW, I discovered that in AUTOFAIL=YES mode the value of DosError() is always 0x02 (e.g. both exceptions and errors are disabled) and cannot be changed. Which is fine for us.

[rudi]

The current implementation still gives me one error popup for each non-ready drive when clicking on "Computer". However, the DIRVIEW example does not.

[Dmitry A. Kuminov]

Are you sure you have an up-to-date everything? This is barely possible now since once QtCore4.dll gets loaded (e.g. before main()), it calls DosError() like this:

    // 27 - Get process DosError setting
    DosSysCtl(27, &savedDosErrorState);
    // disable hardware error popups to make the user's life less annoying
    DosError(savedDosErrorState & ~FERR_ENABLEHARDERR);

and therefore effectively suppresses all hardware error popups.

Please check that globalInit() in qcoreapplication_pm.cpp gets executed for you by adding printf() there.

[rudi]

This was with a version from about 2 days ago. I'm just checking out a new one. For some reason SVN thinks that a lot of stuff has changed. So I will have to do a full rebuild...

[Dmitry A. Kuminov]

Please abort the update and try to debug your current code (there wasn't changes in this area since the defect was closed) -- there is a full source update (4.6.2) and will take you many hours to build.

[rudi]

Too late... Unfortunately, I can't build the stuff anymore. GCC3.3.5 won't do and I have not yet figured out, how the get that fing 4.4.2 to work.

[Dmitry A. Kuminov]

Yes, GCC 3.3.5 is a no go from now on (webkit will never build with that). I actually prepared a special ready-to-use ZIP including GCC442 and everything else (like WLINK) we need to buold Qt. Here's the link to the test package: ​ftp://ftp.dmik.org/tmp/gcc442-for-qt-test.zip.

Please try it to see if it works on your side but don't distribute; I will make it publicly available later.

[rudi]

That worked. But when I look at the README which shows the steps necessary to create it I'm shaking my head and ask myself what happened to the good old OS/2 that is is so complicated to get a compiler (that on any other platform works just out of the box) up an running.

Anyway, at the moment my build is not complete, but has reached quite some progress. However, without manual intervention it refused to link QMAKE because it wouldn't find REGISTRY.DLL. Do we still need it ?

BTW, does webkit build at all in the current trunk ? I have not (yet) tried it..

[Dmitry A. Kuminov]

Well these steps are the kitchen instructions :) For the end user, I tried to made it as simple as it ought to be on OS/2 (e.g. unzip anywhere, start a .cmd and you are done).

Regarding registry.dll, it is still necessary since we still provide access to OS/2 INI files through QSettings (but don't use it from within Qt). And this requirement is described in the Qt's README.OS2. I didn't make it part of gcc442.cmd because of that.

[Dmitry A. Kuminov]

Regarding WebKit, see #135.

[rudi]

O.K., finally I have a complete clean build of everything (except webkit ;-).

I still get one error popup for each "non-ready" / "non-present" drive when clicking on "Computer" in the standard file dialog. And as before, DIRVIEW.EXE doesn't produce any popups.

[Dmitry A. Kuminov]

Here, with the current SVN I don't see any hardware error popups with AUTOFAIL=NO in CONFIG.SYS when I use the standard file dialog and click "Computer" and I see no reason why you should get it in the same conditions.

Did you try what I asked in comment:6?

[rudi]

I see no reason why you should get it in the same conditions.

But I do get it. It also happens, when I double-click on a non-ready drive.

Did you try what I asked in comment:6?

Yes. It gets called.

BTW, I don't have XWorkplace installed (DosOpen(\PIPE\XNOTIFY) returned 3). Furthermore, it since DIRVIEW does not trigger the popups, I suspect it has something to do with filesystem watcher and/or background list population, which AFAIK is utilized by the standard file dialog, but not by the QDirModel on which DIRVIEW relies.

[Dmitry A. Kuminov]

And what is the value of this parameter after DosError() is called? (You may call DosSysCtl(27, &ulTemp) again to find it out). Also, what is your AUTOFAIL setting and what OS/2 version do you use?

You are right that the dirview example doesn't use file system notifications. But anyway, I don't know what can cause this because DosError() is executed before even main() gets run so it must disable the popups for the current process. Of course, if it does so only for the current (or for the main) thread, it would explain this. You may check it too.

[rudi]

And what is the value of this parameter after

It's set up O.K. in globalInit().

what is your AUTOFAIL setting

No setting in CONFIG.SYS i.e. defaults to NO.

what OS/2 version

Warp4 FP15

Of course, if it does so only for the current (or for the main) thread

No, it's not a "per thread" setting. However, I've found this:

A strategic "printf" in gui\dialogs\qfileinfogatherer.cpp (method ::run) reveals, that someone is turning on FERR_ENABLEHARDERR ! When the file dialog comes up for the first time, harderrors are off (as set by gloablinit()). But when I click on "Computer", I get a second message from qfileinfogatherer::run. In this case, harderrors are enabled and stay so for the rest of the program's run time.

[rudi]

O.K, it's caused by WinLoadFileIcon() in gui\itemviews\qfileiconprovider.cpp. Looks like we must call DosError() again after this function...

[rudi]

BTW, the destrictor of QOS2FileSystemWatcherEngine() will call DosCloseEventSem() with a NULLHANDLE, when the pipe could not be opened. Also in the constructor: why are you excluding ERROR_FILE_NOT_FOUND from being issued as qWarning ? DosOpen seems to return
ERROR_PATH_NOT_FOUND in case the pipe does not exist.

[Dmitry A. Kuminov]

Okay, I knew that it's some OS/2 API call (I just wonder why it doesn't trigger it here)... I don't actually feel like we should fix this particular case because of the following:

1. There may be other bogus APIs which we will eventually bump into.
2. There may be 3rd-party DLLs loaded into our process (like the ones from HINI_USER_PROFILE\SYS_DLLS).
3. There is an easy global "once-and-for-all" solution for that: AUTOFAIL=YES in CONFIG.SYS.

While in 1 we could theoretically create a wrapper for each OS/2 API call to surely prevent this, this looks an overkill to me due to 3. More over, 2 makes it all useless because we cannot prevent a 3rd party DLL from such a nasty behavior. Of course, we could call DosError() *before* each our call to the file API but that's also an overkill keeping 3 in mind.

So, to be consistent, I would like to remove the globalInit() thing at all. This will force people to have AUTOFAIL=YES in config.sys and everybody will be happy.

[Dmitry A. Kuminov]

We can even set AUTOFAIL=YES from the WPI installer probably. And I can mention in in README.OS2.

[Dmitry A. Kuminov]

Regarding ERROR_FILE_NOT_FOUND,I now check both in r702, thanks for noticing. The DosCloseEventSem() is adjusted as well, for consistency.

[rudi]

There may be 3rd-party DLLs loaded

ISTR, that a long time ago there used to be a printer driver (Laserjet ?), that re-enabled error popups after showing the page setup dialog.

Of course, we could call DosError?() *before* each our call to the file API

Or we could use the DosOpen() method as discussed in #137

I still dislike the AUTOFAIL=YES in CONFIG.SYS thing...

[Dmitry A. Kuminov]

We cant use DosOpen() everywhere since we normally access files using LIBC and using the OS/2 API is an exception where no LIBC functionality is available. For instance, QFile("A:\blalba").open() will trigger a popup too.

I understand your disliking but the facts tell us that we cannot give a 100% guarantee that any Qt4-based application will be free from hard error popups when AUTOFAIL is not set YES, no matter what we do. And even a single non-working case will render all our efforts to zero.

And Silvan agrees with me here.

[rudi]

For instance, QFile("A:\blalba").open() will trigger a popup too.

True, but that does also happen when doing this using the OS/2 file API directly. But opposed to that, opening a standard PM file open box does normally not involve popups. Thus I do not share your view of "all" or "nothing".

[rudi]

I just wonder why it doesn't trigger it here

Maybe because you are running a different fixpack level than I do.

[Dmitry A. Kuminov]

Maybe. eCSrc7 here (whcih implies Warp 4.5 fp6 I suppose).

And I'm trying to look on that from the user's perspective. I'm pretty sure that if we do all that you propose and then a bogus DLL will slip in or a program will do an explicit open call bypassing our traps, the users will still complain "what the heck!" -- this is why I don't want to make exceptions here.

[Dmitry A. Kuminov]

In r715, I reverted r615 (the DosSetError() call at startup). Instead, in r716 I implemented your proposal to use DosOpen() instead of DosQueryFSAttach() just to make the life of those who's picky about changing to AUTOFAIL=YES easier. Now the popups only appear if you specifically type e.g. A:\somefile.txt in the file dialog (this can also be fixed by analyzing the entered filepath and checking for A: if it starts with it, to fully match the renovated PM file dialog behavior) but I'm not going to implement it now.

Note that I will also offer the user to set AUTOFAIL=YES in the installer and in README.