3

I wanted to create a shorcut for c:\windows\system32\more.com file in Desktop using ctrl+shift and drag and drop, and it silently ignored by not creating anything, then I decided to drag and drop it into a folder in my desktop and got this alert:

Windows could not create the shortcut. check to see if the disk is full.

I have 157 GB of free disk space and I tested it on other .com files (format.com, tree.com etc) as well, and the result was the same. Then I used mklink instead to create a symlink, and it worked, so I am wondering why it is impossible to create shortcuts for .com files in Windows ?

PS:

I am using Windows 8.1 64-bit operating system.

  • What you are attempting makes no sense: more.com is a 16 bit dos program that reads from stdin and writes to stdout, pausing after each screen full. Running it from a shortcut would give it no input, so it would have nothing to do. – psusi Jun 17 '15 at 1:01
3

I think you triggered a glitch, perhaps. As *.COM extension is from MS-DOS and only for 16bit binaries, 32bit Windows created a PIF shortcut for those files which would trigger compatibility layer to set up the 16bit-related environment. However, this part does not exist on 64bit Windows as 16bit executables are old enough and there are many alternatives to run them; DOSBOX for example.

However, it seems that the routine to detect this situation still exists on x64 Windows and gets triggered by targeting a *.COM file, whilst the compatibility layers are all gone!

You can check by yourself that the attempt to create a shortcut to a COM file still produces a PIF file:

  1. Create a new empty folder.
  2. Copy any COM file you'd like to test. Even you can rename any file to *.COM.
  3. On the folder, right click and select new-shortcut.
  4. Enter the full path of your test COM file and click "finish"
  5. It'll say that "unable to create shortcut" but the shortcut is actually made.
  6. See the properties of the new shortcut - it's PIF.

However, as x64 Windows does not have 16bit compatibility layer any more, that PIF cannot run and cannot be set up correctly. It is naturally believed that the logic to produce PIF files to COM should be removed as well but by some reason it is not done yet. What I can guess about the reason is.. since it's really rare to use COM file on x64 Windows, it had very low priority to fix.

So, what are those *.COM files in Windows folder then? They are actually 64bit "EXE" file format executables but renamed to *.COM for old batch scripts.

It is also true that the shortcut to a COM file may cheat users to run a malware so that MS intentionally blocked this, but it's still possible to attach a renamed COM file (which is originally an EXE file) directly on an email or something anyway, and it's still also possible to create a shortcut to a regular EXE file and then rename it to *.COM. So I don't think the security issue was the main reason to make Windows do this strange behaviour. If it was for the security issue and intentional, it would display a proper error/warning message.

-1

I would guess that this is security measure as disguising .com files is a general tactic of malware creators. A shortcut could be disguised to look like a word document in order to goad a user into clicking it and executing malicious code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy