16-bit application fails due to regression in NE-module handling

[Saulius Krasuckas]

I've entered new bug #2332 [1] recently, where I've described my problem.

I think the application was compiled with some BC compiler for win16
platforms.  32 here at "last error" means some sharing violation, I hope:

[s2 at katleriai wine]$ cat include/winerror.h | grep ' \+32$'
#define ERROR_SHARING_VIOLATION                            32

The quick analysis of the patch [1] revealed me two points:

+  handle = FILE_CreateFile( full_name.long_name, GENERIC_READ|GENERIC_WRITE, 0,
+                           NULL, OPEN_EXISTING, 0, 0, TRUE,
+                           GetDriveTypeW( full_name.short_name ) );
...
   /* Open file */
-  if ((hFile = OpenFile16( name, &ofs, OF_READ )) == HFILE_ERROR16)
+  if ((hFile = OpenFile16( name, &ofs, OF_READ|OF_SHARE_DENY_WRITE )) == HFILE_ERROR16)
       return (HMODULE16)2;  /* File not found */

which confused me a bit.  By doing some wild guess I tried to revert last
mentioned change.  Heh, reversing this line really lets the app to
succeed.

My discovery may imply I should write some additional wine-tests, but I'd
like to ask in such case:  do I need the test (for example of OpenFile16()
function) to be 16-bit style?  I mean doing some NE-module-over-ELF and
compiling 16-bit app within Wine(lib).  

If yes, then how it should be done?  If no, then what should I do else to
make Wine happy or even to submit the correct patch?

Yes, I was a bit too lazy to RSFM.  TIA.