View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001430OpenMPTGeneralpublic2021-03-02 20:002021-09-24 18:16
Reportermanx Assigned To 
PrioritylowSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product VersionOpenMPT 1.30.00.* (old testing) 
Target VersionOpenMPT 1.31 / libopenmpt 0.7 (goals) 
Summary0001430: decide how /shared should behave with non-matching architectures of OpenMPT.exe
Description

If a x86 OpenMPT.exe is started with /shared, should it transfer to a running amd64 OpenMPT.exe, or not? Should this be a setting?

TagsNo tags attached.
Has the bug occurred in previous versions?
Tested code revision (in case you know it)

Relationships

related to 0001123 resolvedmanx Provide unified multi-arch installer 
related to 0001429 resolved Force shared instance via INI setting 

Activities

manx

manx

2021-09-24 13:45

administrator   ~0004882

The simple solution would be to just leave things as they currently are for 1.30. That would be, any architecture executable does always transfer to the already running executable, regardless of architecture mismatch.
Saga Musix

Saga Musix

2021-09-24 18:16

administrator   ~0004883

Yeah, it definitely sounds like the easiest way to move forward now, and if people would prefer a different behaviour it can still be implemented later.

Issue History

Date Modified Username Field Change
2021-03-02 20:00 manx New Issue
2021-03-02 20:01 manx Relationship added related to 0001429
2021-03-02 20:01 manx Relationship added related to 0001123
2021-09-24 13:45 manx Note Added: 0004882
2021-09-24 18:16 Saga Musix Note Added: 0004883
2021-09-24 18:16 manx Target Version OpenMPT 1.30.01.00 / libopenmpt 0.6.0 (upgrade first) => OpenMPT 1.31 / libopenmpt 0.7 (goals)