Please attach the complete terminal output as-is.

How big is the log if you compress it with rzip
(see http://rzip.samba.org/ )?

Also, consider adding +seh to the winedebug options.

Oh, and which version of Solidworks is this?

Created attachment 7714 [details]
Output from Wine without any debug options enabled

Here is the output from Wine when I ran Solidworks and crashed it by trying to open a file.  I didn't change the debug options from their defaults.

The package says Solidworks Student Edition 2006 - 2007, so I think that I am using Solidworks 2006 Student Edition.

I ran wine with WINEDEBUG=fixme+all,warn+all,+relay,warn+all,+seh and then compressed it with rzip -9.  The resulting file is 6.8M, but bugs.winehq.org will only let me upload a 1M file.  Any ideas on where I can put it online so people can access it?

I have uploaded the full log file to 

http://austin.linux.googlepages.com/fulloutput.log.rz

The problem is partially solved using winetricks dcom98 (I.E. overriding ole32, oleaut32, msvcrt, etc...)

overriding only oleaut32 seems to be necessary

"An unsupported operation was attempted." pop ups are still there, but opening a file works.

looks like this bug is related to http://bugs.winehq.org/show_bug.cgi?id=8795

As saving files fails, even with ole  overrides

Now opening a file works without any ddl override,  but "An unsupported operation was attempted." pop ups are still there.

Saving files still fails. the problem seems to be related to the storage ( ole32?)  implementation

An unimplemented gdiplus function prevents file saving : 

trace:storage:StorageImpl_ReadProperty storage name: L"ModelStamps"
trace:storage:BlockChainStream_WriteAt block 73
trace:storage:BlockChainStream_ReadAt (0x4e9bfa0)-> 3456 0x32d844 128 0x32d840
trace:storage:BlockChainStream_ReadAt block 71
trace:storage:StorageImpl_ReadProperty storage name: L"PreviewPNG"
trace:storage:StorageBaseImpl_AddStream Stream added (stg=0xbd07918 strm=0xeda6db8)
wine: Call from 0x7b844b20 to unimplemented function gdiplus.dll.GdipCreateBitmapFromGdiDib, aborting

It should be easy to at least add a stub for it ?
It is just destinated to make the preview PNG thumbnail, so one can live without it.

Does 'winetricks gdiplus' work around the problem?

(In reply to comment #12)
> Does 'winetricks gdiplus' work around the problem?
> 

Partially : 

the thumbnail is created, but then there is another problem that make the application crashing. 

trace:storage:StorageImpl_ReadProperty storage name: L"PreviewPNG"
trace:storage:BlockChainStream_WriteAt block 2457
trace:storage:BlockChainStream_WriteAt block 2458
trace:storage:BlockChainStream_WriteAt block 2459
trace:storage:BlockChainStream_WriteAt block 2460
trace:storage:BlockChainStream_WriteAt block 2461
trace:storage:BlockChainStream_WriteAt block 2462
trace:storage:BlockChainStream_WriteAt block 2463
trace:storage:BlockChainStream_WriteAt block 2464
trace:storage:BlockChainStream_WriteAt block 2465
trace:storage:BlockChainStream_WriteAt block 2466
trace:storage:BlockChainStream_WriteAt block 2467
trace:storage:StgStreamImpl_Write <-- S_OK, written 5505
err:ntdll:RtlpWaitForCriticalSection section 0x7d45ece0 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0032, blocked by 0009, retrying (60 sec)
err:ntdll:RtlpWaitForCriticalSection section 0x3998dbfc "?" wait timed out in thread 0009, blocked by 0032, retrying (60 sec)
fixme:storage:StorageImpl_Revert (0xebb0dc0): stub
trace:storage:StorageBaseImpl_Release (0xebb0dc0) ReleaseRef to 0
trace:storage:StorageImpl_Destroy (0xebb0dc0)
trace:storage:StorageBaseImpl_DeleteAll Streams deleted (stg=0xebb0dc0 strm=0xeb02468 next=0xebb0dc8 prev=0xebb0dc8)
wine: Critical section 7d45ece0 wait failed at address 0x7bc3a930 (thread 0032), starting debugger...
Unhandled exception: wait failed on critical section 0x7d45ece0 X11DRV_CritSection
err:seh:raise_exception Unhandled exception code c0000194 flags 0 addr 0x7bc3a930

Please note that this test is made with an hacked opengl.c for bug 13195 workaround , there is currently nothing displayed in graphics windows (no DC !), so there is maybe some other reasons for the crash...

It works : file is correctly saved when overriding gdiplus 

The annoying popup is still there when clicking on any file in the file dialog

The crash is another point. But I need to solve opengl bug 13195 before.

Is this still an issue in current (1.1.9 or newer) wine?

Removing deprecated CVS/GIT version tag. Please retest in current git. If still present, update version field to earliest known version of wine that had this bug. Thanks!

Abandoned. If you still have a problem in current (1.1.26 or newer) wine, and can provide the needed information, feel free to reopen.

Closing.

Created attachment 24433 [details]
After this window SW2007 exits

This is still an issue in Wine 1.1.32 on SolidWorks 2007.
winetricks gdiplus doesn't help. Installing dcom98 doesn't help. Overriding oleaut32 or ole32 doesn't help.
There is no specific output after displaying error.

Before installing SolidWorks 2007 I did:
winetricks mfc40 mfc42 dotnet20 gecko ie6

Reopening then...

Try *not* installing ie6.

Created attachment 24471 [details]
wine-1.1.32-260-gf222a16

(In reply to comment #21)
> Try *not* installing ie6.

OK, so before installing SW2007 I did only winetricks mfc42 dotne20. *Not* installing ie6 didn't help, the same error window appears. I'm attaching log. Do you want me to attach log with WINEDEBUG=+relay,+seh ?

Created attachment 24472 [details]
wine-1.1.32-260-gf222a16

(In reply to comment #21)
> Try *not* installing ie6.

OK, so before installing SW2007 I did only winetricks mfc42 dotne20. *Not* installing ie6 didn't help, the same error window appears. I'm attaching log. Do you want me to attach log with WINEDEBUG=+relay,+seh ?

Thanks for the info.  (No, I don't have time to look,
and there are so many problems in the log I wouldn't
know where to start.)

Similar problem occurs in SolidWorks 2008. When I click open file icon then dialog box with "An unsupported operation was attempted" pops up several times but finally Window where I can open file appears (in SW 2007 it crashed or hanged)

In terminal this lines iterate (with different hwnd numbers only)

fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETSTATE): stub
fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETTASKBARPOS, hwnd=0x783ccc24): stub

confirmed with Solidworks 2009 and wine 1.1.33

winetricks vcrun2005 and ie6 was needed for install ( but not dotnet20 !)

Sometimes saving files works, but most of the time it hangs the application. I would be very pleased to submit logs if it can help, just tell me which ones.

This bug exposes two issues : 

- open/save file crash is maybe a duplicate of bug 7873

- the popup issue is only related to a file dialog UI problem. Nothing to do with file operations problems. Interestingly, very old Solidworks versions ( 2003, which works without mfc40 and vcrun2005 ) doesn't have this problem.

Created attachment 25520 [details]
File dialog screenshot 

file dialog screenshot, with error pop-up when clicking on the file. 

It shows that the preview image and some buttons are incorrectly placed and dimensioned.

Created attachment 25521 [details]
+commdlg log

commdlg channel trace, with a file open operation :

- dialog appears after 5 error pop-ups
- when displayed, all the dialog is "locked" : no file can be choosed from the file list.
- clicking to the parent directory icon works, and then files can be selected. 
- every time a file or a folder is clicked, the error message pops-up.
- a file is selected and opened (2 error pop-ups).

the trace was made with regular (stripped) wine version. Is a version with symbols useful for this problem ?

(In reply to comment #29)
> Created an attachment (id=25521) [details]
> +commdlg log
> 
> commdlg channel trace, with a file open operation :
> 
> - dialog appears after 5 error pop-ups
> - when displayed, all the dialog is "locked" : no file can be choosed from the
> file list.
> - clicking to the parent directory icon works, and then files can be selected. 
> - every time a file or a folder is clicked, the error message pops-up.
> - a file is selected and opened (2 error pop-ups).
> 
> the trace was made with regular (stripped) wine version. Is a version with
> symbols useful for this problem ?

Symbols are only useful for a crash/backtrace. Most distros have them in a wine-dev or wine-dbg package. Or you can compile wine yourself, and use the '-g' CFLAG.

The annoying pop-up window when opening  a file dialog in Solidworks is still there in 1.2-rc1.

with 1.2-rc1, when saving a new file, the filename cannot be entered. The default name "part1.sldprt" is displayed in the filename dialog area, but cannot be changed. 

"Save as" works : the filename can be changed in the dialog box.

update : 

Entering new filename works on local disk, but not well on network mounts.

The annoying pop-up window when opening  a file dialog in Solidworks is still
there in 1.2 release.
Same popup appears when opening every new dir in a file dialog, and clicking on file before preview is shown.

interestingly, none of the file properties are displayed in the file list

In 1.3.6, there is a new regression : when opening file dialog, the popup error window is displayed once or twice, but then all the application window is locked, I.E. nothing can be done inside, even minimize/maximize from WM is locked. 

Console displays "fixme:win:LockWindowUpdate ((nil)), partial stub!" every 2 secs.

the only way to kill the application is wineserver -k, as ctrl-c in console only kills one thread.

regression test will follow.

Overriding comctl32, shell32 and slwapi to native,builtin workarounds this bug.

Overriding comdlg32, shell32 and slwapi to native,builtin workarounds this bug.

Update, good overrides are : 

WINEDLLOVERRIDES="comdlg32=builtin,native","shell32=native,builtin","shlwapi=builtin,native"

Some file dialog elements are misplaced, but it works.

Hmm, does that mean the component should be shell32?

(In reply to comment #41)
> Hmm, does that mean the component should be shell32?

Update, only comdlg32=builtin,native is necessary. It works Without shell32, it was just a side effect of setting comdlg32 to native first. 

So finally one just have to put XP comdlg32.dll to Solidworks folder, no override needed, as builtin,native is the default one.

The bug is somewhere in comdlg32, unfortunately I wasn't able to generate useful traces.

(In reply to comment #42)
> Update, only comdlg32=builtin,native is necessary. It works Without shell32, it
> was just a side effect of setting comdlg32 to native first. 
> 
> So finally one just have to put XP comdlg32.dll to Solidworks folder, no
> override needed, as builtin,native is the default one.
> 
> The bug is somewhere in comdlg32, unfortunately I wasn't able to generate
> useful traces.


So does 'comdlg32=native' actually help?

(In reply to comment #43)
> (In reply to comment #42)
> > Update, only comdlg32=builtin,native is necessary. It works Without shell32, it
> > was just a side effect of setting comdlg32 to native first. 
> > 
> > So finally one just have to put XP comdlg32.dll to Solidworks folder, no
> > override needed, as builtin,native is the default one.
> > 
> > The bug is somewhere in comdlg32, unfortunately I wasn't able to generate
> > useful traces.
> 
> 
> So does 'comdlg32=native' actually help?

Yes, file dialogs are displayed correctly, but then shell32 and shlwapi are needed too. And all context menus ( right-click on parts icon on feature manager treeview ) involving files ops. are not available.

When setting comdlg32 to builtin,native only, app. behaves almost perfectly, the only problems are the misplacement of of elements in file dialog ( see screenshot ), and when opening a dialog, filename can't be selected, but changing folder  solves the problem.

Is there a way to see exactly for which function the native DLL is used ?
+commctl,+loaddll doesn't show anything useful.

Created attachment 31803 [details]
file dialog screenshot

(In reply to comment #44)
> > So does 'comdlg32=native' actually help?
> 
> Yes, file dialogs are displayed correctly, but then shell32 and shlwapi are
> needed too. And all context menus ( right-click on parts icon on feature
> manager treeview ) involving files ops. are not available.
> 
> When setting comdlg32 to builtin,native only, app. behaves almost perfectly,
> the only problems are the misplacement of of elements in file dialog ( see
> screenshot ), and when opening a dialog, filename can't be selected, but
> changing folder  solves the problem.

That's confusing, 'comdlg32=builtin,native' is default Wine setting and
is really a no-op, i.e. it changes nothing.

(In reply to comment #47)
> (In reply to comment #44)
> > > So does 'comdlg32=native' actually help?
> > 
> > Yes, file dialogs are displayed correctly, but then shell32 and shlwapi are
> > needed too. And all context menus ( right-click on parts icon on feature
> > manager treeview ) involving files ops. are not available.
> > 
> > When setting comdlg32 to builtin,native only, app. behaves almost perfectly,
> > the only problems are the misplacement of of elements in file dialog ( see
> > screenshot ), and when opening a dialog, filename can't be selected, but
> > changing folder  solves the problem.
> 
> That's confusing, 'comdlg32=builtin,native' is default Wine setting and
> is really a no-op, i.e. it changes nothing.

I agree. that's what i say. No overrides, just copy the dll.

But why putting a native dll in the app folder (I.E. c:\program file\solidWorks) solved the problem ? Is it possible the the app preloads the dll independantly from wine system ?

If terminal window on a left side on your last screenshot is for terminal where you're running application then you're running builtin comdlg32 (see fixme output).

There's no demo for that?

(In reply to comment #49)
> If terminal window on a left side on your last screenshot is for terminal where
> you're running application then you're running builtin comdlg32 (see fixme
> output).
> 

It does. So why removing the dll from solidworks folder breaks it ?

> There's no demo for that?

A download is available from Soliworks site. Unfortunately, the online installer doesn't work with wine. So the download has to be made on Windows.

http://www.solidworks.com/sw/education/SDL_form.html

(In reply to comment #50)
> (In reply to comment #49)
> > If terminal window on a left side on your last screenshot is for terminal where
> > you're running application then you're running builtin comdlg32 (see fixme
> > output).
> > 
> 
> It does. So why removing the dll from solidworks folder breaks it ?
> 
> > There's no demo for that?
> 
> A download is available from Soliworks site. Unfortunately, the online
> installer doesn't work with wine. So the download has to be made on Windows.
> 
> http://www.solidworks.com/sw/education/SDL_form.html

Open or save filedialogs does not work in Ubuntu 10.10 & wine 1.3.10 - 1.3.11. Dialogs were working with wine 1.3.4. All I get is two "unsupported command was attempted"-messageboxes and then SolidWorks hangs. Earlier with version 1.3.4 there were several more of those boxes and then the file dialog opened.

(In reply to comment #51)

> Open or save filedialogs does not work in Ubuntu 10.10 & wine 1.3.10 - 1.3.11.
> Dialogs were working with wine 1.3.4. All I get is two "unsupported command was
> attempted"-messageboxes and then SolidWorks hangs. Earlier with version 1.3.4
> there were several more of those boxes and then the file dialog opened.


This problem was already pointed in comment #37. But for 32bits ubuntu wine packages, copying native comdlg32.dll solves the problem. So maybe your problem is related to the 64bits package ?

I tried to run SWx with +snoop,+relay to see exactly how native comdlg32 is called, but unfortunately with +snoop it hangs during startup. Is there a way to change WINEDEBUG on the fly, just before opening file dialog ?

(In reply to comment #42)
> So finally one just have to put XP comdlg32.dll to Solidworks folder, no
> override needed, as builtin,native is the default one.


I can confirm this in wine-1.3.12-174-g58786dc and SolidWorks 2010.

Is there way to get debug log about this issue for developers? If yes, could someone post some isntructions how to get it logged?

(In reply to comment #54)
> Is there way to get debug log about this issue for developers? If yes, could
> someone post some isntructions how to get it logged?

Please run a regression test between 1.3.4 and 1.3.5  My computer is too slow and it will take hours.

(In reply to comment #55)
> Please run a regression test between 1.3.4 and 1.3.5  My computer is too slow
> and it will take hours.

I might have proper computer to run that kind of tasks but I did not get any useful information when I tried it. 

However now when I builded the shared wow64 setup from latest git sources and copied the comdlg32.dll from my Windows Vista partition to .wine/drive_c/Program Files(x86)/SolidWorks folder the file dialogs runs with out any hangs or messageboxes! Also menus are now correctly positioned and works exactly like in windows! Great work who ever did fix this, thanks!

(In reply to comment #50)
> (In reply to comment #49)
> > If terminal window on a left side on your last screenshot is for terminal where
> > you're running application then you're running builtin comdlg32 (see fixme
> > output).
> It does. So why removing the dll from solidworks folder breaks it ?

Copying comdlg32.dll to the SolidWorks installation directory works for me as well...

I did some more research:
- When I copy it to the windows/system32 directory and updating comdlg32 to native SolidWorks crashes.
- When I copy it to the windows/system32 directory and *not* updating comdlg32 to native (so keeping it set to buildin) SolidWorks works as well!
- Without copying comdlg32.dll, SolidWorks shows the "An unsupported operation was attempted" and hangs after clicking OK while repeating:
   fixme:win:LockWindowUpdate ((nil)), partial stub!

I was using wine 1.3.17 on Kubuntu 10.10 x64 (32bit Wine)

So for now I copy comdlg32 to the windows/system32 directory without changing winecfg

Bug is still there with wine 1.5.15 and Sw 2012 32 bits.

Hello folks,

confirming.

Prerequisite: 'winetricks -q mfc40 mfc42'

--- snip ---
$ pwd
/home/focht/.wine/drive_c/Program Files/SolidWorks

$ WINEDEBUG=+tid,+seh,+relay,+ole,+variant wine ./SLDWORKS.exe >>log.txt 2>&1
...
0120:Call KERNEL32.LoadLibraryW(007fa084 L"comctl32.dll") ret=006d57bc
0120:Ret  KERNEL32.LoadLibraryW() retval=7e530000 ret=006d57bc
0120:Call KERNEL32.GetProcAddress(7e530000,007f39c4 "DllGetVersion") ret=006d57d5
0120:Ret  KERNEL32.GetProcAddress() retval=7e540450 ret=006d57d5
0120:Call comctl32.DllGetVersion(0033dae4) ret=006d57e6
0120:Ret  comctl32.DllGetVersion() retval=00000000 ret=006d57e6
0120:Call KERNEL32.FreeLibrary(7e530000) ret=006d5801
0120:Ret  KERNEL32.FreeLibrary() retval=00000001 ret=006d5801 
...
0120:Call KERNEL32.LoadLibraryW(052ebb98 L"COMDLG32.DLL") ret=00664439
0120:Ret  KERNEL32.LoadLibraryW() retval=7e190000 ret=00664439
0120:Call KERNEL32.GetProcAddress(7e190000,007f39c4 "DllGetVersion") ret=00664452
0120:Ret  KERNEL32.GetProcAddress() retval=00000000 ret=00664452
0120:Call msvcrt.malloc(0000001a) ret=5f8038d6
0120:Call ntdll.RtlAllocateHeap(00110000,00000000,0000001a) ret=7ed5ef9f
0120:Ret  ntdll.RtlAllocateHeap() retval=0527f0c8 ret=7ed5ef9f
0120:Ret  msvcrt.malloc() retval=0527f0c8 ret=5f8038d6
0120:Call ntdll.wcscpy(0527f0c8,052ebb98 L"COMDLG32.DLL") ret=006644b4
0120:Ret  ntdll.wcscpy() retval=0527f0c8 ret=006644b4
0120:Call version.GetFileVersionInfoSizeW(0527f0c8 L"COMDLG32.DLL",0033dad4) ret=006644c1 
...
0120:Ret  version.GetFileVersionInfoSizeW() retval=0000067c ret=006644c1
0120:Call msvcrt.malloc(0000067c) ret=5f8038d6
0120:Call ntdll.RtlAllocateHeap(00110000,00000000,0000067c) ret=7ed5ef9f
0120:Ret  ntdll.RtlAllocateHeap() retval=05309a48 ret=7ed5ef9f
0120:Ret  msvcrt.malloc() retval=05309a48 ret=5f8038d6
0120:Call version.GetFileVersionInfoW(0527f0c8 L"COMDLG32.DLL",00000000,0000067c,05309a48) ret=006644dc 
...
0120:Ret  version.GetFileVersionInfoW() retval=00000001 ret=006644dc
0120:Call version.VerQueryValueW(05309a48,007f3990 L"\\VarFileInfo\\Translation",0033dad0,0033dae0) ret=006644fa
0120:Ret  version.VerQueryValueW() retval=00000001 ret=006644fa 
...
0120:Call KERNEL32.LoadLibraryA(5f8a14d0 "comdlg32.dll") ret=5f805a00
0120:Ret  KERNEL32.LoadLibraryA() retval=7e190000 ret=5f805a00
0120:Call KERNEL32.InterlockedExchange(5f8d1620,7e190000) ret=5f805a14
0120:Ret  KERNEL32.InterlockedExchange() retval=00000000 ret=5f805a14
0120:Call KERNEL32.GetProcAddress(7e190000,5f8c4cbc "GetSaveFileNameW") ret=5f8059be
0120:Ret  KERNEL32.GetProcAddress() retval=7e19f9b8 ret=5f8059be
0120:Call comdlg32.GetSaveFileNameW(0033ded0) ret=5f852d90
0120:Call comctl32.InitCommonControlsEx(0033db28) ret=7e1a5ab1
0120:Ret  comctl32.InitCommonControlsEx() retval=00000001 ret=7e1a5ab1 
...
0120:Call user32.GetWindowTextW(000a048a,0033c3d8,00000100) ret=5f8142ea
0120:Call window proc 0x7eadc84e (hwnd=0xa048a,msg=WM_GETTEXT,wp=00000100,lp=0033c3d8)
0120:Ret  window proc 0x7eadc84e (hwnd=0xa048a,msg=WM_GETTEXT,wp=00000100,lp=0033c3d8) retval=00000000
0120:Ret  user32.GetWindowTextW() retval=00000000 ret=5f8142ea
0120:Call KERNEL32.lstrcmpW(0033c3d8 L"",5f8d0bcc L"") ret=5f81430f
0120:Ret  KERNEL32.lstrcmpW() retval=00000000 ret=5f81430f
0120:Call user32.GetDlgItem(000b0716,00001dcb) ret=5f80e659
0120:Ret  user32.GetDlgItem() retval=00000000 ret=5f80e659
0120:Call msvcrt._CxxThrowException(0033c5d0,5f8b2e78) ret=5f85141a
0120:Call KERNEL32.RaiseException(e06d7363,00000001,00000003,0033c564) ret=7ed45441
0120:trace:seh:raise_exception code=e06d7363 flags=1 addr=0x7b83a97b ip=7b83a97b tid=0120
0120:trace:seh:raise_exception  info[0]=19930520
0120:trace:seh:raise_exception  info[1]=0033c5d0
0120:trace:seh:raise_exception  info[2]=5f8b2e78
0120:trace:seh:raise_exception  eax=7b8269e1 ebx=7b8bb000 ecx=19930520 edx=0033c4b4 esi=0033c560 edi=0033c520
0120:trace:seh:raise_exception  ebp=0033c4f8 esp=0033c494 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00000283
0120:trace:seh:call_stack_handlers calling handler at 0x5f890e11 code=e06d7363 flags=1
0120:trace:seh:cxx_frame_handler handling C++ exception rec 0x33c4a0 frame 0x33c65c trylevel 0 descr 0x5f8b40c8 nested_frame (nil)
0120:trace:seh:dump_exception_type flags 0 destr (nil) handler (nil) type info 0x5f8b2e60
0120:trace:seh:dump_exception_type     0: flags 1 type 0x5f8d4d58 {vtable=0x5f899864 name=.PAVCNotSupportedException@@ ()} offsets 0,-1,0 size 4 copy ctor (nil)
0120:trace:seh:dump_exception_type     1: flags 1 type 0x5f8d4d18 {vtable=0x5f899864 name=.PAVCSimpleException@@ ()} offsets 0,-1,0 size 4 copy ctor (nil)
0120:trace:seh:dump_exception_type     2: flags 1 type 0x5f8d4cd0 {vtable=0x5f899864 name=.PAVCException@@ ()} offsets 0,-1,0 size 4 copy ctor (nil)
0120:trace:seh:dump_exception_type     3: flags 1 type 0x5f8d4d00 {vtable=0x5f899864 name=.PAVCObject@@ ()} offsets 0,-1,0 size 4 copy ctor (nil)
0120:trace:seh:dump_exception_type     4: flags 1 type 0x5f8d4cf0 {vtable=0x5f899864 name=.PAX ()} offsets 0,-1,0 size 4 copy ctor (nil)
...
0120:Call user32.MessageBoxW(00060762,0033ba10 L"An unsupported operation was attempted.",00178278 L"SolidWorks",00000030) ret=5f86881e 
--- snip ---

The app customizes the file open/save dialogs based on the Windows version _and_ the version of common controls found.

Wine's comdlg32 version 4.0.0.950 is technically inconsistent with reported WinVer 'Windows XP' which confuses the app (should be >= 5.8x).

MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/hh298349%28v=vs.85%29.aspx

and Mr. Chappell himself (although it's comctl32, the same applies to comdlg32):

http://www.geoffchappell.com/studies/windows/shell/comctl32/history/

The version resource part should be updated like Wine's comctl32.
With that part fixed, 'save' works.

$ wine --version
wine-1.7.13-100-gfcae016

Regards

Hello folks,

this is fixed by commit http://source.winehq.org/git/wine.git/commitdiff/73a2408f27a7454f9fccd3558dd20286d52eda25

ThanksStefan

Regards

Closing bugs fixed in 1.7.14.