exeCute: smooth integration of exe and bat files

exeCute allows opening exe files as if they were native Linux applications, silently selecting the right emulator and configuration for each case.

Basically it's s switch. If the file is 16-bit it runs it as a DOS executable, otherwise as a Windows application.

So you don't have to worry what kind of exe it is, it will just open.

The AUR package is "execute-git". Feel free to provide any feedback, this is my first AUR software :stuck_out_tongue:

Also I don't know if this is the appropriate section to post this. Feel free to change it if you wish.

6 Likes

So the app has all the tricks needed for certain applications it can apply on demand?

Seems like a nice little helper, but I struggle to understand what your intention was to make it.

I see it depends on 2 other AUR packages and one of them is available in the repos - dosbox
Is there a need for the svn version?

Are you planning to make some kind of compatible application list?

Launching DOS games takes more fritz than needed. Applications start windowed, how to maximize the window is generally not obvious, the window doesn’t close after exiting, the user doesn’t know what scaler is appropiate, and launching the game involves typing commands or making hard to craft shortcuts.

Also DosBox usually fails to launch when done within Wine, and because exes share the same mime type, they cannot be associated independently to Wine and DosBox. You have to manually select the appropriate emulator each time.

No, it’s just a nice consistent way to combine the functionalities of DosBox and Wine in a single launcher. So you can juggle game exes without having to worry if it’s of certain type of the other, or how to configure DosBox.

The regular one crashed a game I tested, where the SVN doesn’t. The regular one seems mostly abandoned, it hasn’t seen a stable release for many many years.

If it works either on DosBox or Wine, it works out of the box on exeCute.

3 Likes

Moved to #showcase

Why does it need q4wine?

Please see the VCS package guidelines, especially the pkgver() function section.

# Maintainer: Your Name <youremail at domain dot com>
pkgname=execute-git
pkgver=r11.1bc0822
pkgrel=1
pkgdesc="Opens exe files as if they were native Linux applications, silently selecting the right emulator and configuration for each case"
arch=("x86_64")
url="https://gitlab.com/es20490446e/exeCute"
license=('GPL3')
depends=('dosbox-svn' 'q4wine')
makedepends=('git')
optdepends=('wine-mono' 'wine-gecko')
provides=("${pkgname%-git}")
conflicts=("${pkgname%-git}")
source=("${pkgname%-git}::git+https://gitlab.com/es20490446e/exeCute")
sha256sums=('SKIP')

pkgver() {
	cd "$srcdir/${pkgname%-git}"
	printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

package() {
	cd "$srcdir/${pkgname%-git}"
	./installer -install "$pkgdir/"
}
3 Likes

It includes an icon to winecfg, which allows setting text size. I consider that a basic feature.

Check MAKEPKG now :+1:

I also have included a couple of interesting tools, BUILD and PUBLISH. So to have quick changeovers.

Then wine should be in depends and q4wine should be in optdepends as it’s not required.

Better, but there’s still a few things:

  • It’s unnecessary to use a shebang at the top. Notice I executed the installer with a ./
  • Custom variables are unnecessary here. If used at all, they should be preceded by an underscore; i.e., ${_name}. I used "${pkgname%-git} as the folder so it would be named execute instead of exeCute.
  • The pkgver function should be before package

Huh? Those files aren’t called by the PKGBUILD, what are they doing there? I’m too tired to look more closely at them now. No clue what “quick changeovers” have to do with anything.

Sorry, but from here we will have to agree to disagree! Everything I do is for a reason.

Take this as specimen of why I let my employees decide the implementation details by themselves. Just for fun:

Not required for the software to function, but for basic functionality.

The goal of my software is making computing as easygoing as possible. If I make an application that automatically chooses which emulator to launch is for making it easy for a noob to use it.

So only installing Wine, and forcing the noob to type “winecfg” in a terminal for getting Windows’ fonts to be usable, because they being minuscule by default, is a no brainer. It defeats the goal of the software.

I don’t care about how the software is organised, I care about the service it provides. I care about the usage process, the goal, and the context.

It tells the text editor to highlight as if was Bash, so the text gets easier to read.

If something has to be changed, in only needs to be changed in one place.

Since they are tested not to conflict, and they are unlikely to do so, it really doesn’t matter. It just adds complexity.

It doesn’t matter, as the folder is deleted after build nowadays. Making the name larger does nothing.

package seems more relevant than pkgver to somebody looking into the file, so that’s why the order.

BUILD instantly builds the package, so you can test it. PUBLISH instantly uploads the changes to the AUR.

It means doing the opposite than Arch, automating any repetitive task so you have to think as little as possible about them.

It means assuming the default, till stated otherwise.

It also tells “noobs” that this is a bash script they should make executable and run in a terminal.

But it’s the “standard” for AUR PKGBUILD’s.

Ofcourse, but it’s about consistancy.

Well, the pkgver() function needs to be run before the package() function. Again. It’s a PKGBUILD standard. In a PKGBUILD it’s not about readability, but about how makepkg executes the functions.

So they are only for you to use, then don’t include them in the source. Only include stuff that gets used by the PKGBUILD.

2 Likes

Install gtksourceview-pkgbuild and you’ll have PKGBUILD highlighting in gedit / xed, etc. Even without that, you can change it from Plain Text to SH and save the file.

Right, variables are helpful. I said custom variables were unnecessary in this case.

As @Strit mentioned, we’re talking about Arch package guidelines, not how you write your own software and philosophy.

Isn’t that potentially dangerous?
If I understand this correctly, with your tool you just have to click on whichever .exe and the program is immediately started whether in DosBox or Wine?

@Strit @Yochanan Basically I disagree with these guidelines.

As dangerous as launching exes with Wine itself, which is as dangerous as launching a program in user-space.

You are in your right to, but be aware that it can be pulled off AUR because of it.

1 Like

These guidelines are there for a reason, and they’re consistent and very easy to implement.

So?. You are free to do so, but you still stick to them. whether you like them or not. It makes it easier for other people to read and follow. Based on what this software does, you’re all about making things easier for people, right?

I have fixed the variables problem, by starting them with uppercase letters.

Support for opening bat files added.

What about .vbs files execution??
Does it support?

It doesn't right now.

Why do you feel that's important?