ABCDEFG

You didn't mention the speed of your 2GB module, nor did you mention latency. And i think you're forgetting that Windows NT uses all the cores your processor has, and Windows 98 can't. So whatever you've tested, of course it will be faster on Windows NT. It has nothing to do with memory size at all. I have 16GB, quad channel on my x79 board and there are no slowdowns because of it, in fact there is an acceleration because all four channels are filled with memory, so the communication between the processor and memory is significantly faster... When I was putting that system together i saw big improvements - a huge increase in fps in the Quake III benchmark, there is a huge difference between single channel and quad channel configuration.

The EX58-UD4 supports triple channel memory. So it depends on where you put the second stick of memory and also depends on the speed of that second stick, if the second stick is slower than the first the BIOS will automatically set the memory speed to the speed of the slowest stick.

@awkduck Well, in theory it is possible if we had a team of expert software engineers and system programmers who know 9x in depth, who would dedicate their time to this problem. It is not a simple problem and would require modifying some vxds and dlls and adding new functionality. At first glance it may not look like that, and it may seem simple, but just look at kernel32.dll it is only 460kB, but its assembly code when disassembled is about 5.5MB. Also VMM.VXD is about 450kB but when disassembled it is about 2.5MB of assembly code. Similar applies to VWIN32.VXD and others. There would also be a problem with the shell, User32.dll and GDI32.dll and others which are not fully 32-bit but most of their most important functionality is actually 16-bit because 9x systems are hybrid. And many other important files that would have to be modified. And not just a small modification but a complete reengineering is required. That is a MASSIVE task and therefore it is not realistic to expect such a thing to happen in practice. But we can still use multiprocessors/multicores for, some calculations and such things...

Well, it would certainly be interesting to see his code, but it is not necessary since the mechanisms for starting the processor/core are known. here are some simple examples: https://board.flatassembler.net/topic.php?t=13498 https://board.flatassembler.net/topic.php?t=21093 And the absolute best example: https://github.com/WindowsNT/asm And it is possible to use something like that for GPU emulation and that would be it, that would be the end of the story. But to be able to use something like that in the ring 3 space of a 9x system - to enable multithreaded applications to truly take advantage of multiprocessor/multicore systems, this would require modification of a large part of the kernel.

well, that sysinternal suite thing, it was created late, so most things require win2k+, however some things from that package still work, namely: Filemon, procexp, Regmon, ZoomIt... Here is the link for that package: https://web.archive.org/web/20061216013739if_/http://download.sysinternals.com:80/Files/SysinternalsSuite.zip

I have everything from sysinternals, but there are things i can't distribute. Anyway, it's not that hard to find what you're interested in, almost everything is archived on archive.org https://web.archive.org/web/20060705013959/http://www.sysinternals.com/Utilities.html

wxDev-C++ Versions 6 and 7 are the last compatible with 9x systems. https://archive.org/details/wxdevcpp_7/ And it seems that one thing went mostly unnoticed, Borland C++ Builder 1.0 is now free. https://blogs.embarcadero.com/celebrating-25-years-of-cbuilder/ https://cc.embarcadero.com/item/30934 It produces relatively small executable files with a small number of dependencies - only 6 dlls. And after applying the UPX compressor, the executable file is only 100KB.

@Winster95 Da, imam te fajlove u mojoj arhivi. EN: Yes, i have those files in my archive. @Black Doomer I don't remember exactly when I got them, but I have a large archive of almost everything for 9x systems.

Man, is this what you were looking for? C:\DCI. ├───DISK1 │ │ LICENSE.DOC │ │ LOADBMP.DOC │ │ README.TXT │ │ SPEC16.DOC │ │ │ └───DEVKIT │ ├───BIN │ │ DCIMAN.DLL │ │ DCISVGA.DRV │ │ DVA.386 │ │ ICCVID.DRV │ │ IR32.DLL │ │ MSVIDEO.DLL │ │ UDH.DLL │ │ │ ├───INC │ │ COMPDDK.H │ │ DCIDDI.H │ │ DCIMAN.H │ │ │ ├───LIB │ │ DCIMAN.LIB │ │ │ └───SAMPLE │ ATI68800.ASM │ BRESNHAM.C │ CBLIT.ASM │ CLIPBLIT.C │ CONVERT.ASM │ DCIENTRY.C │ DCIEXFNS.C │ DCIHDW.C │ DCIHDW.H │ DCIMACRO.INC │ DCISAMP.C │ DCISAMP.DEF │ DCISAMP.RC │ DEBUG.H │ GDIDEFS.INC │ MAKEFILE │ READNDX.ASM │ STRBLIT.ASM │ STUBAPI.ASM │ VALIDBMP.C │ VERSION.H │ VERSION.RCV │ ├───DISK2 │ LOADBMP.DLL │ TDCITEST.EXE │ TMCIAVI.EXE │ └───VFW11DRT ACMCMPRS.DL_ AVICAP.DL_ AVIFILE.DL_ CLEANUP.RE_ COMPOBJ.DL_ CTL3D.DL_ DCISVGA.DR_ DISPDIB.DL_ DVA.38_ ICCVID.DR_ IMAADPCM.AC_ INIUPD.DL_ IR21_R.DL_ IR32.DL_ MAP_WIN.HL_ MCIAVI.DR_ MCIOLE.DL_ MPLAYER.EX_ MPLAYER.HL_ MPLAYER.RE_ MSACM.DL_ MSACM.DR_ MSADPCM.AC_ MSCOMSTF.DL_ MSCPYDIS.DL_ MSCPYDIS.IN_ MSCUISTF.DL_ MSDETECT.IN_ MSDETSTF.DL_ MSINSSTF.DL_ MSRLE.DR_ MSSHLSTF.DL_ MSUILSTF.DL_ MSVIDC.DR_ MSVIDEO.DL_ OLE2.DL_ OLE2.RE_ OLE2CONV.DL_ OLE2DISP.DL_ OLE2NLS.DL_ OLE2PROX.DL_ PROFDISP.EX_ SETUP.EXE SETUP.INI SETUP.IN_ SETUP.LST SETUP.MST SETUPAPI.IN_ STDOLE.TL_ STORAGE.DL_ TYPELIB.DL_ _MSSETUP.EX_ _MSTEST.EX_

Well, i have the newer version archived, the one that was there:

You can search for "win98updt0001.zip" and "KernelUpdate020.rar" and there you'll see how it's done.

Yes.

GCC 11.1.0 - > https://github.com/fsb4000/gcc-for-Windows98/releases/tag/gcc11.1.0

Yes, i understand, that's how it is today, we don't have time for anything. I was thinking of trying it so i wanted to make sure it was supported. Thank you.

Hello. So, these .inf files, are they available for the x79 chipset?