Is there an alternative for Autorun.inf for a CD or DVD in Windows 7/8/8.1/10? I can't make it work in Win10 - autorun

Most of what I have found on this topic is really for Autorun.inf files for USB sticks.
Many folks say that feature was dropped for USB sticks when Win7 and later versions of Windows came along but it was kept for CDs and DVDs.
I have used the standard Autorun.inf code that I could find in several places on the Internet, but it does not work for the CDs that I have burned.
I can open a disk and look at the files on the disk and click on my .exe file and it launches and runs fine.
My Autorun.inf file just will not execute it when the CD is first loaded and run on my computer which is running Win10.
Is anyone still successful with running Autorun.inf files on CDs or DVDs on computers with Windows 7/8/8.1/10?
If so, how is the Autorun.inf file configured?
All I want to do is launch a .exe file that is in the root directory of the CD or DVD.
Is it required to have the line of code to specify where the icon can be found?
I am including that code but I wonder if it is required as well.

Related

Can't find previously downloaded files in WSL

I'm not very experienced in *nix operating systems and I'm trying to set up an embedded programming environment in WSL, but I'm getting hung up on basic issues. Last time I was working on this project I had downloaded some files (cargo and rustup, but that shouldn't matter), and I confirmed that they were there and working by getting the version number with -V.
After restarting my computer WSL doesn't recognize rustup or cargo as commands, and the folders don't show up with ls, even though they show up when I check for them in Windows Explorer.
The directory I've been working out of is %LOCALAPPDATA%\Packages\TheDebianProject.DebianGNULinux_76v4gfsz19hv4\LocalState\rootfs\home*user* which I'm pretty sure is the default. I’ve verified this by creating a .txt in WSL and finding it with Windows Explorer
Working on Windows 10 64-bit. I chose Debian for arbitrary reasons/ open to switching.
I’m not too worried about the files themselves, I just want to be able to avoid this in the future.
Firstly since you are new to WSL please be aware that the recommendations are to not under any situations edit or modify any Linux files inside of your %LOCALAPPDATA% folder using Windows apps or tools which includes moving files using file explorer. See this blog post from Microsoft https://devblogs.microsoft.com/commandline/do-not-change-linux-files-using-windows-apps-and-tools/ If you do you can see corruptions missing files and crashes.
I have no experience with cargo or rust but it sounds like you didnt update your .bashrc (start up script) with details needed to add things to the environment on start up.
There are a few things you can do
Use the history command to look back at what you did when you installed things
Use sudo find / -name rust to look for the executable in your system
When using ls remember that files/folders that begin with a dot are hidden so you need to use ls -al to see them in the terminal
I assume you followed this guide for installation (or similar). If you did not and are still having issues please detail how you installed things.

Appv V5.1 - some files are not sequencing correctly

I am trying to sequence an application in V5.1 that currently works fine in v4.6. I have tried to do the conversion and also do a brand new sequence but on both occasions, when the sequenced app is run it errors with "The program can't start because Vcl50.bpl is missing from your computer. Try reinstalling the program to fix the problem".
This file is installed to 'C:\Windows\System32' when I install the client along with a load of other .bpl files. These files are related to the BDE Administrator that it installs.
If I open the bubble for amendment the application works fine and I can see all the .bpl files in the 'C:\Windows\System32' folder.

Gamemaker Game EXE file won't load (game made 11years ago)

So I made a few gamemaker games about 11 years ago and tried to run the exe file.
When I run the exe file, nothing really happens just an error box pops up saying you can find out more here. And it points to 3 .tmp files located in the Temp folder on my computer.
Anyone know how to get these exe files working again?
The older versions of game maker games use an old runner that does not work with the newer versions of window (from Vista and up).
Using compatibilty mode does not fix this.
There is however a fix available that replaces the runner in the EXE with an updated one.
The tool was posted by Mark Overmars (the original creator of Game Maker) but the link in his topic is no longer active (the .zip does download but its an HTML page, not the actual tool).
http://gmc.yoyogames.com/index.php?showtopic=299895&p=2116603
It did work for me and using this program I was able to run a lot of older gm4 + games that I have played before on windows XP.
If its a must - you can always try to run it on an XP machine.
TL;DR:
There is a tool to make them work, I will upload it tonight.
EDIT: Turns out YoYoGames has the tool posted themselves;
http://help.yoyogames.com/attachments/token/lsj0pmbzqeu64hf/?name=GM_Convert_Game.zip
More information: http://help.yoyogames.com/hc/en-us/articles/216753218-Troubleshooting-Legacy-GameMaker
You can extract all the files to a directory, then drag your old .exe file onto the converter exe. It will then create a game_old.exe and game.exe and then you should be able to run the game.exe one.

dll can't be found but it is there

I have a W2K8 box running some automation software.
Once of the drivers that I need to load for it adds a dll into a sub-folder of the program (in Program Files (x86)).
When the program tries to load the driver it spits out an error that it can't find the file. The location that it is looking for the file is correct and if I browse to that location the file is definaelty there.
Other drivers that use similar techniology (i.e. dll's in that same folder) are working fine, in that they find there dll and load up.
If I install the software on a XP/Win7/W2k3 OS it all works fine for the driver in question.
Is there something funky that the OS is doing that is not making the file visible to the program. The account that the servive for this program is running under is an admin account, the same account that I am loggedin with on the console.
I am told that the drivers are all C++ based drivers if that makes any difference.
Thats for any leads
Mick
Just off hand, it sounds like a permissions issue. That the application in question doesn't have access to the Program Files folder. Is this something you have checked? If not, I would start there.

Same dll files in my computer is x64, but on another computer they are x86, strange

I have an program which has the dependencies of MSVCP100D.DLL and MSVCR100D.DLL, x64 version.
This is the screenshot of DependencyWalker in my computer:
When I copy this program to my friend's computer, it can't run since there are no such two files. Then I copied the 2 dll files to his computer.
But it reports some error when executing the program, and when I use dependency walker to check, I found a very strange thing. This is screenshot from him:
Why they are "x64" in my computer and "x86" in his computer? How to fix it?
Update
My friend's system is win7 x64 too.
Finally, after several hours, we fixed it. There are too many strange things.
First. My system is win7 x64.
Here take MSVCP100D.DLL for example. There are two different MSVCP100D.DLL in my computer, one in windows/system32, one in windows/SysWOW64. They have different sizes.
Look at the screenshots:
But in "everything" they have same sizes(even same modified date), that I thought they are the same.
Then I send the dll from system32 via an IM software called QQ.
I dragged the file from windoes/system32 which is 991K, but QQ displayed the size is "726K":
But, if I copy the file into another dir, e.g. D:\, then send it again, the size is correct "991K".
Finally, I copied these dll files into another dir, and package them into zip file, they are sent correctly, and the program run well on my friends' computer.