Messages

1

Support and Feedback / Re: Bug in image viewer

« on: October 04, 2026, 15:27:07 »

Is there any restriction on image dimension in  WIC? I have some very tall images and all but one are displayed by image viewer:
610x10789 - OK
540x16635 - fails

I don't think it is metada problem because rewriting file using my favourite tool (exiftool) doesn't help.
WebView displays image correctly.

2

Support and Feedback / Re: Bug in image viewer

« on: October 03, 2026, 16:50:53 »

Microsoft reader is a bit to strict. yes reading a value that is expected as SHORT as LONG can be a problem. But only if the value read actual is larger then MAX SHORT value. and this value can only be 0-6

No, value can be even MAX_SHORT - 1. This is the best and most detailed documentation I am aware of:
https://exiftool.sourceforge.net/TagNames/EXIF.html#Compression
It was created in 2005 and is refined and updated for 21 years.

But I guess Microsoft just follow the spec very strict.

However for the next version.. If it fails to loading an image because of metadata.. It will retry loading it without metadata.

Kudos to Microsoft. They SHOULD be strict. Years ago they added their own "enhancenents" everywhere, making a mess in programming world. Glad they stopped.

If you accept the suggestion: please show at least warning informing user that his file is problematic. If not, even a red dot in menu area would be better than nothing.

3

Support and Feedback / Re: Bug in image viewer

« on: October 03, 2026, 04:50:12 »

[IFD1 (thumbnail)] at offset 64, 3 entries
  0x0103 Compression                  LONG      count=1     inline   (6,) <-- WRONG TYPE, expected SHORT
  0x0201 JPEGInterchangeFormat        LONG      count=1     inline   (106,)
  0x0202 JPEGInterchangeFormatLength  LONG      count=1     inline   (1891,)

All clear now. I simply misunderstood your previous post. I was looking for KEY 0x0103 as LONG while you meant its VALUE (6). So, your AI was right. Here they are:

00000a0  00  03  01  04  00  01  00  00  00  06  00  00  00  01  02  04
00000b0  00  01  00  00  00  6a  00  00  00  02  02  04  00  01  00  00


If someone is interested how to repair such files: as JPEG compression is lossy, we must re-write matadata only while leaving image data intact.

This command reads metadata and writes them back:
c:> exiftool -all= -tagsfromfile @ -all:all -unsafe -icc_profile  plomyki.jpg

The result is attached. Viewer shows it properly.

Thank you for your support. I definitely learned something new.

4

Support and Feedback / Re: Bug in image viewer

« on: October 02, 2026, 00:19:34 »

MC do not decode jpg it self.. MC is using WIC  (Windows Imaging Component) So I don't know if there is anything I can do about it.

So we can exclude MC itself. Problem lies either in WIC or in malformed file.

According to an AI analyze of the image
"The problem is its EXIF block (APP1, 2005 bytes). It contains a small thumbnail, and the thumbnail's Compression tag (0x0103) is written with type LONG instead of SHORT, which the EXIF spec requires."

Could you provide source of this information? I cannot reproduce it. There's no *long int* representation of 0x103 value in this file.

The command:
C:> hexdump -x plomyki.jpg

shows file content as 16-bits (short int) values. There are some "0103" values there, but no one has enough zeroes in their neighbourhood to form long int of this value.

As there may be not aligned longs in file, I also checked output of command:
C:> hexdump -X plomyki.jpg

This dumps file as bytes (2 hex digits, separated with double spaces). Searching for "03  01" sequences shows some results but again - there is not enough 00 bytes after them to form long int.

Besides, no software I have displays warning about malformed file. For example:
C:>exiftool -Compression -H plomyki.jpg

simply shows:
0x0103 Compression                     : JPEG (old-style)

without any warning about spec violation.

As this is my HI (Human Intelligence) analysis, I might have overlooked something. I am not JPEG expert.

5

Support and Feedback / Bug in image viewer

« on: September 30, 2026, 15:08:56 »

Attached I send an example of JPEG image which is not shown in viewer (F3), but EXIF info is read (at least partially).
Gimp shows more image info and displays this image properly.
Newest MC version: 16.6, build 3221.

6

Support and Feedback / Re: WebView problem

« on: September 13, 2026, 00:25:28 »

I dno't know.. WebView is a Microsoft component to show HTML in an application.. And used by lots and lots of apps..

In my system these "lots of apps" is exactly 1 app (besides MC).

Error 0x80080005 means "access denied". so something is blocking it.

Yes! I am the one to blame. About 3 years ago Microsoft tried aggressively to force me to use Edge browser so I searched for remedy. Found it here: https://www.sordum.org/9312/edge-blocker-v2-0/
As you see, it not only blocks Edge but WEbView as well.

Problem solved, thank you.

7

Support and Feedback / Re: WebView problem

« on: September 10, 2026, 22:26:05 »

In FileType configuration you can add external viewers for pdf. then it will open in that viewer instead.

I did it for PDFs, however personally I prefer external viewer for "Run" action (by pressing Enter on file name) and internal MultiFileViewer for View/F3.

Also if you remove WebView2Loader.dll from MC will fail to load webview and will fall back to old way and open it binary. (unless you have it already installed in the search path by another app)

No, it does not work this way. After renaming "WebView2Loader.dll" to "WebView2Loader.dll.sav" all internal file view stopped working. Just no action after pressing View/F3 (restart MC to see it). External viewers still work.

There is no error in the app log ?

There is, of course. For example: "2026-09-10 11:08:11.666 WebView2 failed while initializing the WebView2 controller (0x80080005). File: C:\Users\herbata\home\bin\node-v24.18.0-win-x64\README.md"

Might in future version add option to enabled what filetype webview will load for so they can be easily disbaled.

IMHO the best behaviour in this case is just  silently fall back to old way.

Could you tell why all this webview staff doesn't work for me?

8

Support and Feedback / WebView problem

« on: September 06, 2026, 02:04:18 »

Is there any way to tell MC *not* to use WebView?

When I click "Web View" button in MultiDataViewer, it freezes. I have to close and re-open it to bring it to live.
When I press View (F3) on PDF file, it is even worse: I get error message telling that WebView controller (whatever it is) is not found. I can't see PDF as bytes, ASCII, nothing at all, because WebView is apparently default viewer in this case.

9

Support and Feedback / Re: Weird file names display

« on: February 16, 2026, 19:55:06 »

nietrupek,

I've created some files. No problems.

Thank you for checking. Are you using File Manager look and feel or traditional one?

10

Support and Feedback / Re: Weird file names display

« on: February 16, 2026, 13:54:30 »

More likely it is some windows issue, Because the window text draw engine is loaded into each process that is rendering text in the Windows UI.

Sounds like a conspiracy theory...

But I can't check for that since I can't reproduce it

Why not? Each line of attached file contains a filename. Just do:
echo "anything" > "filename1"
echo "anything" > "filename2"
...
for each line, and you will get a set of files. See them in MC's panel. Maybe you'll see what I see.
Final note: from time to time MC displays them differently for no apparent reason.

11

Support and Feedback / Re: Weird file names display

« on: February 15, 2026, 06:23:44 »

MC just tell window to draw the unicode string. MC does not process., It is using Window built in support for drawing unicode strings.

So the problem is outside of MC's control, somewhere in external library.

Sorry, I have to revive this thread. The problem *is* somehow MC-related. No matter what font I use, MC distorts file names. Moreover, if I close MC and restart it, filenames are displayed differently.

The same filenames are displayed properly in all terminal-based apps I have at hand: cmd, Cygwin's bash or Power Shell. No matter what fonts I use. Modern apps like File manager, browsers, etc. all display filenames correctly, too.

12

Support and Feedback / Re: Weird file names display

« on: February 09, 2026, 09:15:34 »

MC just tell window to draw the unicode string. MC does not process., It is using Window built in support for drawing unicode strings.

So the problem is outside of MC's control, somewhere in external library.
And today, the same files are displayed properly. And my PC wasn't even turned off since yesterday...

You can't use zip for unicode filenames, zip is an legacy and old format. normally zip till convert filename to 7/8bit for current code page used, or to UTF-8 if enabled for zip.

Thanks for the explanation. I had no idea that zip is outdated.

13

Support and Feedback / Weird file names display

« on: February 08, 2026, 19:53:58 »

Attached I send MC's display of some "exotic" filenames (attachements, left panel). These files were created by Thunderbird, they are spam mails saved using EML format. System: Windows 10.

It is a security risk if "something" in filenames is able to manipulate MC's behaviour.

BTW, your built-in zip functionality changes filenames (2nd attachment, right panel). If it is documented and user may switch this feature on/off, then it is OK. If not, it is a bug.
For reference, the same files packed using external 7z application keep original file names intact (1st attachment, right panel).

ADDED: Sorry, I didn't see "[BUG] Unicode NOT work" topic, so this is basically a duplicate of it. But maybe attachments will be helpful. I am using one of typical Windows fonts (Consolas), so it is not the cause of the problem.

14

Support and Feedback / MC hangs when copying files

« on: February 26, 2025, 13:15:08 »

Actually the title is inaccurate. MC hangs *before* it starts copying files, producing empty (white) modal sub-window. This window has no controls, so it cannot be neither moved nor closed. Even worse, it is on top of other windows. Main MC window cannot be closed too as its child is modal.

All I can do is to use Task manager to forcefully kill MC. It does not close cleanly (directories in panels are not as they were while closing, etc.).

This happens once per day or two when I use MC for longer time.

MC x64, version 15.0, build 3072 dated Feb 9 2025 (please, please allow us to copy data form "About" window!)
Windows 10

There were no such problems in previous versions of MC.

15

Support and Feedback / Re: How to disable preview?

« on: December 25, 2023, 05:14:34 »

That's what I missed: "you have to click icon on toolbar". Sorry, my fault.
Apparently I turned it on somehow and didn't notice it.
So, you are perfectly right, Mathias. Thanks for clarification.

16

Support and Feedback / Re: How to disable preview?

« on: December 21, 2023, 20:55:02 »

Configuration - Manage Plug-ins and Extensions - uncheck "Preview Panel" - Save.

OMG! Thanks a lot!

I know it's late answer, but... I think the author of MC should think twice before he adds new feature turned ON by default. I lost a lot of time trying to find a way to turn off this feature. Do I have to check every new MC update to be safe from your suprises?

17

Feature Requests and Suggestions / Re: Refresh file info in a directory

« on: May 09, 2021, 18:57:00 »

Compile this:

Code: [Select]

#include <glob.h>
int main (void)
{
glob_t globbuf;
glob("*", GLOB_NOSORT, NULL, &globbuf);
return 0;
}
and link with standard Cygwin's DLL. Running resulting program in any directory does the trick. And I don't think that any hidden fopen() calls are involved.

18

Feature Requests and Suggestions / Refresh file info in a directory

« on: May 02, 2021, 12:44:12 »

Windows 10, local filesystem (C: drive).

When I download large file using browser, a temporary file (largefile.mp4.part) is created. MC shows this file with size of approx. 32kB. The file is growing, but its size is still shown as 32kB. Pressing F2 (or Refresh icon) does nothing. Also DIR command shows file size as 32kB.

But when I do one of the following:
- select file and press F3 (View file)
- use Cygwin's 'ls -l' command
proper file size is immediately shown in MC. DIR command also returns refreshed file size info.

Apparently MC's F3 command (and Cygwin's ls) do something that forces Windows to "wake up" and report proper file info to the caller.

Here's my feature request: change F2/Refresh to deal properly with situation described above.

19

Support and Feedback / Re: Huge fonts since last update

« on: December 17, 2020, 19:49:41 »

Second attachment that I sent also shows that content doesn't fit in window.
Just installed latest build and it is not fixed.

JK

20

Support and Feedback / Re: Huge fonts since last update

« on: December 15, 2020, 22:36:50 »

I've just installed latest build (Dec 04, 2020).

After setting all user-configurable fonts to 10 everything looks nice on my system (150% and 1920x1080).

Whatever you changed in last built, fonts are OK now. Thank you, Mathias.

JK

Still not consistent, I'm afraid. I didn't notice before. See attachments.

JK

21

Support and Feedback / Re: Huge fonts since last update

« on: December 10, 2020, 15:29:19 »

100% and 1920x1080.

No DPI scaling. strange. I see no issues in 100%.

I've just installed latest build (Dec 04, 2020).

After setting all user-configurable fonts to 10 everything looks nice on my system (150% and 1920x1080).

Whatever you changed in last built, fonts are OK now. Thank you, Mathias.

JK

22

Support and Feedback / Re: Huge fonts since last update

« on: December 03, 2020, 03:31:42 »

Sorry. I misspoke. It is the "Device Dropdown list" that I am referring to.
The font shrinks in size sometimes when making changes using the "Quick Look N Feel Setup".

Exactly.

It goes back to normal after quitting & restarting.

Same for me.

JK

23

Support and Feedback / Re: Huge fonts since last update

« on: December 01, 2020, 20:33:33 »

8 is just the recommended minimum in the list. You can enter any value in the edit box above the size

Oh my... Shame on me. Yes, it works, Thank you. 2 of 3 problems solved.

But I noticed something that apparently is a bug. To reproduce:

- Set Free Area to 10. Click OK, click Apply. Font is large, as expected.

:loop
- Set Free Area to 6. Click OK, click Apply.
- Watch carefully dropdown list font size.
- endloop

See what happens? While setting font size 6 (or 7 or few times, nothing should change, but actually dropdown list font shrinks for each iteration.

This may be the reason why people report microscopic font size sometimes.

Also there can't be a option for everything, There are already too many options. It turns inte option hell.

I agree. As a user I was sometimes lost when I started using MC and tried to change something. Still I am from time to time.

But the scaling things are going to be tweaked a bit more. However some things that works in 150% scaling looks bad in 225% scaling. so it is not easy to get right.

That's why I'm asking for possibility to turn off automatic gear box and switch to manual.

JK

24

Support and Feedback / Re: Huge fonts since last update

« on: December 01, 2020, 09:06:19 »

You might need to lower the font. set it to 6,   6 at 150% scaled should be around 8pt.
The Path area is not changed at all.. The default font is changed. it scaled already before.

Thanx for your reply.

I can't set font size to anything less than 8. It is minimum font size available on my system. See attached file.

It would be nice to have configuration option to turn off autoscaling until all problems with it will be resolved. It's like automatic gearbox - sometimes you need to turn it off.

JK

25

Support and Feedback / Re: Huge fonts since last update

« on: November 30, 2020, 21:22:50 »

freespace area will autoscale font according to scaling settings in Windows. So just make this font smaller in Explorer Panel settings

I have done it before asking here (see attached image area [4]).
Font are larger than before in areas marked [1,2,3].
BTW, the rightmost icon in area [3] after last update was pushed out of view. I had to enlarge MC window to see it again.

I have scaling set to 150% (screen size 15.6'', resolution 1920x1080 if that matters).

JK