Opened 10 years ago

Closed 10 years ago

#782 closed defect (invalid)

Build Application still creates a .app bundle on Windows

Reported by: ender2012 Owned by:
Priority: normal Milestone:
Component: Cocotron Version: trunk
Keywords: Cc:


When executing build-application on windows instead of creating a .exe and a resource folder, build-applicaiton creates .app bundle which contains the .exe, the cocoa dll and the resource folder. It would be much better and more in line with the Windows way of doing things if build-application created a .exe file and a resource file without the .app bundle.

Change History (1)

comment:1 Changed 10 years ago by gb

  • Resolution set to invalid
  • Status changed from new to closed

Cocoa and Cocotron use .app bundles so that an application and the runtime can use NSBundle methods to find and load frameworks, libraries, and other resources. In Cocotron, the executable and Cocotron .dlls are in the same directory, which means that the dlls can be found without either modifying the PATH environment variable or installing the dlls in a global location (where they may conflict with other installed versions of themselves.)

Most Windows programs are installed via an installer program; their components are scattered all over the filesystem. Users generally don't navigate through the file system to find an executable to launch; they invoke programs via shortcuts (links) in the Start menu, on the desktop, and elsewhere.

Double-clicking on a .app bundle on Windows doesn't launch the application. Double-clicking on a shortcut to the executable inside the .app bundle does launch the application, which would then be able to actually find the resources that it uses. A shortcut to an executable file can be created manually in Windows Explorer by right-clicking on the executable and choosing the obvious menu option. Installer programs such as those generated by NSIS ( can automate the shortcut-creation process. Once appropriate shortcuts have been created, there's no reason for end users to know or care about how the application and its resources are packaged (though developers who have some understanding of the issues might be expected to benefit from that understanding.)

Note: See TracTickets for help on using tickets.