http://bugs.winehq.org/show_bug.cgi?id=19816

Dmitry Timoshkov [email protected] changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WONTFIX

--- Comment #1 from Dmitry Timoshkov [email protected] 2009-08-23 01:52:19 --- This is outside of Wine development, same as MFC and others.

http://bugs.winehq.org/show_bug.cgi?id=19816

Alexandre Julliard [email protected] changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|WONTFIX |

--- Comment #3 from Alexandre Julliard [email protected] 2009-08-23 02:48:04 --- If it's shipped with Windows then it's within Wine's scope. Of course it probably won't happen any time soon, but it's still a valid request.

http://bugs.winehq.org/show_bug.cgi?id=19816

--- Comment #5 from Dmitry Timoshkov [email protected] 2009-08-23 09:47:15 --- Windows also ships msvbvm50, mfc40, mfc42, mfc71, msvcp50, msvcp60, msvcp70, msvcp71, msvcr70, mdac.

Is it ok to start accepting requests for those as well?

http://bugs.winehq.org/show_bug.cgi?id=19816

--- Comment #7 from Bamm Gabriana [email protected] 2009-08-23 14:41:43 --- As the requestor of this enhancement, please let me explain. So many installers nowadays no longer include these DLLs because they assume they are on the system. As a user, I believe that ideally, running the installer in Wine should allow the user the immediately run the program. I think requiring the user to know that they need to use winetricks after installing their app adds to the reputation of Wine being only for advance users.

I believe that winetricks should always and only remain a hack for things that do not work at the moment. It shouldn't be considered a solution for end users. We shouldn't even require end users to know which runtime is needed by their apps, especially since it works out of the box in XP (which by default is what Wine tells the installers it is, btw).

Lastly (and this may be just me), I don't like having the real msvbvm50/60 on my system. I just want my apps. If I can have free alternatives then better.

If I had the programming skills for this I would probably scratch my itch. But having none, I do the next best thing and file a request in the remote hope that someone has a similar itch with necessary skills. I am by no means requiring those who are already working on other parts (and doing a good job too!) to work on my request instead of what they believe to be important to them.

I know that Wine has many more important bugs that need to be worked on, but that shouldn't be reason to prevent what I perceive to be a valid request. After all, it took me 3 years to finally decide to file this bug, because I respect the more important things that needed to be done.

http://bugs.winehq.org/show_bug.cgi?id=19816

--- Comment #9 from Bamm Gabriana [email protected] 2009-08-23 15:46:38 ---

OP, if you expect someone to implement all these garbage you are NUTZ!!!

I have no illusions that this will be fixed soon. That's reality. My request is not for all these garbage but specifically about MSVBVM60.

The other reality is that non-geek users just want their app to run. Alexander understands this, why can't you?

http://bugs.winehq.org/show_bug.cgi?id=19816

--- Comment #11 from Austin English [email protected] 2009-08-23 18:28:56 --- (In reply to comment #10)

You talking about implementing something that's not a part of an OS. What's worse, you talking about something that MS holds lots of patents and copyrights on. Ask any lawyer how feasible it is to re-implement MSVB.

They also hold patents on a lot of windows builtin functionality.

http://bugs.winehq.org/show_bug.cgi?id=19816

--- Comment #13 from Detlef Riekenberg [email protected] 2010-04-22 07:47:40 --- (In reply to comment #5)

Windows also ships msvbvm50, mfc40, mfc42, mfc71, msvcp50, msvcp60, msvcp70, msvcp71, msvcr70, mdac.

Is it ok to start accepting requests for those as well?

Wine has now builtins for more C/C++ runtime libraries: - msvcr70.dll (VS2002) - msvcr71.dll (VS2003) - msvcr80.dll (VS2005) - msvcr90.dll (VS2008) - msvcr100.dll (VS2010)

They are far from complete, but enough for many apps.

http://bugs.winehq.org/show_bug.cgi?id=19816

Dmitry Timoshkov [email protected] changed:

What |Removed |Added ---------------------------------------------------------------------------- Summary|Enhancement request: |Add implementation of |MSVBVM60 |MSVBVM60

http://bugs.winehq.org/show_bug.cgi?id=19816

fracting [email protected] changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]

http://bugs.winehq.org/show_bug.cgi?id=19816

Rex Tsai [email protected] changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]

http://bugs.winehq.org/show_bug.cgi?id=19816

Ken Sharp [email protected] changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]

http://bugs.winehq.org/show_bug.cgi?id=19816

Felix Yan [email protected] changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]

https://bugs.winehq.org/show_bug.cgi?id=19816

--- Comment #18 from Austin English [email protected] --- Still in 1.7.51.

https://bugs.winehq.org/show_bug.cgi?id=19816

Austin English [email protected] changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]

--- Comment #20 from Austin English [email protected] --- *** Bug 42448 has been marked as a duplicate of this bug. ***

https://bugs.winehq.org/show_bug.cgi?id=19816

[email protected] changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]

--- Comment #22 from [email protected] --- ComDlg32.OCX (winetricks comdlg32ocx) presumably falls under this category.

Not saying it should be a priority at all, but fwiw LOTS of industry software still uses this crap (MSVBVM60.dll, ComDlg32.OCX, etc). Microsoft has a solid foothold there, kept by these old APIs, & they're not going to surrender it for a while.

https://bugs.winehq.org/show_bug.cgi?id=19816

--- Comment #24 from Anastasius Focht [email protected] --- Hello folks,

for documentation the official Microsoft Support Statement for Visual Basic 6.0 on Windows:

https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-basic...

--- quote --- 64-Bit Windows

Visual Basic 6.0 runtime files are 32-bit. These files ship in 64-bit Windows Operating Systems referenced in the table below. 32-bit VB6 applications and components are supported in the WOW emulation environment only. 32-bit components must also be hosted in 32-bit application processes.

The Visual Basic 6.0 IDE has never been offered in a native 64-bit version, nor has the 32-bit IDE been supported on 64-bit Windows. VB6 development on 64-bit Windows or any native architecture other than 32-bit is not and will not be supported. Windows 10

Since the initial release of this support statement, the Windows 10 operating system has been released. This document has been updated to clarify Microsoft’s support for VB6 on Windows 10.

The VB6 runtime will ship and will be supported in Windows 10 for the lifetime of the OS. Visual Basic 6.0 runtime files continue to be 32-bit only, and all components must be hosted in 32-bit application processes. Developers can think of the support story for Windows 10 as being the same as it is for Windows 8.1. Windows 8.1

Since the initial release of this support statement, the Windows 8.1 operating system has been released. This document has been updated to clarify Microsoft’s support for VB6 on Windows 8.1.

The VB6 runtime will ship and will be supported in Windows 8.1 for the lifetime of the OS. Visual Basic 6.0 runtime files continue to be 32-bit only, and all components must be hosted in 32-bit application processes. Developers can think of the support story for Windows 8.1 as being the same as it is for Windows 7. Windows 7

Since the initial release of this support statement, the Windows 7 operating system has been released. This document has been updated to clarify Microsoft’s support for VB6 on Windows 7.

The VB6 runtime will ship and will be supported in Windows 7 for the lifetime of the OS. Visual Basic 6.0 runtime files continue to be 32-bit only, and all components must be hosted in 32-bit application processes. Windows Server 2016

Since the initial release of this support statement, the Windows Server 2016 operating system has been released. This document has been updated to clarify Microsoft’s support for VB6 on Windows Server 2016.

The VB6 runtime will ship and will be supported in Windows Server 2016 for the lifetime of the OS. Visual Basic 6.0 runtime files continue to be 32-bit only, and all components must be hosted in 32-bit application processes. Developers can think of the support story for Windows Server 2016 as being the same as it is for Windows Server 2012 R2. Windows Server 2012 R2

Since the initial release of this support statement, the Windows Server 2012 R2 operating system has been released. This document has been updated to clarify Microsoft’s support for VB6 on Windows Server 2012 R2.

The VB6 runtime will ship and will be supported in Windows Server 2012 R2 for the lifetime of the OS. Visual Basic 6.0 runtime files continue to be 32-bit only, and all components must be hosted in 32-bit application processes. Developers can think of the support story for Windows Server 2012 R2 as being the same as it is for Windows Server 2012. Windows Server 2012

Since the initial release of this support statement, the Windows Server 2012 operating system has been released. This document has been updated to clarify Microsoft’s support for VB6 on Windows Server 2012.

The VB6 runtime will ship and will be supported in Windows Server 2012 for the lifetime of the OS. Visual Basic 6.0 runtime files continue to be 32-bit only, and all components must be hosted in 32-bit application processes. Developers can think of the support story for Windows Server 2012 as being the same as it is for Windows Server 2008 R2. Windows Server 2008 R2

Since the initial release of this support statement, the Windows Server 2008 R2 operating system has been released. This document has been updated to clarify Microsoft’s support for VB6 on Windows Server 2008 R2.

The VB6 runtime will ship and will be supported in Windows Server 2008 R2 for the lifetime of the OS. Visual Basic 6.0 runtime files continue to be 32-bit only, and all components must be hosted in 32-bit application processes. Developers can think of the support story for Windows Server 2008 R2 as being the same as it is for Windows Server 2008. Windows Server 2008

Since the initial release of this support statement, the Windows Server 2008 operating system has been released. This document has been updated to clarify Microsoft’s support for VB6 on Windows Server 2008.

The VB6 runtime will ship and will be supported in Windows Server 2008 for the lifetime of the OS. Visual Basic 6.0 runtime files continue to be 32-bit only, and all components must be hosted in 32-bit application processes. --- quote ---

@alexchandel

--- quote --- ComDlg32.OCX (winetricks comdlg32ocx) presumably falls under this category. --- quote ---

No, that ActiveX control doesn't fall into same category according to the link.

--- quote --- Supported runtime files to distribute with your application

comct232.ocx msbind.dll msdbrptr.dll msstdfmt.dll comct332.ocx mscdrun.dll msflxgrd.ocx msstkprp.dll comctl32.ocx mschrt20.ocx mshflxgd.ocx mswcrun.dll comdlg32.ocx mscomct2.ocx mshtmpgr.dll mswinsck.ocx dbadapt.dll mscomctl.ocx msinet.ocx picclp32.ocx dbgrid32.ocx mscomm32.ocx msmapi32.ocx richtx32.ocx dblist32.ocx msdatgrd.ocx msmask32.ocx sysinfo.ocx mci32.ocx msdatlst.ocx msrdc20.ocx tabctl32.ocx msadodc.ocx msdatrep.ocx msrdo20.dll --- quote ---

Regards

https://bugs.winehq.org/show_bug.cgi?id=19816

Anya [email protected] changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]

https://bugs.winehq.org/show_bug.cgi?id=19816

Zebediah Figura [email protected] changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]

--- Comment #27 from Zebediah Figura [email protected] --- (In reply to Bamm Gabriana from comment #26)

Would this project be useful to lead to a possible implementtion someday?

https://github.com/cocus/openmsvbvm

Probably not. They appear to have used methods that aren't considered safe for Wine development:

"API Monitor from ROHITAB was also used to check some runtime values and function calls from the original MSVBVM60.dll. Some reverse-engineering sites such as the ones listed in http://sandsprite.com/vb-reversing/"

There's also the problem that there's no actual license attached (although that could probably be resolved by contacting the author and asking for an explicit license).

https://bugs.winehq.org/show_bug.cgi?id=19816

Bartosz [email protected] changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected]

https://bugs.winehq.org/show_bug.cgi?id=19816

soredake [email protected] changed:

What |Removed |Added ---------------------------------------------------------------------------- CC|broaden_acid002@simplelogin | |.com |