So VB6 still runs fine under Windows 10. When will it no longer run under Windows?
Thank you
Punchy
(I did search but could fine no post on this.)
Printable View
So VB6 still runs fine under Windows 10. When will it no longer run under Windows?
Thank you
Punchy
(I did search but could fine no post on this.)
It will continue until Microsoft breaks it. So far they haven't seen fit to, and to avoid losing more customers they've actually made efforts here and there so that it keeps working.
Microsoft sayQuote:
Originally Posted by Punchy
So VB6 programming on Windows 10 is currently supported until October 14, 2025Quote:
Microsoft is committed to support existing Visual Basic 6.0 applications running on Windows Vista, Windows Server 2008 including R2, Windows 7, Windows Server 2012, Windows Server 2012 R2, Windows 8.x, and Windows 10.
...the core Visual Basic 6.0 runtime will be supported for the full lifetime of Windows operating system with which it shipped for serious regressions and critical security issues.
https://support.microsoft.com/en-us/...0#Visual Basic
I think windows XP is the best platform for Vb6. So we can use VirtualBox with windows Xp and vb6...and now is not Microsoft problem but Oracle's Virtual Box;;
(And not only this virtual machine...there are other out there...)
But for newer OS is good to use Net platform. I stuck with vb6 and in my universe of code so a moving to an other space is difficult like the spaces travels...you can plan only...and in one second you face the reality...you can't do it.
Windows XP :confused:
Windows XP is no longer supported and should not be used where there is any Internet connection at all, which includes most VM usage as well. It is just too hazardous now that no new security patches are being made, and the bad guys know this and target it specifically now.
For that matter there are tons of things that don't come with XP that VB6 programs can use in later, still supported versions of Windows. Some of them once had redist packages so the features could be back-ported to XP but Microsoft has already pulled most of the downloads from their sites.
So XP is no longer a viable development platform any more than Windows 95. Maybe less so since it is such a malware target today.
I'm not sure that's a completely accurate statement. VB6 development I don't think is guaranteed at all. As it is, it takes some effort to get VB6 IDE to install on newer platforms. What WILL be supported is the VB6 RUNTIME... which means VB6-based applications will still continue to run for the foreseeable future... but given that the IDE isn't supported, there's no guarantee that it will continue to be able to be installable and used for development. There may come a time when the runtimes are still being shipped but for what ever reason the IDE/compiler no longer works or can even be installed.Quote:
Originally Posted by sten2005
-tg
Good point.
VB6 also works great under W2K ;)
I have VMs setup to run W2K and XP and have VB6 installed on both of them.
Lack on updates is a non issue at this point and it is simple enough to isolate a VM from the internet if you are worried about the bad guys.
Seems odd to hear someone say that XP should not be used for development since it is not supported by MS any longer while also talking about VB6 which has been unsupported longer than XP has.
Yes there are new features in the later OS editions that can be used [assuming you don't need the program to run under XP] but this does not prevent you from doing development under XP and being able to target XP as well as the newer OS editions.
I haven't loaded windows 10 yet so I don't really know what to expect as far as getting a VB6 environment to work there.
I really haven't had any significant problems with the VB6 IDE in Windows 7, you need to run it as administrator, and you need to disable visual themes and set the compatibility for XP, but it has worked just fine for me for a couple years now.
Same here. I'm happily running the IDE on Windows 10 without any trouble, and those same settings solve most IDE problems. (I'd also recommend disabling DPI scaling, if your monitor is high-DPI.)Quote:
Originally Posted by interactii
Edit: actually, reading your comment more closely, I don't understand the need to set a compatibility mode. I'm curious why you use that setting?
Completely agree. XP offers no benefit for VB developers, and it adds a ton of negatives. Unless you run an XP PC/VM completely network- and peripheral-isolated (including USB drives), you should expect to be compromised eventually.Quote:
Originally Posted by dilettante
Microsoft has made it easy to run the classic VB IDE on modern versions of Windows. Developers should take advantage of this.
Microsoft do say that they test the Visual Basic 6 IDE to "mitigate compatibility issues". Whether that is worth more or less than Microsoft's guarantee that the VB6 Runtime will be supported for the lifetime of Windows 10 remains to be seen.
To be fair to Microsoft, both the VB6 Runtime and IDE have continued to work on Windows 7, 8.x and now on Windows 10.
Gibra, who posts in this forum, has a utility to help install the VB6 IDE on Windows 10 and earlier.
http://nuke.vbcorner.net/Tools/Visua...S/Default.aspx
I've not found any problems with the VB6 IDE on Windows 10, beyond those known in earlier versions of Windows (and touched on in this thread) - compatibility setting, Run as Administrator, DPI scaling, etc.
You shouldn't run VB6 as administrator under Windows 10.
I have several isssues.
Ex, if you try to access outlook, it won't be available, as it will run outlook in, an admin mode, mode and it is not by default.
Some API won't work too.
I have tested several configurations, and the best is "compatibility Vista SP2" and no administrator rights
This config solves all issues
Vista SP2 is the best compatibility setting.
XP SP3 is OK too, but has the "desktop composition" slowness.
I usually have Reduced Color Mode set to 16 bit (65536), and Disable Display Scaling checked.
I've not had any issues running as Administrator, but I don't do much with Outlook.
What API's don't work ? Do you mean they don't work only when you run as Administrator ?
What service pack have you installed ?
Microsoft keeps supporting VB6 because its core customers are businesses, and many businesses still depend on programs written in VB and have no intention on upgrading, because as people here know, there's absolutely nothing wrong with VB and VB.NET is a whole new ballgame. It will probably be decades more before VB support is dropped. MS never commits to it for future versions, but they eventually announce it. Too many business customers would be upset, and MS actually cares about them.
IMO, there's not even anything wrong with VB6 for new development. Getting your program to look like a modern app using modern features takes a fair amount of work, but when you make that effort your program can have all the bells and whistles of a .NET program with none of the .NET Framework headaches. Take a look at this program-- looks just as nice as anything made with a more modern language/framework, and nobody looking at it is going to think it's VB, which they associate with looking like Win95. But everything there is native VB enhanced with or created entirely from API.
Regarding the IDE... it's not quite the end of the world if that breaks. Developers won't have a problem using it in a VM, and the users aren't effected as long as the runtime works.
Don't worry too much. VB library is not so large, just less than 15MB, VB6 has the same age with VS6, If VB6 can't be supported by future OS, that means MS doesn't support 32 bit applications, it won't happen in 20 years!
And we can always pray MS makes VB7, an actual successor to VB. It's not that crazy an idea, they've already made a lot of upgrades and 64-bit support with VBA. It's ridiculous they still work on VBA but not VB, and I guarantee it's only because there's too many people using VBA to switch THAT to .NET, imagine the anger.
I am running VB IDE in windows 7, without compatibility set to XP SP3 - runs just fine. Altought i am running IDE manifested.Quote:
Originally Posted by interactii
Not sure why interactii set compatibility to XP SP3.:confused:Quote:
Originally Posted by Tech99
Actually there is one quirk which comes to mind - VB IDE color chooser (palette) does not work, at least not when IDE is manifested. It displays blank white. Likewise in Windows 7 there is a bug in operating system color chooser - you can test it with MSPaint for example. Try to input Red, Green or Blue values directly, to input boxes there - it accepts only two valued characters ie. you can input 99, but not 100 and above values.
Me too.Quote:
Originally Posted by Jonney
On Vista/32 Win7/32 & 64 , all with Aero , checked only the admin rights. With no problem at all.
Here is a sample of the problem I had running the VB6 IDE e running elevated but Outlook has been launched un-elevated (as it normally is). The exe will normally be run un-elevated of course.
If you never intend to run the exe elevated this is not a an issue.
Set oOutlook = GetObject("", "Outlook.application")
It is just a security in WIndows 10.
I don't know if the samie thing could happens with other applications
For testing puposes run *Outlook* as administrator and above code works just fine.Quote:
Originally Posted by Thierry69
cheers,
</wqw>
On my computer, outlook is not running as administrator, ad so, I had such problem
I am not that good with VB, or not to say that I don't know nothing :)
but I am concerned to read these kind of questions, I don't want VB to die, at least not yet :cool:
Running the VB6-IDE with Admin-rights is important to make it behave properly whilstQuote:
Originally Posted by Thierry69
developing (or loading) "ActiveX-stuff" (Dlls and OCXes).
I have two links on my Desktop for that reason:
- the one I use most, is the one which starts the VB6-IDE in Admin-Mode
- and to test out Drag&Drop (and other Cross-Process-stuff) I have a second shortcut which starts VB6 "un-elevated".
But the general recommendation for most (inexperienced) Users should be, to run the VB6-IDE elevated
(to avoid the whole class of "unsufficient Registry-Rights" issues, the VB-IDE might encounter whilst
interacting with COM-components).
Olaf
Can you explain more? Running in VB IDE, drap-drop is enable?Quote:
Originally Posted by Schmidt
My2Cents:
As long as the VB5/6 community stays alive and well and has significant interest I believe Microsoft will continue to support it.
Unfortunately, a lot of colleges and community colleges follow Microsoft, and I believe have shifted to teaching NET.
This has the effect of eliminating the pool of new users as people tend to program in what they first learned or are more comfortable with.
OLE-Drag&Drop is designed and capable to work "cross-process".Quote:
Originally Posted by Jonney
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
Quote:
Originally Posted by Tech99
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.
Do you know what is the link?Quote:
Originally Posted by Schmidt
I am always puzzle with the drag-drop when running xxx.vbp. I have to compiled into EXE for testing drag-drop.
So dragging files with the native VB stuff to Explorer doesn't work if your program isn't in admin mode?Quote:
Originally Posted by Schmidt
If so chalk up a victory for doing things the hard way, because SHDoDragDrop works whether I'm running elevated or not.
No, I was talking about VB6.exe (the IDE), not about "ones program" - and also not aboutQuote:
Originally Posted by fafalone
Exporer.exe (or Shell-stuff) specifically (since there could be other Ole-Drag-Operations -
not involving the Shell or the FileSystem - to other Processes and vice versa).
When "your program isn't in admin mode" (as you wrote above, and as Programs usually are and will be run) -
then things usually work as they should (with any Cross-Process-Ole-stuff, because the Process'
user-credentials will match).
Here again, what I wanted to say:
- most Users run their VB6-IDE elevated on Vista+ (to ensure the necessary Registry-Rights for VB6.exe, to work properly with COM)
- this works well enough for 90% of all development-scenarios
- only in the relative rare cases you want to test out OLE-Cross-Process-Operations from *within that elevated VB-IDE* (and not from your compiled Program)...
- ...you can fall back on doubleclicking a VB6.exe-Link on your Desktop, which starts up a "normal, non-elevated IDE-Session"
In your reply you seem to suggest, that such DoubleClicking on a Link on your Desktop is "doing things the hard way",
which is hard to understand.
Olaf
I have created two extra-copies of VB6.exe in my \VB98\ folder (with differing names):Quote:
Originally Posted by Jonney
- VB6_non_manifested.exe
- VB6_non_adminmode.exe
For these two Executables I've created Links on my Desktop.
My normal VB6.exe (the one which is configured to start together when doubleclicking *.vbp and *.vbg Files)
is set to "Run as Admin" - and does already contain the same Manifest-resource, I will later also apply to my compiled Apps.
When I want to test Drag&Drop, or other Cross-Process-Automation, I will either start the IDE
over my Desktop-Link to "VB6_non_adminmode.exe" (and load the *.vbp in question from within the IDE),
or I will drag&drop the *.vbp in question on that same Desktop-Link, to load the *.vbp directly
(together with that non-elevated IDE-instance).
Olaf
Windows 7, 8.x and 10 Pro (build 10240):Quote:
Originally Posted by JackB
Visual Basic 6.0 Ee + MSDN Library + SP6 (installed from Visual Studio 6.0 Enterprise edition)
The only VB6.EXE property I've checked is: Disable Desktop Composition
- I don't Run As Administrator,
- I don't set Compatibility Mode
I run VB6 IDE with no problems :)
:wave:
That statement could actually be misunderstood by people who accomplished and runQuote:
Originally Posted by gibra
a working VB6-installation on Vista up to Win10, but didn't use your Installer to do so...
A clear statement from you, what those people would have to do in *addition*
(on their "normal" VB6-installation), to be able to safely run the IDE non-elevated
would be nice, to not mislead them into thinking that this switch is not necessary.
Olaf
I thought you were saying there was a scenario where dragging files from a VB program to Explorer would fail, that scenario related to whether the program/IDE was run in admin mode or not. This is normally accomplished with basic VB stuff, and the "hard way" I was talking about, SHDoDragDrop, is an API that uses another, undocumented API, SHCreateFileDataObject, and several COM interfaces- it's most definitely the hard way of dragging to Explorer (not the hardEST, but still harder than normal), but the point was that this works regardless of whether the IDE is running as admin or not, or whether the compiled program runs as admin or not.Quote:
Originally Posted by Schmidt
The issue is complex because it involves many factors that are not always easily understood by a developer that does not mean these things.Quote:
Originally Posted by Schmidt
Especially when 'transmitted' via web, they may be even less clear.
For a correct installation, also require to edit manuallly some files. It is not so easy to explain, and even less to make it clear. There is a study, behind all this.
There are many 'guides' in the web that indicate how.
More or less, these guides give correct information, but these indications were valid at that time.
For example, since its release Windows 10 TP, I already have done three updates to my wizard (the latest 4.3 version just yesterday).
Unfortunately MS likes to change the rules: from version to version, from build to build, so the problem is not 'how to' but became 'how do IF ...'
The IF is for:
- Windows version
- Version of VB: From Visual Studio 6.0 or from Visual Basic 6.0 distribution ?
- Edition of VB: Professional or Enterprise ?
The combinations are different, each with different problems!
Moreover, not all distributions of VS/VB seem to be exactly alike, can also be different from the localized language.
For example, on some distributions, the MSDN Library CD folders structure of Italian language is different of English language.
In addition, the Retail version of Visual Studio is different from the MSDN Subscription version:
IE4 folder doesn't exists in Subscription version, so MSJAVA.DLL doesn't need to be copied con C:\Windows (setup run correctly without it).
As you can see, the problems are many and different.
It 'easy to understand that explain all this in a comprehensive manner requires writing a guide long and complex, and here we return to the starting point: those with little or insufficient knowledge of these issues will eventually make just a mess and will be disappointed.
My VS6I Wizard tries to solve all these problems in an automatic and transparent to the user.
When I thought of designing my VS6 Installer wizard, I did it because I was tired (whenever I had to re-install Windows on my PC) than reading a guide (found on the web) to manually change the setup of my Visual Studio 6.0 Enterprise Edition (ITA), the only tool I had created for my personal use.
Next, seeing that many, like me, had increasingly complex problems in installing Visual Basic 6.0 so I decided to make the wizard public (and free), for others to solve the problems that I had to face.
Experts do not need my tools, they already know how to do.
It is the less experienced who find themselves in difficulty, I hope that my tool could be helpful, and, given the number of downloads (over 49.000), it seems to be appreciated.
:wave:
I hear you, but was talking specifically only about the problem of the "run as Admin"-necessityQuote:
Originally Posted by gibra
after "normal installs" (which for most users are not a larger problem). This setting seems to be
required for the VB6-IDE, to behave properly in COM-compiling, COM-typelib-reading/registering
and OutOfProcess-COM-Debugging-scenarios (e.g. when working across several running IDE-Instances).
For those scenarios the "run as Admin"-setting is needed (so far ... and you claimed that
your installer makes this switch unnecessary).
Well, I certainly do *not* know exactly (aside from a guess, which would require experimentingQuote:
Originally Posted by gibra
I don't want to invest time into currently, because "running as Admin" is quite "cheap to do" -
and works well enough so far, for most Users).
What I was hoping for, was some explanation from your end, which only relates to the topic
of the "run as Admin"-switch (which is a universal problem, not related to "Professional- or
Enterprise-versions or to "System-versions").
The problem is not related to the dozens of other small problems you mentioned, which crop
up with different VB6-Setup-packages, and different languages on different systems.
So, why not give us at least a hint here, what one has to do to avoid that "run as Admin" switch?
My guesses are that you (whilst running from your elevated Setup) will ensure that:
- the VB6-IDE-related Folders will get proper access-rights set-up (to avoid virtualization)
- certain registry-hives will end up with proper rights, set-up by your installer, to allow VB6.exe access to them even when running un-elevated
And if my guesses are right, then this is not a problem which "differs across VB6-Installation-CDs",
but a universal one (which one could possibly write a simple VBScript - or *.reg-File for).
Could you at least confirm - or deny my above guesses?
Or is there more (when we only talk about the "run as Admin"-necessity)?
Olaf
The fact is that the issue is not so clear and simple.
There isn't a something to say: do so and doesn't have to use Run As ...
If you want to understand with an example, analyze the differences on my two videos:
The 1st video is in English: http://www.youtube.com/watch?v=1tkTb6AYlAg
install Visual Basic 6.0 Enterprise (version of MSDN Subscription)
After installation (minute 8:00 of the video), when I start VB6, appears an error Automation. Then I show that by setting Run As Admin error appears (but the UAC always requires confirmation).
Going forward in the video, you see that I deactivate the Run As Admin, and the error no longer occurs.
Also, to avoid flicker Desktop Composition for Windows 10, I have to set the Compatibility Mode on Vista SP2.
There is a logical explanation for all this? If there is, I do not know.
I can only think that it happened in the registry 'something' that solved the problem.
The 2nd video is in Italian: https://www.youtube.com/watch?v=pF5oyvZ_N6Y
install Visual Studio 6.0 Enterprise (retail version)
Always per minute 8:00 you'll see that VB6 will run with no error, and do not even need to set the compatibility on Vista SP2.
Is there a reason for this difference? I don't know.
The only thing I can think is that the setups distributed by Microsoft are not all equal.
And some updates may change the rules, also.
I.e. A curiosity of MSJAVA.DLL:
1. The SETUP of VB Enterprise ENG (MSDN Subscription) does not require the presence of MSJAVA.DLL
2. In Windows 10 pre-release (TP) the MSJAVA.DLL could be zero length.
3. In Windows 10 (build 10240) the MSJAVA.DLL must be the original one
Again: is there a logical explanation for all this? If there is, I do not know.
:wave:
So, I guess I'm correct with my assumption, that your elevated running Setup-Process willQuote:
Originally Posted by gibra
- not apply any special rights to certain Registry-Hives
- and will also not apply lowered Access-Rights to the Root-Folder of a VB6-installation
In this case (as your video shows quite clearly) - your setup-process did nothing to solve the
necessity to run the IDE "as Admin".
Your assumption (or suggestion), that after using your Installer, the "running as Admin" setting
would not be necessary anymore, is a wrong one.
The same problem (as it became apparent at the first start of your fresh installed IDE in your vid at 8:00),
still applies - and is just "waiting for the next time you run into it" (which is for example, when you develop,
debug or compile ActiveX-Dlls, or ActiveX-Exes - depending on their "Project-Compatibility or BinComp-Settings" -
or when you use complex ProjectGroups - or try to run two isolated IDE-Instances in a Cross-Process-Debugging-
scenario.
I think it was important, that we established that now for the other readers of this thread:
The "Run as Admin setting is needed!" (when you use the VB6-IDE in more complex scenarios).
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).
So it's a "less capable-mode" (COM-wise) - but one which still can be useful, e.g. when you want
to test stuff as the already mentioned Ole-Drag&Drop for example.
Olaf
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.Quote:
Originally Posted by fafalone
Honestly I do not understand the meaning of what you write.Quote:
Originally Posted by Schmidt
VB6 works without any problems. Always.
Nope, that simply cannot be, when you consider the following:Quote:
Originally Posted by gibra
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
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.Quote:
Originally Posted by Tech99
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.Quote:
Originally Posted by fafalone
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.
Few talent guy worked out a packed version of VB6.EXE to support Drag-Drop on VBIDE (Administrator Mode):Quote:
Originally Posted by Schmidt
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
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? :PQuote:
Originally Posted by dilettante
...
Still toying with the idea of putting it on W10, is there a recommended guide for that somewhere?