Using TinyTask Compile EXE to Make a Standalone Macro

Press it with nothing in memory and you get a message telling you so.

The dialog says nothing has been recorded and points you at the blue button to start. That is the record button. Recording basics are covered in the how to use TinyTask guide.

So the order is fixed. Record first, or open a saved recording, and only then compile.

Press .exe. A save dialog opens.

Give the file a name and pick a folder. The name matters more than you might think. It is what the person receiving it will see. It is also what you will look for in Task Manager if you need to end it.

The file type in that dialog is set to a program file, not a recording. The window title still shows the recording you are compiling from, which is a useful check that you are building from the right macro.

When it finishes, the program shows a report. Read it, because it contains the answer to a question most guides get wrong.

The report confirms the compile succeeded, gives the full path of the file it wrote, and shows its size. Below that, under Program attributes, it lists the execution speed and the repeat loops that were written into the file.

That settles it. Your speed and loop settings are baked into the compiled macro. Whatever was active when you pressed the button is what the standalone file will do, permanently. Change either setting and you have to compile again.

So check both before you compile. If the report shows a repeat count you did not intend, you have just built a macro that will do that on someone else's machine. The settings themselves are covered on the playback speed and loops pages.

A single executable that replays your recording. Nothing else is required to run it.

No installer. No runtime. No copy of TinyTask on the target machine. No settings file needed alongside it, as far as we have seen, though we have not yet tested that on a machine that has never had the program on it.

The compiled file is an output, not a source. Keep the recording. Save the .rec file before or after you compile, because that is the version you can open again and replay inside the program. Treat the compiled file the way you would treat a printed copy of a document. What a recording file is and where it lives is covered on the rec files page.

Everything the original could not do, it still cannot do. Compiling changes the packaging, not the capability.

It has no logic. It cannot check whether a window is open, wait for something to appear, or take a different path when the screen looks different. It replays a fixed sequence.

It is still coordinate based. It clicks screen positions. On a machine with a different resolution, a different scaling setting, or windows arranged differently, it will click the wrong places. This is the single biggest limitation of sharing a compiled macro with someone else, and it is why a macro that works perfectly for you can be useless to a colleague.

It cannot be edited. There is no way back from a compiled file to something you can adjust. If you lose the recording, you rebuild the macro from scratch.

It has no scheduler. Compiling does not make a macro run on a timer. For that you need Windows Task Scheduler pointing at the compiled file, which is covered on the scheduling page.

The report tells you, in the same window, every time you compile.

There is no fixed answer to publish, and the sites that print one have invented it. A compiled macro is the playback engine plus your recording, so a longer recording makes a larger file. For a short macro the result is close to the size of the program itself.

Read the number in your own report. It is the only figure that describes your file.

The stop keys work. Pause and ScrollLock end a compiled macro the same way they end a playback inside the program.

We tested that on a compiled file rather than assuming it, because it is the thing you most need to know when a standalone macro with a high repeat count gets away from you. Nobody else documents it.

Task Manager is the fallback. Press Ctrl+Alt+Del, find the process by the file name you gave it, and end it. The stop playback page covers both routes.

This is the part almost nobody mentions, and it is the most valuable fact on this page.

The developer states plainly that macros you compile into executables can be distributed and sold, with no royalties and no restrictions attached. What you build is yours.

That makes the feature genuinely useful for work. An onboarding routine you hand to a new colleague. A repetitive setup step packaged for a whole team. A small tool you charge for. None of that requires permission or a licence.

Two sensible habits go with that freedom. Tell people what your macro does before they run it, because an unexplained executable is an unreasonable thing to send anyone. And keep the recording, so you can fix it later. Our position on licensing and attribution across this site is set out on the credits page.

Your compiled macro is an unsigned executable, and Windows treats unsigned executables with caution.

They may see a SmartScreen warning saying Windows protected their PC. If they do, they click More info and then Run anyway. That is normal for any small program without a code signing certificate and it is not a sign that anything is wrong with your file.

They may also see nothing at all. We could not reproduce the warning on our own test machine, downloading fresh and running the file. SmartScreen decides case by case, using reputation signals we cannot see, so neither outcome is a fault.

Security software may also flag it. A program that sends synthetic mouse and keyboard input looks, to a scanner, quite a lot like a program you would not want on your machine. Why that happens and how to verify a file for yourself is covered on the safety page.

Say all of this to whoever you are sending it to, in advance. A warning that arrives unexplained looks like a virus. A warning you were told about looks like Windows doing its job.

Almost always the screen, not the file.

Different resolution, different scaling, a taskbar on a different edge, a window opening in a different position. Any of those and your fixed coordinates point somewhere else.

There are two ways to reduce the damage. Record with the target window maximised, so its position is at least predictable. And prefer keyboard steps over mouse clicks wherever you can, because a keyboard sequence does not care where anything is on screen. The wider set of causes is on the not working page.