HELP!: Who can fix Micrografx Picture Publisher 8?

Questions about Wine on Linux
Post Reply
=CO= Windler
Level 2
Level 2
Posts: 13
Joined: Wed Apr 07, 2021 1:27 am
Location: Germany
Contact:

HELP!: Who can fix Micrografx Picture Publisher 8?

Post by =CO= Windler » Sat Apr 10, 2021 1:29 am

My most important graphics program for drawing and complex photo editing is Micrografx Picture Publisher 8. Unfortunately it does not run in WINE on modern hardware. I examined it with DependencyWalker but found no solution.

As a collector and hardware researcher of music keyboards and soundtoys, for reference I keep on my harddisk some 10000 downloaded old eBay pages (consisting each of a HTML page and directory with media contents) and have some 100000 own digicam photos of hardware details etc. Yet I used for this Picture Publisher 8 on my main PC (Colani bigtower) for major photo rework jobs, but because the highend Win98SE machine (AMD K6-3@550MHz, 768MB RAM) became completely overloaded with this work (160GB harddrive full to the brim and FAT32 too slow), I installed an additional modern ITX mainboard with AMD 2400G and 8TB harddrive running Linux Mint 20.1 with KDE 5 Plasma and WINE 6.3 (using PlayOnLinux to switch versions).

After installing Micrografx Picture Publisher 8 (German version) in WINE 6.3, the canvas does not react on drawing, so first you need to disable DirectDraw mode in "Display" menu(?). Then you need to disable the active mask and set the drawing mode of the brush to standard (initially something wrong is selected) and choose a colour (other than white) to draw something. The bad thing is that the file requester causes a crash so you can not save your work (you may try a screenshot). Also some other things like clicking on blur/sharpen tool crashes.

bugs

(Because my install is in German language, the actual menu item names may differ.)

- Most severe is, you can not save your work, because the file requester crashes (halfway visible, buttons and contents missing). But "export" as JPG (which uses a different file requester?) does function ok. On my Win98SE PC it rarely crashed too during saving (very annoying), so I conclude there may be a race condition bug in the program triggered by slow responding OS or file system.

- Clicking the blur/sharpen/brighten/darken drawing tools makes it crash.

- Closing the "make website"(?) window makes it crash.

- Moving the toolbar menus around causes temporary coloured pixel garbage.

- Running the installer makes the blue desktop background stay in front of a popup requester, so you can not click "ok" to finish the successful installation. But killing it with ALT F4(?) seems to work ok.

- Drawing works only when you disable the DirectDraw mode in "Display"(?) menu. Else picture contents gets scrambled e.g. by moving the window.

Version "Picture Publisher 7" is very similar and in WINE has the same bugs except that it does not need the disable DirectDraw workaround.

diagnosis

Apparently SHELL32.DLL and WINSPOOL.DRV fail. They are loaded by MGXBRWSR.DLL and by PP80.EXE. Also MGX42.DLL fails when using some functions.

Running DependencyWalker 2.2 for "Micrografx Picture Publisher 8" on Linux using WINE 6.3 starts with:

"Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module."

Inserting a SHELL32.DLL from 2007 (works in Win98SE) =>DependencyWalker compains about missing KRNL386.EXE (refered by KERNEL32.DLL), which seems to be a 16bit module. It also complains about missing dependencies to other 16bit stuff (which is not supported by 64bit Linux kernels on my AMD 2400G). Also "Micrografx Picture Publisher 5" is 16bit and hence can not run at all, so I only analyzed version 8.

(I initially had tried to transplant the installation folder from my Win98SE system, which did not work. So I tried severe registry surgery by exporting .REG files and hand-editing all paths (my Win98SE is on drive E:). Because it is German, I also had to replace the folder name "Programme" with "program files" to work in WINE. I also had to copy all DLLs named mgx*.dll and lt*.dll(?) from windows\system folder. However attempting JPG export had opened a blank window (no preview) and failed. So I finally searched my install CD and cleanly installed from the original installer, which makes JPG work but the bugs stay the same.)

This is a quick summary of the DependencyWalker output on WINE. The complete outputs are very lengthy, so I won't post them here unless anybody convinces me that they will be useful to solve the problem.

Code: Select all

System Information:

Dependency Walker:	2.2.6000 (32-bit)
Operating System:	Microsoft Windows 98 (32-bit)
OS Version:	4.10.2222 A (Second Edition)
Processor:	x86 Family 23 Model 17 Stepping 0, AuthenticAMD, ~3600MHz
Number of Processors:	8, Mask: 0x000000FF
Computer Name:	JUCHHE
User Name:	co_windler
Local Date:	Donnerstag, 8. April 2021
Local Time:	06:31:59 Mitteleuropäische Sommerzeit (GMT+02:00)
OS Language:	0x0407: German (Germany)
Memory Load:	31%
Physical Memory Total:	2.147.483.647 (2048 MB)
Physical Memory Used:	0
Physical Memory Free:	2.147.483.647
Page File Memory Total:	4.294.443.007
Page File Memory Used:	18.446.744.073.709.027.328
Page File Memory Free:	4.294.967.295
Virtual Memory Total:	2.147.352.575
Virtual Memory Used:	65.536
Virtual Memory Free:	2.147.287.039
Page Size:	0x00001000 (4.096)
Allocation Granularity:	0x00010000 (65.536)
Min. App. Address:	0x00010000 (65.536)
Max. App. Address:	0x7FFEFFFF (2.147.418.111)
Apparently SHELL32.DLL and WINSPOOL.DRV fail. Both are called by COMDLG32.DLL and are loaded by MGXBRWSR.DLL (handles file requester?) and by PP80.EXE. Also MGX42.DLL (part of Microsoft Foundation Classes/MFC) fails in some functions.

# SHELL32.DLL has 7 red dependencies:

SHCreateItemFromIDList
SHCreateShellItemArray
SHCreateShellItemArrayFromDataObject
SHGetFolderPathW
SHGetIDListFromObject
SHGetItemFromObject
SHParseDisplayName

# WINSPOOL.DRV has 2 red dependencies:

GetDefaultPrinterW
GetDefaultPrinterA

Replacing SHELL32.DLL and WINSPOOL.DRV with Win98SE parts fails because of dependencies to KRNL386.EXE which is 16bit.

# open file (file requester): =>program crash

Code: Select all

00:01:59.099: Loaded "c:\prog~fbu\micr~ong\system4\browser\MGXBRWSR.DLL" at address 0x492D0000.  Cannot hook module.
00:01:59.134: DllMain(0x492D0000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\prog~fbu\micr~ong\system4\browser\MGXBRWSR.DLL" called.
00:01:59.139: DllMain(0x492D0000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\prog~fbu\micr~ong\system4\browser\MGXBRWSR.DLL" returned 1 (0x1).
00:01:59.305: First chance exception 0xC0000005 (Access Violation) occurred in "c:\windows\system32\SHELL32.DLL" at address 0x7DD0BB02.
00:01:59.307: Second chance exception 0xC0000005 (Access Violation) occurred in "c:\windows\system32\SHELL32.DLL" at address 0x7DD0BB02.
00:01:59.313: Exited "c:\program files\micrografx\picture publisher 8\PP80.EXE" (process 0xF4) with code -1073741819 (0xC0000005).
Here SHELL32.DLL fails.

# click on blur tool: => program crash

Code: Select all

00:01:16.036: First chance exception 0xC0000005 (Access Violation) occurred in "c:\program files\micrografx\picture publisher 8\PP80.EXE" at address 0x433CF37C.
00:01:16.039: First chance exception 0xC0000005 (Access Violation) occurred in "c:\program files\micrografx\picture publisher 8\PP80.EXE" at address 0x433CF37F.
00:01:16.041: First chance exception 0xC0000005 (Access Violation) occurred in "c:\windows\MGX42.DLL" at address 0x5F40331D.
00:01:16.043: First chance exception 0xC0000005 (Access Violation) occurred in "c:\windows\MGX42.DLL" at address 0x5F40331F.
00:01:16.046: Second chance exception 0xC0000005 (Access Violation) occurred in "c:\windows\MGX42.DLL" at address 0x5F40331F.
00:01:16.051: Exited "c:\program files\micrografx\picture publisher 8\PP80.EXE" (process 0xF0) with code -1073741819 (0xC0000005).
# close website template window: => program crash

Code: Select all

00:00:58.249: DllMain(0x44640000, DLL_PROCESS_DETACH, 0x00000000) in "c:\program files\micrografx\picture publisher 8\wizards\WEBSTYLE.PPW" called.
00:00:58.252: First chance exception 0xC0000008 (Invalid Handle) occurred in "c:\windows\system32\NTDLL.DLL" at address 0x7BC23ED9.
00:00:58.256: DllMain(0x45040000, DLL_PROCESS_DETACH, 0x00000000) in "c:\program files\micrografx\picture publisher 8\WIZTOOLS.DLL" called.
00:00:58.259: DllMain(0x45040000, DLL_PROCESS_DETACH, 0x00000000) in "c:\program files\micrografx\picture publisher 8\WIZTOOLS.DLL" returned 1 (0x1).
00:00:58.263: Unloaded "c:\program files\micrografx\picture publisher 8\wizards\WEBSTYLE.PPW" at address 0x44640000.
00:00:58.266: Unloaded "c:\program files\micrografx\picture publisher 8\WIZTOOLS.DLL" at address 0x45040000.
00:00:58.268: First chance exception 0xC0000005 (Access Violation) occurred in "c:\windows\MGX42.DLL" at address 0x5F46EEAD.
00:00:58.271: Second chance exception 0xC0000005 (Access Violation) occurred in "c:\windows\MGX42.DLL" at address 0x5F46EEAD.
00:00:58.277: Exited "c:\program files\micrografx\picture publisher 8\PP80.EXE" (process 0x12C) with code -1073741819 (0xC0000005).
In both cases the MGX42.DLL (part of Microsoft Foundation Classes/MFC) fails.


I am desperately attempting to get Micrografx Picture Publisher 8 to work in WINE, but I can not even leave a comment on its AppDB page because it has no maintainer. Becoming the maintainer is likely to complex for me because I know too little about the detailed inner working of WINE. Can I test or upload anything else to help debugging? (Archive.org has an ISO image of the install CD.)

Please tell me what I can do to fix this.

=CO= Windler
Level 2
Level 2
Posts: 13
Joined: Wed Apr 07, 2021 1:27 am
Location: Germany
Contact:

Re: HELP!: Who can fix Micrografx Picture Publisher 8?

Post by =CO= Windler » Mon Apr 19, 2021 8:25 pm

Generally the file requester of Picture Publisher 8 has many strange bugs those make it fail if anything is non-standard.

I have installed a Windows 98SE in VirtualBox 6.1 now, but even there the PP8 file requester was garbled and unusable; the folders pane was displayed too large, which makes the lower button row invisible (outside the window) because the window size does not adapt to it.

It turned out that this had to do with the unofficial Win98SE Service Pack 3.1 (German) I installed on VirtualBox, which made the file requester larger (also e.g. in notepad.exe) and so makes the custom version of PP8 not fit into its fixed size window anymore. Also the special name user folders ("Eigene Dateien" etc.) are not displayed. The "Save As" dialog text was english despite german version of Win98SE. It turned out that a too new COMMDLG.DLL made trouble here.

https://www.creopard.de/projekte/window ... e-pack.htm

I also discovered that when on my real Win98SE system I simulate through KernelEx 4.5.2 any newer (NT based) Windows versions than 98, I see in the file requester top row 2 additional buttons. One toggles the folder pane to an album folder (internal of PP8), the other hides the thumbnails pane and so makes the window smaller. But when I click both alternately in a certain order, the contents gets garbled, drawing buttons on top of thumbnails etc. (Clicking both buttons again will finally ungarble it.)

COMMDLG.DLL 4.0.0.950 = "Allgemeine Dialogbibliotheken"
COMMCTRL.DLL 4.10.1998 = "Bibliothek für benutzerdefinierte Steuerelemente"

I found a patch "BigOpenBox.zip" (by Fredledingue) that is intended to change the save dialog box size in Win98SE by replacing COMDLG32.DLL.
quote from BigOpenBox instruction:

MANUAL INSTALLATION
...
1/ Copy the file into "C:\WINDOWS\SYSTEM"

2/ Open the file "C:\AUTOEXEC.BAT" in notepad and add the following code at the end

::----start of code----

cd windows
cd system
rename Comdlg32.dll Comdlold.dll
rename 2omdlg32.dll Comdlg32.dll
exit

::----end of code----


3/ Restart your computer.

My installed versions were

COMDLG32.DLL 4.72.3510.2305 (c)1981-1997
COMDLG32.OCX 6.01.9841 (c)1987-2000 "CMDialog ActiveX Controll DLL"

with file date 2019-12-17 those got installed by the unofficial Service Pack 3.1 (found in SP3.CAB).

In my real Win98SE machine they are older:

COMDLG32.DLL is 4.72.3510.2300 (c)1981-1997 (file date 1999-05-05 22:22)
COMDLG32.OCX is 6.00.8418 (c)1987-1998 (file date 2001-01-17 5:00)

Copying these into VirtualBox makes Picture Publisher 8 work correctly and also returns the original smaller file dialog with German text in Notepad.

Unfortunately VirtualBox in Win98SE can not easily save data outside its virtual partition (import works only by mounting an ISO image as virtual CD that cuts long file names) because its "Guest Additions" does not support DOS based OS. Thus it is pretty useless for doing actual work with a graphics program.

fargodwe
Level 5
Level 5
Posts: 466
Joined: Mon Oct 02, 2017 7:08 am

Re: HELP!: Who can fix Micrografx Picture Publisher 8?

Post by fargodwe » Mon Apr 19, 2021 9:10 pm

First off, I know nothing about image editing, etc.. That being said, I know there is a learning curve to them but have you looked into something native like GIMP or any of the other (some more complex and higher learning curve) for image manipulation?

=CO= Windler
Level 2
Level 2
Posts: 13
Joined: Wed Apr 07, 2021 1:27 am
Location: Germany
Contact:

Re: HELP!: Who can fix Micrografx Picture Publisher 8?

Post by =CO= Windler » Tue Apr 20, 2021 7:49 pm

Yes I may look at GIMP. But Picture Publisher 8 is fairly good (perhaps less than Photoshop because it is raster based) and requesting to abandon it is like saying to a cello player "Sorry, cellos are outdated now and not made anymore. It's time to learn to blow tuba instead."

fargodwe
Level 5
Level 5
Posts: 466
Joined: Mon Oct 02, 2017 7:08 am

Re: HELP!: Who can fix Micrografx Picture Publisher 8?

Post by fargodwe » Tue Apr 20, 2021 10:08 pm

Again, not knowing anything about such things, I also remember something like inkscape or some such thing. Don't know if that would be of any benefit to you or not. I get the idea of having a tool that suits a need. I guess the biggest thing would be if you made the switch to linux, your weren't worried about the oboes ;) so maybe a switch to something native would in the long run be worth it?

=CO= Windler
Level 2
Level 2
Posts: 13
Joined: Wed Apr 07, 2021 1:27 am
Location: Germany
Contact:

Re: HELP!: Who can fix Micrografx Picture Publisher 8?

Post by =CO= Windler » Sat Apr 24, 2021 1:01 am

One of the most crucial features of Picture Publisher 8 to me is local colour correction by masking a part of a picture (optionally with alpha channel) and locally bending by mouse the input-output transition curve for brightness or the individual RGB/HSV parts to intensify details. (This sophisticated tool is far more than just a gamma slider - you can invert sections or smoothen the ends of the curve etc.) E.g. when I have a too dark photo of an opened music keyboard with black plastic case, it permits to make case details (like embossed manufacturing date or serial number) visible or correct overexposed spots on the shiny PCB surface to show the traces.

Most modern drawing crapware is barely better than the M$ Paint of my Win98SE because it lacks such detail control. It might be that some of those "apps" instead use AI with a smart neural network to optimize photos now. But in real life such algorithms fail to understand the difference between a foggy autumn landscape and an overexposed moonlight scene - not to say special things like the inside of electronics with shiny black plastic case. (My Samsung WB210 digicam contains tons of such fully automatic gimmicks those in real life always fail.)


I experimented with Win98SE in VirtualBox, but I always need to disable the 32bit protected mode IDE driver because AMD Ryzen 2400G APU apparently has page cache bugs those make the driver randomly fail to load files. Despite the 16bit driver is fast enough, it has the nasty side effect to use the DOS driver for CDROM access (the only easy way to load files into the VM) which only shows the short DOS filenames. (Regard that enabling 32bit IDE makes Windows automatically comment out that CDROM driver in AUTOEXEC.BAT, thus you need to manually re-enable it to get the CDROM drive letter back.) Worst is that the Guest Addition can not be loaded on Win98SE (I tried even with KernelEx 4.5.2), so there is no easy file exchange. Likely I have need to share a folder through network to get any files out of the virtual partition.

Win98SE also needs the SciTech DisplayDoctor 7 to get more than 16 colour VGA resolution (and even fairly fast OpenGL software renderer by selecting the CAD mode driver), but on Ryzen it fails to boot by not identifying the too new CPU. To fix this, simulate a Pentium 4 (the fastest CPU of its era) by entering in a terminal:

VBoxManage modifyvm "Windows 98SE" --cpu-profile "Intel Pentium 4 3.00GHz"

("Windows 98SE" is my guest partition name. In Windoze the command syntax differs a bit.)

CPU-Z reports it as 3600MHz, so beside having only 1 core (Win98SE has no use for more) it runs at full speed.

You may also install the Realtek AC97 driver to get (slightly choppy) sound e.g. in "Space Cadet Pinball". You need to manually unpack the EXE with 7-zip or use KernelEx, else the installer complains that it is only for Win95.

https://msfn.org/board/topic/158893-win ... 7-drivers/
https://download.cnet.com/Realtek-AC-97 ... 38712.html
https://www.advantech.com/support/detai ... id=1-AQHM0
http://vogonsdrivers.com/getfile.php?fi ... enustate=0


I always thought that virtual machines are scary. And I was right; they are even worse. There is so much spooky background stuff going on (like quantum interferences from the nearby brane of another universe...) that makes behaviour unpredictable. This is some lengthier analysis of what I tested on Win98SE without success.

Selecting in Win98SE filesystem "Synchrone Pufferzuweisung deaktivieren" (disable sychronous buffer assignment) makes it more often boot in 32bit mode without missing file errors, but many programs still don't load e.g. with strange error "Die erforderliche DLL-Datei .DLL wurde nicht gefunden." (DLL not found). This mostly happened with non-preinstalled stuff (default programs of Windows load ok). Possibly it only affects files after a certain sector number. It becomes less extreme after running Scandisk (despite it found no errors); may be this rather loads the emulated HDD into a buffer or such background crap already by reading all files. Also quitting and restarting VirtualBox (not only the VM window) can help. But e.g. PP8 does not load, so the filesystem driver is still broken. (On VirtualBox I had tried many other emulated harddisk interfaces, those did the same errors or even corrupted the virtual FAT32 partition - but of course returning to a saved state will work.)

Enabling additional "Behandlungsroutine für Festplatten-Interrupt im Protected-Modus deaktivieren" (disable HDD interrupt in protected mode) causes the many missing files problem again. Same when setting "Leseoptimierung (read-ahead)" to 0% and stays broken when going back to 100%. Toggling "Synchrone Pufferzuweisung deaktivieren" seems to fix it again. Likely it is a nasty buffering/disk cache bug depending on the order in that a file is read (else Scandisk would show errors).

Trying to load Unofficial Service Pack 3.1 from virtual CD shows error "Die erforderliche DLL-Datei .DLL wurde nicht gefunden." (DLL not found) and something in WINDOWS\TEMP can not be found. Starting the service pack (without 32bit filesystem driver) and selecting "DMA für alle (E)IDE/(P)ATA Festplatten aktivieren" =>after enabling 32bit the missing files problem returns worse (even Runddll32.dll fails when opening "System" setup). Again running Scandisk temporary fixes this (by only reading). The harddisk is now listed as "GENERIC IDE DISK TYPE47" together with "VBOX CD-ROM" under the "Primary IDE controller (dual fifo). After reboot I end with blank desktop because explorer.exe not found.

With 32bit filesystem disabled, I can not even see "GENERIC IDE DISK TYPE47" in the broken devices menu to get rid of DMA because the drives section is gone. Reboot with 32bit filesystem shows it (and missing files) so I can uncheck DMA, but the errors stay there. Again "System" setup did not run. Deleting "GENERIC IDE DISK TYPE47" (and diskette controller as fake tape drive) in safemode, setting busmaster IDE to only 1 channel =>again missing files problem. CDROM is shown, which proves that it uses the same channel like HDD (which in real PC hardware sometimes made trouble).

Thus I returned to saved previous state =>behaves the same? =>explorer.exe not found (blank desktop lockup). Again safemode and later Scandisk made it start ok. Save state and reload again has missing files problem, thus it likely does not depend on the virtual disk content but actual ram and disk cache.

A while later e.g. Process Explorer did start in 32bit filesystem mode despite other files were not found. Thus it is definitely a cache problem depending on external things. It may be the "Windows 9x TLB Invalidation Bug" when memory page cache is not purged properly.

https://blog.stuffedcow.net/2015/08/win ... ation-bug/

Disabling "IO APIC" in VM doesn't help.

VBoxManage modifyvm "Windows 98SE with Software" --cpu-profile "Intel 80486"

starts ok, but filesystem 32bit has bugs. CPU-Z (only starts after scandisk) thinks it is an Intel 80486DX2 with almost 3600MHz (which indeed runs quite fast). According to vbox.log it has no VME extension, thus it is no VME bug.

Windows 98 SE VM on a Ryzen 3000 not working:
https://www.vogons.org/viewtopic.php?f= ... 5&start=20

The dead link from Google translate apparrently should go here

Windows 98 SE erfolgreich mit AMD Ryzen 1600 CPU in VMware 12.x installieren:
https://www.creopard.de/2020/05/VM-Wind ... lieren.htm

It is about VMware, but the key point is also here to disable 32bit protected mode filesystem driver. Then you should replace ESDI_506.PDR with a patched version.

C:\WINDOWS\SYSTEM\IOSUBSYS\ESDI_506.PDR

replace it with this one:
ESDI_506 - 48-bit LBA Korrektur.ISO
https://www.creopard.de/download/get/esdi_506/47.htm

Unfortunately this does not work on my Ryzen 2400G; I thought I already had this driver from the unofficial service pack 3.1; the binary code differs but it still crashed. Disabling "Nested VT-x/AMD-V aktivieren" did not help. Disable Nested Paging also in the other tab of VirtualBox makes not picture when Win98SE enters SVGA mode.

I read that masking the VME flag may fix Win98 problems on Ryzen, but it does not work at all:

VBoxManage modifyvm "Windows 98SE mit Software" --cpuidset 1 00800f11 00000800 56d8220b 078bfbfd

=> complete crash with error message
>>>
CPUM internal processing error #1. (VERR_CPUM_IPE_1).

Fehlercode:
NS_ERROR_FAILURE (0x80004005)
Komponente:
ConsoleWrap
Interface:
IConsole {872da645-4a9b-1727-bee2-5585105b9eed}
<<<

VBoxManage modifyvm "Windows 98SE mit Software" --cpuidremove 1
(undo VME masking)

VBoxManage modifyvm "Windows 98SE mit Software" --cpu-profile "Intel Pentium 4 3.00GHz"
(back to Pentium 4)

makes it function again.

Here are some VirtualBox tips:

https://www.creopard.de/2019/01/In-2019 ... difyvm.htm
https://www.creopard.de/2020/05/VM-Wind ... lieren.htm

The Unofficial Service Pack 3.1 adds many newer DLL versions, which however corrupt the device manager window, so it lacks the lower buttons and scrollbar, which prevents reaching lower parts.

https://www.creopard.de/2019/10/Windows ... n-Beta.htm

You also need to reinstall the old versions of COMDLG32.DLL and COMDLG32.OCX else the Picture Publisher 8 file requester will not work.

COMDLG32.DLL is 4.72.3510.2300 (c)1981-1997 (file date 1999-05-05 22:22)
COMDLG32.OCX is 6.00.8418 (c)1987-1998 (file date 2001-01-17 5:00)

fargodwe
Level 5
Level 5
Posts: 466
Joined: Mon Oct 02, 2017 7:08 am

Re: HELP!: Who can fix Micrografx Picture Publisher 8?

Post by fargodwe » Sat Apr 24, 2021 3:58 am

If you got it to work for you by using a virtual machine then that's your choice - as long as it works for you is what matters. I think you might find more than one user of gimp and several other high-quality tools would argue with being counted as "crapware" and that it's not any better than mspaint. I know Inkscape is a vector-based graphics program and certainly not to be included in the catagory of crapware or mspaint either. So as long as you can do what you want that's all that matters - but in the long run you're going want to change to something different. You already know about Win98. Don't close the door to world-class applications just because they are free.

andrew.smart
Level 2
Level 2
Posts: 33
Joined: Thu Dec 15, 2016 3:08 am

Re: HELP!: Who can fix Micrografx Picture Publisher 8?

Post by andrew.smart » Sat Apr 24, 2021 4:19 am

I expect shell32.dll is too "low level" to be replaced with native. Replacing builtin DLLs with native DLLs might work with "higher level" DLLs. My guess is that shell32.dll, kernel32.dll, ntdll.dll are on a list of DLLs that you can't possibly replace with native because they are too "low level". I have no idea what that list might be.

I took a peek at just one thing, SHGetFolderPathW.

It is public in shell32.dll here:
https://github.com/wine-mirror/wine/blo ... .spec#L380

Declared here:
https://github.com/wine-mirror/wine/blo ... bj.h#L1568

Defined here:
https://github.com/wine-mirror/wine/blo ... th.c#L4394

So... it exists. Why DependencyWalker doesn't see it, I don't know. MGXBRWSR.DLL isn't linking to it? I think this is where I'd investigate. Maybe it wants a different signature than what exists. Maybe it's not looking at the right path. winedump might be useful in your investigation.

This guide to WINE is pretty good, I recommend you read it if you're interested in WINE:
https://www.codeweavers.com/blog/aeikum ... -ecosystem

With refining WINEDEBUG appropriately you can refine where the problems are. When you want to see the trace messages for a particular function, say SHGetFolderPathW, you look at the top of the *.c file where it is defined, and add that channel. In the case of that schellpath.c, it is: +shell. You'd want +seh too. Feel free to get an appropriate WINEDEBUG log and file a bug for Micrografx Picture Publisher 8. Actually I see one here:
https://bugs.winehq.org/show_bug.cgi?id=45999

On that bug I suppose you could add a link to this archive.org backup of said software:
https://archive.org/details/micro-grafx ... her-8-1998

Assuming WINE also doesn't find the SHGetFolderPathW that MGXBRWSR.DLL wants, I'd look in the relay at the KERNEL32.GetProcAddress calls (search for SHGetFolderPathW), specifically the retval in the return, to see if it's an error code.
5054.585:0020:0024:Call KERNEL32.GetProcAddress(6ec40000,077411e3 "SHGetFolderPathW") ret=05fa05f4
5054.585:0020:0024:Ret KERNEL32.GetProcAddress() retval=6ec418c8 ret=05fa05f4

I don't know what debug channels are relevant, one of these:
WINE_DEFAULT_DEBUG_CHANNEL(module);
WINE_DECLARE_DEBUG_CHANNEL(relay);
WINE_DECLARE_DEBUG_CHANNEL(snoop);
WINE_DECLARE_DEBUG_CHANNEL(loaddll);
WINE_DECLARE_DEBUG_CHANNEL(imports);

Good luck, I'm sure someone else can help better as my knowledge is not perfect. But I think the first step would be getting a sufficient WINEDEBUG log.

=CO= Windler
Level 2
Level 2
Posts: 13
Joined: Wed Apr 07, 2021 1:27 am
Location: Germany
Contact:

Re: HELP!: Who can fix Micrografx Picture Publisher 8?

Post by =CO= Windler » Sun Apr 25, 2021 2:08 am

I did not imply that Inkscape or GIMP was crapware. (I rather think of all those "apps" simplified to the max and designed to be used on tablets without users nagging the company, where the manufacturers systematically eliminate any feature that causes too much work for the customer support.)

Although I studied computer engineering in 1990th, I am not expert about the inner working of Windows or WINE. Sorry.

Yet PP8 is not usable in a Win98SE VM either; VirtualBox can only load data (from simulated CD-ROM) into the VM but not export the result outside its virtual partition which makes it quite pointless. It may be possible to get a shared network directory to work (found no tutorial yet) or send them by e-mail by installing a local mail server on Linux (haven't tried), but this all makes me jump to much worse piles of burning hoops than exchanging data through USB sticks with the real DOS-age mainboard.

But because antique hardware can not survive forever, there must be an effective method found for running DOS based Windows code on modern hardware. (Currently there seems to be a huge gap between Win3.11 (in DOSbox) and XP (in commercial VM) that nobody considers worth to be fixed.) Currently already 16bit code can not run in 64bit mode of Intel/AMD CPUs anymore and even 32bit is getting worse, has too many incompatible variants and can be expected to vanish within some years in the name of obsolescence for maximized profit. While the MAME emulator is great in gathering knowledge about the inner working of all kinds of historical hardware (before it extincts of bitrot), implementation is yet too chaotic to ensure long-term compatibility with future computers.

For the human right of culture preservation it is time to develop a nested emulator protocol to automatically replace yet unemulated features on the host CPU with nested emulation layers (possibly involving JIT compilers or even AI) if the needed emulation already existed on a now incompatible older hardware. Unlike nowadays emulators this needs to be based on a strictly formalized well-defined public domain API (similar like the TeX language) that keeps the system usable even in situations where knowledge about the functioning of inner layers got lost or experts are not available. The approach may appear stupidly slow, but when we compare 8bit hardware with modern cheap RasPi or APU, we can expect that if coming generations will stay capable to use it, they may employ yet unimaginable fast and strange hardware (may that be quantum based Turing machines or what ever).

This development should be preferringly not in the hand of profit based companies but a national software-archaeological taskforce in the manner of PLANETS or the KEEP project.

https://www.digitalpreservation.gov/ser ... anets.html
https://cordis.europa.eu/project/id/231954

andrew.smart
Level 2
Level 2
Posts: 33
Joined: Thu Dec 15, 2016 3:08 am

Re: HELP!: Who can fix Micrografx Picture Publisher 8?

Post by andrew.smart » Sun Apr 25, 2021 11:15 am

Oh, I'd figured with all your technical writing I thought you might have been interested in what I wrote on WINE.

With VirtualBox, I believe I used a SAMBA share to get files on and off. I might have also used sftp. Certainly was a chore to set up and use in a workflow.

With regard to hardware emulation that's beyond my knowledge.

You can learn a bit about CodeWeavers, one of the principle backers of WINE in this interview:
https://youtu.be/2H98T9-q2x8?t=1442

In that interview around 42:00 they talk about their collaboration with Adobe on Adobe Photoshop, and a change with Adobe Photoshop CS. I thought you might be interested giving your interest in business models and 2D graphics software.

fargodwe
Level 5
Level 5
Posts: 466
Joined: Mon Oct 02, 2017 7:08 am

Re: HELP!: Who can fix Micrografx Picture Publisher 8?

Post by fargodwe » Sun Apr 25, 2021 6:28 pm

In the interest of an ancient - and let's face it a piece of software published in 1998 is ancient - I'm going to try a few things. I do no hold out hope. Just hardware alone is betting against you. If you have an old piece of hardware it will run on leave it there. Need an old piece of hardware it will run on - check ebay, facebook marketplace, etc. - they should be cheap. You are in the same position millions of others have been - having an ancient piece of software they have never migrated away from and now want modern hardware and modern operating systems to support it. There is only so much people and companies are willing to go in that regard.

I assume since you posted in the linux wine forum that you probably wanted to get this working on a replacement piece of hardware using a free OS.

Since this is a forum about wine, I would think you will find people are more interested in things wine. Virtual machine software has their own support forums. If you have questions about wine then please post those.

fargodwe
Level 5
Level 5
Posts: 466
Joined: Mon Oct 02, 2017 7:08 am

Re: HELP!: Who can fix Micrografx Picture Publisher 8?

Post by fargodwe » Sun Apr 25, 2021 8:51 pm

In your opening post you also mentioned you use playonlinux. I don't think that tool is supported here.

=CO= Windler
Level 2
Level 2
Posts: 13
Joined: Wed Apr 07, 2021 1:27 am
Location: Germany
Contact:

Re: HELP!: Who can fix Micrografx Picture Publisher 8?

Post by =CO= Windler » Sun Apr 25, 2021 11:09 pm

Software like PP8 should still get supported by WINE since 98% of the application works and here basically only the file requester and blur/sharpen/brighten/darken tool fails, so I guess it lacks only minor tweaking of small parts.

I do need PlayOnLinux to avoid code regressions because I use many other Windows applications on Linux - particularly if I ever install test versions of WINE. AFAIK in PlayOnLinux embedded WINE versions can run independent from the WINE main install of the OS, so I can still install things outside if needed. Photoshop is nothing I am interested in. (I would rather learn to use GIMP.)

My hardware is a homemade dual PC system (Highscreen Colani bigtower with ISA/PCI mainboards DFI K6BV3+/66 for Win98SE and additional modern ITX mainboard AsRock B450 Gaming-ITX/ac under its ceiling) so I can switch between modern and DOS-age hardware, although this involves 2 mice and exchanging data through USB sticks. But I am shocked how badly virtual machines can handle DOS-based operating systems. I expected that beside tempo issues (choppy video/audio during games, perhaps no FM midi sound and of course lack of unemulateable hardware features like physical diskette drives) modern VM would run everything flawlessly that is too new for true emulators like DOSbox.

Yet companies typically support compatibility with only one previous hardware generation (e.g. PlayStation 4 plays games written for PS3 but not earlier models), which is (beside planned obsolescence) mainly done to reduce development and servicing complexity. Technically this is mainly a problem of configuration management that can be automated. The concept of nested emulation (or more generalized compatibility adapter) layers should become standard technology that will play a similar key role for long term interoperability like HTML played for the development of the internet. The principle is that if the host OS itself can not natively run an executable, it will first ask through a standardized protocol all installed (thinner to thicker) emulation engines if they can run it, and each of them that can't will (if present) recursively ask the same to older emulation engines available for their emulated hardware. So the protocol will count the depth of nested layers necessary to run the executable to permit the OS to decide the best suited emulator, which by default will be one with shortest path if not overridden by manual configuration. Said executable can be a whole application started by the user, but theoretically may be also an emulated hardware component like a graphics or sound IC within a complex modular emulation framework like MAME. Because nested emulators will be slow, technologies like JIT compilers max be integrated, and the system debugger may output statistic recommendations which emulators to reimplement on the host system.


MAY THE SOFTWARE BE WITH YOU!

fargodwe
Level 5
Level 5
Posts: 466
Joined: Mon Oct 02, 2017 7:08 am

Re: HELP!: Who can fix Micrografx Picture Publisher 8?

Post by fargodwe » Mon Apr 26, 2021 12:57 am

I've come up in the old days of large scale mainframe support all the way down to micros. I've seen my share of hardware/software/firmware emulators. Quite familiar with the complexities involved,

Play-on-linux will be problematic for support here.

Install PP8 using wine itself in it's own prefix. Run via the console and post back logs. Someone might be able to help you.

You would be far far better off to make switch to other software that is current, runs in current OS's (and in Linux itself since that is what you are running). I'm sure you know but GIMP is cross-platform and would run natively.

As much as I like some of my old software, including some I wrote years ago, I would never go through that much effort to make something that old work when new native apps are available. I would never go through screwing around with switching between physical hardware just to run it. I would never go through that much work with virtual machines, etc..

But that's just me.

=CO= Windler
Level 2
Level 2
Posts: 13
Joined: Wed Apr 07, 2021 1:27 am
Location: Germany
Contact:

Re: HELP!: Who can fix Micrografx Picture Publisher 8?

Post by =CO= Windler » Mon Apr 26, 2021 10:59 pm

I have now finally installed the WINE 6.7 development version (after uninstalling the system default WINE 5.0). I hope this can be good for anything.

Code: Select all

co_windler@Juchhe:~$ sudo apt-key add winehq.key
co_windler@Juchhe:~$ sudo add-apt-repository 'deb https://dl.winehq.org/wine-builds/ubuntu/ focal main' 
co_windler@Juchhe:~$ sudo apt update
[...]
co_windler@Juchhe:~$ sudo apt install --install-recommends winehq-devel
Paketlisten werden gelesen... Fertig
[...]
Die folgenden zusätzlichen Pakete werden installiert:
  wine-devel wine-devel-amd64 wine-devel-i386:i386
Die folgenden NEUEN Pakete werden installiert:
  wine-devel wine-devel-amd64 wine-devel-i386:i386 winehq-devel
0 aktualisiert, 4 neu installiert, 0 zu entfernen und 20 nicht aktualisiert.
Es müssen 163 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 1 124 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] j
Holen:1 https://dl.winehq.org/wine-builds/ubuntu focal/main i386 wine-devel-i386 i386 6.7~focal-1 [78,9 MB]
Holen:2 https://dl.winehq.org/wine-builds/ubuntu focal/main amd64 wine-devel-amd64 amd64 6.7~focal-1 [82,2 MB]
Holen:3 https://dl.winehq.org/wine-builds/ubuntu focal/main amd64 wine-devel amd64 6.7~focal-1 [1 932 kB]     
Holen:4 https://dl.winehq.org/wine-builds/ubuntu focal/main amd64 winehq-devel amd64 6.7~focal-1 [1 936 B]    
Es wurden 163 MB in 2 min 0 s geholt (1 355 kB/s).                                                            
[...]
I had to move away my .wine directory because it was 64bit and made a fresh additional 32bit wineprefix. (This does not damage my PlayOnLinux installation, which is independent and stores all its own Windows directories under .PlayOnLinux/wineprefix)

Code: Select all

co_windler@Juchhe:~$ WINEARCH=win32 WINEPREFIX=/home/co_windler/.wine/ winecfg
wine: WINEARCH set to win32 but '/home/co_windler/.wine' is a 64-bit installation.
co_windler@Juchhe:~$ WINEARCH=win32 WINEPREFIX=/home/co_windler/.wine32/ winecfg
wine: created the configuration directory '/home/co_windler/.wine32'
[...]
co_windler@Juchhe:~$ ls .wine*
.wine:
dosdevices  drive_c  system.reg  userdef.reg  user.reg  winetricks.log

.wine32:
dosdevices  drive_c  system.reg  userdef.reg  user.reg
co_windler@Juchhe:~$ mv .wine .wine64
co_windler@Juchhe:~$ mv .wine32 .wine
The Picture Publisher 8 directory copied from PlayOnLinux does not run by missing DLLs when opened by explorer.exe or entering "wine pp80.exe". So I had to open "wine explorer.exe", navigate to the actual installer picpub8.exe and install it from there. Then I navigated to pp80.exe to start it.

Opening within PP8 the broken file requester shows in wine this error:

Code: Select all

Unhandled exception: page fault on read access to 0x04244cd5 in 32-bit code (0x7ddb1596).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:7ddb1596 ESP:0021cc60 EBP:0021ced8 EFLAGS:00210206(  R- --  I   - -P- )
 EAX:6ed26e00 EBX:0021dce8 ECX:04244c8d EDX:078c8d78
 ESI:09b00ae0 EDI:0021cc84
Stack dump:
0x0021cc60:  6ed26e00 078c8d78 00000000 0021cc84
0x0021cc70:  00220094 0021cc90 7d7ce14d 7d8df000
0x0021cc80:  078c8d78 f7dfbb43 7d8df000 7d7c4929
0x0021cc90:  00220094 00000002 0021ccc8 70ba810c
0x0021cca0:  00000001 f7bbfcf0 001301c3 077d0000
0x0021ccb0:  f7bb8790 00000001 0021cce0 0000006d
Backtrace:
=>0 0x7ddb1596 in shell32 (+0xa1596) (0x0021ced8)
  1 0x7ddb2069 in shell32 (+0xa2068) (0x0021cf58)
  2 0x6edab73c EntryPoint+0xffffffff() in user32 (0x0021cf98)
  3 0x6edabdf7 EntryPoint+0xffffffff() in user32 (0x0000004e)
  4 0x6edad329 EntryPoint+0xffffffff() in user32 (0x0021d4e4)
  5 0x6edae633 EntryPoint+0xffffffff() in user32 (0x0021d4e4)
  6 0x492da0cd EntryPoint+0xffffffff() in mgxbrwsr (0x0021d518)
  7 0x6edab73c EntryPoint+0xffffffff() in user32 (0x0021d548)
  8 0x6edabdf7 EntryPoint+0xffffffff() in user32 (0x0000004e)
  9 0x6edac906 EntryPoint+0xffffffff() in user32 (0x6edb7068)
  10 0x6edae34b EntryPoint+0xffffffff() in user32 (0x6edb7068)
  11 0x6ed60e71 EntryPoint+0xffffffff() in user32 (0x0021dce8)
  12 0x6ed65fec EntryPoint+0xffffffff() in user32 (0x7ffc2000)
  13 0x6ed66244 EntryPoint+0xffffffff() in user32 (0x0021dbe8)
  14 0x005d8ab2 EntryPoint+0xffffffff() in comctl32 (0x078c6618)
  15 0x005d9d05 EntryPoint+0xffffffff() in comctl32 (0x00000000)
  16 0x005dc398 EntryPoint+0xffffffff() in comctl32 (0x00000001)
  17 0x005dcba0 EntryPoint+0xffffffff() in comctl32 (0x0021ddb8)
  18 0x005e6c1e EntryPoint+0xffffffff() in comctl32 (0x0021e128)
  19 0x005eeef8 EntryPoint+0xffffffff() in comctl32 (0x0021e128)
  20 0x6edab73c EntryPoint+0xffffffff() in user32 (0x0021e168)
  21 0x6edabdf7 EntryPoint+0xffffffff() in user32 (0x0000000f)
  22 0x6edae423 EntryPoint+0xffffffff() in user32 (0x6edb6e88)
  23 0x6ed69f41 EntryPoint+0xffffffff() in user32 (0x0021e2c8)
  24 0x6ed2f0e7 EntryPoint+0xffffffff() in user32 (0x0021e428)
  25 0x6ed2fa04 EntryPoint+0xffffffff() in user32 (0x00000001)
  26 0x6ed2fcbc EntryPoint+0xffffffff() in user32 (0x0021e4b8)
  27 0x6ed2fd11 EntryPoint+0xffffffff() in user32 (0x0021e4f8)
  28 0x00335cfd EntryPoint+0xffffffff() in comdlg32 (0x0021e650)
  29 0x00335db7 EntryPoint+0xffffffff() in comdlg32 (0x0021e650)
  30 0x00341b03 EntryPoint+0xffffffff() in comdlg32 (0x0021e650)
  31 0x4930b8e0 in mgxbrwsr (+0x3b8df) (0x6ed9b8c0)
  32 0xfff0e483 (0x04244c8d)
0x7ddb1596: call	*0x48(%ecx)
Modules:
Module	Address			Debug info	Name (58 modules)
PE	  330000-  58a000	Dwarf           comdlg32
PE	  590000-  a12000	Dwarf           comctl32
PE	  a20000-  ea4000	Deferred        ole32
PE	 6070000- 608e000	Deferred        cico
PE	 7250000- 727f000	Deferred        wintab32
PE	 7280000- 728b000	Deferred        tbar16b
PE	 7290000- 729a000	Deferred        tbar16c
PE	 72a0000- 72b1000	Deferred        tbar24c
PE	 a030000- a07a000	Deferred        mgxfma
PE	 a080000- a094000	Deferred        mgxfmar
PE	10000000-10139000	Deferred        ppres
PE	43240000-43512000	Deferred        pp80
PE	43640000-4365b000	Deferred        mgxfrm30
PE	43a40000-43a84000	Deferred        mgxbm30
PE	44010000-4401c000	Deferred        lfcal80n
PE	44020000-44067000	Deferred        lfcmp80n
PE	44070000-44085000	Deferred        lffax80n
PE	44090000-440f4000	Deferred        lffpx7
PE	44100000-4411b000	Deferred        lffpx80n
PE	44130000-44140000	Deferred        lfica80n
PE	44140000-4414c000	Deferred        lfimg80n
PE	44150000-4415d000	Deferred        lflmb80n
PE	44160000-4416c000	Deferred        lfmac80n
PE	44180000-4418d000	Deferred        lfpct80n
PE	44200000-44221000	Deferred        lftif80n
PE	44240000-44258000	Deferred        ltfil80n
PE	44280000-442ee000	Deferred        ltkrn80n
PE	45160000-4516b000	Deferred        dll32
PE	45250000-4529b000	Deferred        pcdlib32
PE	453f0000-45411000	Deferred        lfkodak
PE	492d0000-49349000	Export          mgxbrwsr
PE	5f400000-5f4ed000	Deferred        mgx42
PE	61740000-6182c000	Deferred        advapi32
PE	61d00000-6211a000	Deferred        actxprxy
PE	62fc0000-631f2000	Deferred        rpcrt4
PE	63480000-6349c000	Deferred        version
PE	63bc0000-63c02000	Deferred        shcore
PE	64a40000-64b5e000	Deferred        shlwapi
PE	64ec0000-652a8000	Deferred        oleaut32
PE	68500000-6864f000	Deferred        combase
PE	68700000-6878e000	Deferred        uxtheme
PE	697c0000-69a10000	Deferred        ddraw
PE	6a280000-6a4c9000	Deferred        msvcrt
PE	6bc00000-6bca1000	Deferred        sechost
PE	6bcc0000-6bea4000	Deferred        setupapi
PE	6c9c0000-6cf46000	Deferred        gdi32
PE	6ed00000-6f394000	Dwarf           user32
PE	70940000-70997000	Deferred        mpr
PE	70b40000-70df4000	Deferred        ucrtbase
PE	71200000-71248000	Deferred        imm32
PE	7a840000-7a844000	Deferred        opengl32
PE	7b000000-7b2f9000	Deferred        kernelbase
PE	7b600000-7b91f000	Deferred        kernel32
PE	7bc00000-7be97000	Deferred        ntdll
PE	7c790000-7c794000	Deferred        wined3d
PE	7d940000-7d944000	Deferred        winex11
PE	7dd10000-7e5e7000	Export          shell32
PE	7e6f0000-7e6fb000	Deferred        winspool
Threads:
process  tid      prio (all id:s are in hex)
00000020 start.exe
	00000024    0
00000038 services.exe
	0000003c    0
	00000040    0
	0000004c    0
	00000070    0
	00000088    0
	000000c8    0
	000000dc    0
00000044 winedevice.exe
	00000048    0
	00000054    0
	00000058    0
	0000005c    0
00000060 plugplay.exe
	00000064    0
	00000074    0
	00000078    0
	0000007c    0
	00000098    0
00000068 explorer.exe
	0000006c    0
	000000ac    0
	000000b0    0
	0000010c    0
	00000118    0
	0000011c    0
	00000120    0
00000080 winedevice.exe
	00000084    0
	0000008c    0
	00000090    0
	000000a0    0
	000000a4    0
	000000a8    0
	000000b8    0
000000c0 svchost.exe
	000000c4    0
	000000cc    0
	000000d0    0
000000d4 rpcss.exe
	000000d8    0
	000000e0    0
	000000e4    0
	000000e8    0
	000000ec    0
	000000f0    0
	00000108    0
	000001c0    0
	000001d0    0
000000f8 conhost.exe
	000000fc    0
00000100 explorer.exe
	00000104    0
	00000124    0
000001b4 (D) C:\Program Files\Micrografx\Picture Publisher 8\pp80.exe
	000001b8    0 <==
	000001bc    0
	000001c8    0
	000001cc    0
	000001d8    0
	000001e4    0
System information:
    Wine build: wine-6.7
    Platform: i386
    Version: Windows 98
    Host system: Linux
    Host version: 5.4.0-72-lowlatency
terminal output:

Code: Select all

co_windler@Juchhe:~$ wine pp80.exe
0144:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0144:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
014c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
014c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0154:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0154:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
015c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
015c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0154:fixme:reg:RegQueryInfoKeyA security argument not supported.
0154:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION
0154:fixme:reg:RegQueryInfoKeyA security argument not supported.
0154:fixme:file:NtLockFile I/O completion on lock not implemented yet
wine: Unhandled page fault on read access to 04244CD5 at address 7DDB1596 (thread 0154), starting debugger...
0178:fixme:reg:RegQueryInfoKeyA security argument not supported.
0180:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0180:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0178:fixme:reg:RegQueryInfoKeyA security argument not supported.
0178:fixme:reg:RegQueryInfoKeyA security argument not supported.
0178:fixme:reg:RegQueryInfoKeyA security argument not supported.
0178:fixme:reg:RegQueryInfoKeyA security argument not supported.
0178:fixme:reg:RegQueryInfoKeyA security argument not supported.
co_windler@Juchhe:~$ 0090:err:rpc:I_RpcReceive we got fault packet with status 0x1c010003
Clicking on the blur/sharpen/brighten/darken tool shows this error:

Code: Select all

Unhandled exception: page fault on read access to 0x000004f4 in 32-bit code (0x5f40331f).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:5f40331f ESP:0021e774 EBP:00000000 EFLAGS:00210246(  R- --  I  Z- -P- )
 EAX:00000500 EBX:00000000 ECX:00000100 EDX:00000000
 ESI:00000018 EDI:00000018
Stack dump:
0x0021e774:  00000018 00000000 00000000 433cf399
0x0021e784:  00000100 0021e79c 00000000 00000000
0x0021e794:  434f9f58 014b6498 7bc29029 7bc27f93
0x0021e7a4:  00000002 01480000 7bc29029 01480094
0x0021e7b4:  00000002 01480000 7bc29029 01480094
0x0021e7c4:  00002a51 00000000 00000000 014b3818
Backtrace:
=>0 0x5f40331f EntryPoint+0xffffffff() in mgx42 (0x00000000)
0x5f40331f EntryPoint+0xffffffff in mgx42: cmpl	$1,0xfffffff4(%eax)
Modules:
Module	Address			Debug info	Name (55 modules)
PE	  330000-  58a000	Deferred        comdlg32
PE	  590000-  a12000	Deferred        comctl32
PE	  a20000-  ea4000	Deferred        ole32
PE	 6070000- 608e000	Deferred        cico
PE	 7250000- 727f000	Deferred        wintab32
PE	 7280000- 728b000	Deferred        tbar16b
PE	 7290000- 729a000	Deferred        tbar16c
PE	 72a0000- 72b1000	Deferred        tbar24c
PE	10000000-10139000	Deferred        ppres
PE	43240000-43512000	Deferred        pp80
PE	43640000-4365b000	Deferred        mgxfrm30
PE	43a40000-43a84000	Deferred        mgxbm30
PE	44010000-4401c000	Deferred        lfcal80n
PE	44020000-44067000	Deferred        lfcmp80n
PE	44070000-44085000	Deferred        lffax80n
PE	44090000-440f4000	Deferred        lffpx7
PE	44100000-4411b000	Deferred        lffpx80n
PE	44130000-44140000	Deferred        lfica80n
PE	44140000-4414c000	Deferred        lfimg80n
PE	44150000-4415d000	Deferred        lflmb80n
PE	44160000-4416c000	Deferred        lfmac80n
PE	44180000-4418d000	Deferred        lfpct80n
PE	44200000-44221000	Deferred        lftif80n
PE	44240000-44258000	Deferred        ltfil80n
PE	44280000-442ee000	Deferred        ltkrn80n
PE	45160000-4516b000	Deferred        dll32
PE	45250000-4529b000	Deferred        pcdlib32
PE	453f0000-45411000	Deferred        lfkodak
PE	5f400000-5f4ed000	Export          mgx42
PE	61740000-6182c000	Deferred        advapi32
PE	61d00000-6211a000	Deferred        actxprxy
PE	62fc0000-631f2000	Deferred        rpcrt4
PE	63480000-6349c000	Deferred        version
PE	63bc0000-63c02000	Deferred        shcore
PE	64a40000-64b5e000	Deferred        shlwapi
PE	64ec0000-652a8000	Deferred        oleaut32
PE	68500000-6864f000	Deferred        combase
PE	68700000-6878e000	Deferred        uxtheme
PE	697c0000-69a10000	Deferred        ddraw
PE	6a280000-6a4c9000	Deferred        msvcrt
PE	6bc00000-6bca1000	Deferred        sechost
PE	6bcc0000-6bea4000	Deferred        setupapi
PE	6c9c0000-6cf46000	Deferred        gdi32
PE	6ed00000-6f394000	Deferred        user32
PE	70940000-70997000	Deferred        mpr
PE	70b40000-70df4000	Deferred        ucrtbase
PE	71200000-71248000	Deferred        imm32
PE	7a840000-7a844000	Deferred        opengl32
PE	7b000000-7b2f9000	Deferred        kernelbase
PE	7b600000-7b91f000	Deferred        kernel32
PE	7bc00000-7be97000	Deferred        ntdll
PE	7c690000-7c694000	Deferred        wined3d
PE	7d8e0000-7d8e4000	Deferred        winex11
PE	7dd10000-7e5e7000	Deferred        shell32
PE	7e6f0000-7e6fb000	Deferred        winspool
Threads:
process  tid      prio (all id:s are in hex)
00000020 start.exe
	00000024    0
00000038 services.exe
	0000003c    0
	00000040    0
	0000004c    0
	00000070    0
	00000088    0
	000000c8    0
	000000dc    0
00000044 winedevice.exe
	00000048    0
	00000054    0
	00000058    0
	0000005c    0
00000060 plugplay.exe
	00000064    0
	00000074    0
	00000078    0
	0000007c    0
	00000098    0
00000068 explorer.exe
	0000006c    0
	000000ac    0
	000000b0    0
00000080 winedevice.exe
	00000084    0
	0000008c    0
	00000090    0
	000000a0    0
	000000a4    0
	000000a8    0
	000000b8    0
000000c0 svchost.exe
	000000c4    0
	000000cc    0
	000000d0    0
000000d4 rpcss.exe
	000000d8    0
	000000e0    0
	000000e4    0
	000000e8    0
	000000ec    0
	000000f0    0
	0000010c    0
000000f8 conhost.exe
	000000fc    0
00000100 (D) C:\Program Files\Micrografx\Picture Publisher 8\pp80.exe
	00000104    0 <==
	00000108    0
	00000110    0
	0000011c    0
System information:
    Wine build: wine-6.7
    Platform: i386
    Version: Windows 98
    Host system: Linux
    Host version: 5.4.0-72-lowlatency
terminal output:

Code: Select all

co_windler@Juchhe:~$ wine pp80.exe
0034:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0034:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0064:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0064:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
006c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
006c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
005c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
005c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
002c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
002c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0024:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0024:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
00fc:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
00fc:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0104:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0104:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0104:fixme:reg:RegQueryInfoKeyA security argument not supported.
0104:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION
wine: Unhandled page fault on read access to 000004F4 at address 5F40331F (thread 0104), starting debugger...
0118:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0118:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0118:err:dbghelp:pe_load_dbg_file Couldn't find .DBG file "MGX42.dbg" (L"C:\\Program Files\\Micrografx\\Picture Publisher 8")
After a while wine (already closed?) tends to randomly throw this error:

Code: Select all

co_windler@Juchhe:~$ 0090:err:rpc:I_RpcReceive we got fault packet with status 0x1c010003
another small bug:

The reason why you can not start to paint on a new canvas after a fresh install of PP8 and PP7 is that it starts with the brush as "sponge" with mixing mode "saturation" (which draws nothing). (My version is German language so the exact displayed words may differ.) On VirtualBox Win98SE a fresh PP8 install (if I remember well) comes up with the default brush mode "massive" and mixing mode "(normal)" in that you can directly start to paint (black on white) after clicking the brush tool. This may be an initialization bug in WINE e.g. causing allocated blank memory to have different content.

Post Reply