When will VB6 be Unable to Run Under Windows

Re: When will VB6 be Unable to Run Under Windows

Quote:

Originally Posted by fafalone

You're inputting them as hex right? &HxxBBGGRR, you can input the full range of 0-255 because 255 is FF. Not sure what you're talking about with the color picker dialog, MSPaint lets me enter 3-digit decimal numbers no problem.

No not in hex, just plain decimal values. Color chooser accepts only numeric digits. Definitely in W7/64 Finnish language version, color chooser has a bug in it.

Re: When will VB6 be Unable to Run Under Windows

Quote:

Originally Posted by Schmidt

The IDE will work without that Admin-setting, when the Project you will start-up will use only
"already existing and stable COM-Interfaces which already have proper entries in the registry"
(e.g. those of the built-in OCX-stack - and typelibs which ship with VB6).

Honestly I do not understand the meaning of what you write.
VB6 works without any problems. Always.

Re: When will VB6 be Unable to Run Under Windows

Quote:

Originally Posted by gibra

Honestly I do not understand the meaning of what you write.
VB6 works without any problems. Always.

Nope, that simply cannot be, when you consider the following:

1) Why do you think it is necessary, to run e.g. regsvr32.exe elevated (to make it succeed)?
Right, it wants to write to registry-hives which require "Admin-access-rights".

2) Now, keep in mind that the VB6-IDE supports a whole lot of development-modes, as well
. as project-types, where it will need the very same access-rights, to be able to write to
. those (COM-related) registry-hives itself.

I hope you see as clearly as I do, that the point #2 above is not going conform with your:
- "works without any problems. Always."
statement.

Your statement denies the fact, that the VB6-IDE is *dependent* on full access-rights
to certain areas of the registry (to work properly and behave as expected in scenarios,
where it has to register and unregister COM-stuff - sometimes even temporarily).

Olaf

Re: When will VB6 be Unable to Run Under Windows

Quote:

Originally Posted by Tech99

No not in hex, just plain decimal values. Color chooser accepts only numeric digits. Definitely in W7/64 Finnish language version, color chooser has a bug in it.

There's two different things; the various 'Color' entries in the Properties window for VB stuff, which you can manually enter the string in hex (&HxxBBGGRR), then the color chooser common dialog, something entirely different. That sounds like a pretty big bug to be unpatched.. it's fine on Win7 x64 US.

Re: When will VB6 be Unable to Run Under Windows

Quote:

Originally Posted by fafalone

There's two different things; the various 'Color' entries in the Properties window for VB stuff, which you can manually enter the string in hex (&HxxBBGGRR), then the color chooser common dialog, something entirely different. That sounds like a pretty big bug to be unpatched.. it's fine on Win7 x64 US.

I reported this color chooser common dialog bug to Microsoft, as early as beginning of the 2010. Correction to the problem is still 'non existing' - it seems that MS is not interested this.

Color properties in VB IDE works ok, but color chooser under color properties/combobox drop down and palette tab displays blank white in manifested IDE.

Re: When will VB6 be Unable to Run Under Windows

Quote:

Originally Posted by Schmidt

OLE-Drag&Drop is designed and capable to work "cross-process".
And when the two Processes (e.g. whilst dragging something out of a running *.vbp,
hosted within VB6.exe -> onto Explorer.exe), then those two processes will work
together in the Ole-Drag&Drop Operation only, when their "User-Credentials they
were started with" do match.

And when VB6.exe runs with Admin-credentials (elevated) - but Explorer.exe does
run under the "normal User-account", then the Ole-Operation will fail - or just
"doesn't react" (not throwing the expected Events).

Same thing (sometimes) with 'Ole-Automation' (e.g. working cross-process against
the Excel-, Outlook- or Word-ObjectModels from an elevated running VB6.exe).

So, to test these cases from within a "running *.vbp" (from within the VB6.exe-Hostprocess)
you should start VB6.exe (just this time) - in non-elevated mode (with normal User-credentials).

But this came up quite often over the last months (and perhaps years) - a forum-search
should bring those threads up.

Olaf

Few talent guy worked out a packed version of VB6.EXE to support Drag-Drop on VBIDE (Administrator Mode):
http://bbs.csersoft.net/thread-33-1-1.html

Quote:

UserFunc1[RVA:00199F36]:
00599F36 /$ FF35 18B05900 push dword ptr [0x59B018] ; /hWnd = NULL
00599F3C |. FF15 8C164000 call dword ptr [<&USER32.GetWindowDC>>; \GetWindowDC
00599F42 |. 50 push eax
00599F43 |. 6A 00 push 0x0
00599F45 |. 6A 00 push 0x0
00599F47 |. 6A 00 push 0x0
00599F49 |. 6A 00 push 0x0
00599F4B |. 54 push esp ; /pRect
00599F4C |. FF35 18B05900 push dword ptr [0x59B018] ; |hWnd = NULL
00599F52 |. FF15 40164000 call dword ptr [<&USER32.GetWindowRec>; \GetWindowRect
00599F58 |. 5A pop edx
00599F59 |. 59 pop ecx
00599F5A |. 83C4 08 add esp, 0x8
00599F5D |. 58 pop eax
00599F5E |. 50 push eax
00599F5F |. 6A 00 push 0x0 ; /pPrevious = NULL
00599F61 |. 51 push ecx ; |Y => 0x0
00599F62 |. 52 push edx ; |X => 0x0
00599F63 |. 50 push eax ; |hDC => NULL
00599F64 |. FF15 301A4000 call dword ptr [<&GDI32.SetWindowOrgE>; \SetWindowOrgEx
00599F6A |. 58 pop eax
00599F6B \. C2 0400 retn 0x4

UserFunc2[RVA:00199F7C]:
00599F7C /$ FF7424 08 push dword ptr [esp+0x8] ; /hDC
00599F80 |. FF35 18B05900 push dword ptr [0x59B018] ; |hWnd = NULL
00599F86 |. FF15 08194000 call dword ptr [<&USER32.ReleaseDC>] ; \ReleaseDC
00599F8C \. C2 0800 retn 0x8

patch1[RVA:000D880A]:
org:
004D8800 . 56 push esi
004D8801 . E8 00B2F2FF call 00403A06
004D8806 . FF75 08 push dword ptr [ebp+0x8] ; /hDC
004D8809 . 53 push ebx ; |hWnd
004D880A . FF15 08194000 call dword ptr [<&USER32.ReleaseDC>] ; \ReleaseDC
004D8810 .^ E9 D876FBFF jmp 0048FEED
new:
004D880A . E8 6D170C00 call 00599F7C ; UserFunc2
004D880F . 90 nop

patch2[RVA:000F69FA]:
org:
004F69F0 /$ 55 push ebp
004F69F1 |. 8BEC mov ebp, esp
004F69F3 |. 83EC 34 sub esp, 0x34
004F69F6 |. 57 push edi
004F69F7 |. 33FF xor edi, edi
004F69F9 |. 57 push edi ; /hWnd => NULL
004F69FA |. FF15 B8154000 call dword ptr [<&USER32.GetDC>] ; \GetDC
004F6A00 |. 3BC7 cmp eax, edi
new:
004F69FA |. E8 37350A00 call 00599F36 ; UserFunc1
004F69FF |. 90 nop

patch3[RVA:000F6C67]:
org:
004F6C67 |. FF15 301A4000 call dword ptr [<&GDI32.SetWindowOrgE>; \SetWindowOrgEx
new:
004F6C67 |. FF15 68194000 call dword ptr [<&GDI32.OffsetWindowO>; \OffsetWindowOrgEx

patch4[RVA:00129234]:
org:
00529230 |> FF75 0C push dword ptr [ebp+0xC] ; /hDC; Default case of switch 00529221
00529233 |. |53 push ebx ; |hWnd
00529234 |. |FF15 08194000 call dword ptr [<&USER32.ReleaseDC>] ; \ReleaseDC
new:
00529230 |> FF75 0C push dword ptr [ebp+0xC] ; Default case of switch 00529221
00529233 |. |53 push ebx
00529234 |. |E8 430D0700 call 00599F7C ; UserFunc2
00529239 |. |90 nop

patch5[RVA:00189C4D]:
org:
00589C4C |. 57 push edi ; /hWnd => NULL
00589C4D |. FF15 B8154000 call dword ptr [<&USER32.GetDC>] ; \GetDC
new:
00589C4C |. 57 push edi
00589C4D |. E8 E4020100 call 00599F36 ; UserFunc1
00589C52 |. 90 nop

patch6[RVA:00189D5B]:
org:
00589D4E |. 57 push edi ; /pPrevious
00589D4F |. F7D8 neg eax ; |
00589D51 |. 50 push eax ; |Y
00589D52 |. 8B45 C4 mov eax, dword ptr [ebp-0x3C] ; |
00589D55 |. F7D8 neg eax ; |
00589D57 |. 50 push eax ; |X
00589D58 |. FF75 FC push dword ptr [ebp-0x4] ; |hDC
00589D5B |. FF15 301A4000 call dword ptr [<&GDI32.SetWindowOrgE>; \SetWindowOrgEx
new:
00589D4E |. 57 push edi ; /pPoint
00589D4F |. F7D8 neg eax ; |
00589D51 |. 50 push eax ; |YOffset
00589D52 |. 8B45 C4 mov eax, dword ptr [ebp-0x3C] ; |
00589D55 |. F7D8 neg eax ; |
00589D57 |. 50 push eax ; |XOffset
00589D58 |. FF75 FC push dword ptr [ebp-0x4] ; |hDC
00589D5B |. FF15 68194000 call dword ptr [<&GDI32.OffsetWindowO>; \OffsetWindowOrgEx

patch7[RVA:00189D8B]:
org:
00589D87 |> \FF75 FC push dword ptr [ebp-0x4] ; /hDC
00589D8A |. 57 push edi ; |hWnd
00589D8B |. FF15 08194000 call dword ptr [<&USER32.ReleaseDC>] ; \ReleaseDC
new:
00589D87 |> \FF75 FC push dword ptr [ebp-0x4]
00589D8A |. 57 push edi
00589D8B |. E8 EC010100 call 00599F7C ; UserFunc2
00589D90 |. 90 nop

patch8[RVA:0018AB1C]:
org:
0058AB1B |. 57 push edi ; /hWnd => NULL
0058AB1C |. FF15 B8154000 call dword ptr [<&USER32.GetDC>] ; \GetDC
new:
0058AB1B |. 57 push edi
0058AB1C |. E8 15F40000 call 00599F36 ; UserFunc1
0058AB21 |. 90 nop

patch9[RVA:0018AB6A]:
org:
0058AB5F |. 57 push edi ; /pPrevious => NULL
0058AB60 |. F7D8 neg eax ; |
0058AB62 |. 50 push eax ; |Y
0058AB63 |. 8B45 F0 mov eax, dword ptr [ebp-0x10] ; |
0058AB66 |. F7D8 neg eax ; |
0058AB68 |. 50 push eax ; |X
0058AB69 |. 53 push ebx ; |hDC
0058AB6A |. FF15 301A4000 call dword ptr [<&GDI32.SetWindowOrgE>; \SetWindowOrgEx
new:
0058AB5F |. 57 push edi ; /pPoint
0058AB60 |. F7D8 neg eax ; |
0058AB62 |. 50 push eax ; |YOffset
0058AB63 |. 8B45 F0 mov eax, dword ptr [ebp-0x10] ; |
0058AB66 |. F7D8 neg eax ; |
0058AB68 |. 50 push eax ; |XOffset
0058AB69 |. 53 push ebx ; |hDC
0058AB6A |. FF15 68194000 call dword ptr [<&GDI32.OffsetWindowO>; \OffsetWindowOrgEx

patch10[RVA:0018AB89]:
org:
0058AB87 |. 53 push ebx ; /hDC
0058AB88 |. 57 push edi ; |hWnd
0058AB89 |. FF15 08194000 call dword ptr [<&USER32.ReleaseDC>] ; \ReleaseDC
new:
0058AB87 |. 53 push ebx
0058AB88 |. 57 push edi
0058AB89 |. E8 EEF30000 call 00599F7C ; UserFunc2
0058AB8E |. 90 nop

Re: When will VB6 be Unable to Run Under Windows

Quote:

Originally Posted by dilettante

Windows XP :confused:
Windows XP is no longer supported...
So XP is no longer a viable development platform any more than Windows 95.

Yes, they said they have withdrawn support for those. But, in W10 [1607], right click an executable and find under the Compatibility Tab that the program can be run in compatibility mode for as far back as Windows 95! Pseudo-Support? :P
...
Still toying with the idea of putting it on W10, is there a recommended guide for that somewhere?