I play on a 4k monitor. The screen glitches when I try to select the Diablo (classic) option in the Gog launcher.

It also glitches when I try to play it from the .exe file in the Gog folder.

The settings on the Gog laucher do not alter anything with the classic version I'm finding. Changing those settings does not get classic out of full screen mode.

Do I need to do an extra step or is there something I'm missing?

When I start classic, my monitor shifts to full screen, but the game image is jagged, green, and completely un-intelligible.

Thanks for any help.

The Diablo Gog ver works perfectly fine though in full screen. I just wanted to see if I could play classic on B.net.

"Classic" is the original game, exactly as it was made without any changes. It doesn't support windowed mode and current versions of windows have issues with the graphics mode that it uses (resulting in wrong colors).

Correct... or rather, "correct-ish."

It's not WINDOWS, per-se, that causes the majority of issues we see, but rather the fact that there is no longer "DirectDraw" as part of DirectX. Microsoft removed it, and then put in an emulation mode into Direct3D which is buggy. So, it's technically not the OS, but rather DirectX, which is at the root of the issues.

A number of people have come up with "replacement Directdraw" versions which can be dropped into game directories and allow older games to run on current versions of Windows, typically as a single DLL file. Note, this is generally not the original DirectX DLL file, but a replacement or wrapper someone else wrote. These often work for only a small subset of all programs, but when you find the right one for your program, it will work perfectly fine in any version of Windows.

In other words, the issue is not with "being designed to run on obsolete systems," but rather, Microsoft's ridiculous choice to remove this feature from DirectX, and to provide only the most basic, and buggy, of replacements. They literally claimed that "no one needs to render 2D anymore." And their "hack" basically creates a 3D surface and draws onto that... but isn't even compatible with their own original API. Which is remarkable, considering that they, and ONLY they, have full access to their own source code.

So, the idea that they "can't do this" is simply a lie. People without access to MS source code have done it repeatedly. Microsoft ought to be able to implement this far, far more easily.

классику можно запустить в окне с помощью DxWnd
Вот видео: https://youtu.be/QQ71nq10vO8

Так же можно версию ГОГ заставить играть через battle.net
Вот ссылка: https://www.gog.com/forum/diablo/run_diablo_1_gog_no_classic_in_window_and_play_on_battlenet

No, in this case it really is the windows GUI code.
From XP onwards the OS stopped properly supporting palettes for individual apps, instead all apps share the same palette. This has nothing to do with directdraw/directx; the main app that uses a palette is explorer, which uses neither of those subsystems.
Every time an app makes a change to a palette entry it affects all other apps using the palette as well, which is why original Diablo ends up displaying psychedelic colours.
There was a special flag added to directdraw to emulate palette rendering for compatibility but Diablo was never updated to use it.

Then apparently EVERY SINGLE GAME ever written using "DirectDraw" was also "never updated to use it?"

Because I have encountered this same issue on pretty much EVERY DirectDraw application I have.

Here's the thing. It's still a MICROSOFT issue, and it's still part of DirectDraw where the problem arises.

And I know that I can run different "workspaces" on my current machine with different color depths, etc... so I'm a bit dubious about the claim that there's only a single "pallet."

Can you support that explanation with a bit more detail? I'd be interested in seeing more about what you're telling me.

Only apps that use 8-bit/256 colours use palettes. Most regular apps use 32-bit colour only.

A LOT of early popular directdraw games automatically have palette emulation enabled because MS whitelisted them in their compatibility database, but that relies on the executable matching the name and checksum that they recorded.

Of course. I know that. I also know that INTERNAL use of pallets does not necessarily translate to what the rendering system uses. I can run a program which, internally, does 16-colors (not 16-bit, but 16 total), but renders (properly) on a 32-bit-color-depth display, in a window no less. I'm sure you know that, of course.

I'm entirely unaware of Explorer running in 8-bit (256color) mode on any modern system. That seems rather odd, as I can display elements within Explorer in 32-bit color. So, the "explorer" interface runs in 8-bit, and then has to separately render higher-color-depth elements?

I'm not saying MS wouldn't do something that stupid, but it seems AWFULLY stupid, frankly, doesn't it?

Explorer doesn't render in 256 colours but it uses palettes internally (mainly for system tray icons). They are still tied to GUI objects which means they affect the entire system.
If you don't want to believe me, go Google for it - you will find many people recommending killing explorer.exe as a "solution" to the directdraw psychedelic colours issue.

You could be right, but the reason I'm dubious is that I have personally communicated with more than a dozen folks who have written replacement drop-in-DLL "DirectDraw" fixes for various games, and each of them has (independently) given the same explanation to me... all consistent, and all actually having (independently) coded WORKING solutions to the problems.

I haven't written these myself, but when that many separate people give me ONE explanation, and are able to resolve issues based upon their understanding... and one explanation comes along which contradicts that... I find myself tending to believe those who've actually produced code which resolves the issues.

But I'm not the expert on this topic, sooo...

The solutions are all the same: stop rendering in 256 colours, do the palette lookups manually and render in 24/32-bit mode. As long as the palette isn't tied to a GDI object it won't be modified by other programs.

https://stackoverflow.com/questions/1054365/exclusive-directdraw-palette-isnt-actually-exclusive
That thread has pretty much all the relevant info; palettes being changed by non-directdraw apps (MSN Messenger, CSRSS), the directdraw palette compatibility flag and the solution everyone ends up using (manual colour lookups).

Thanks, I'll give it a look.