x64 Development

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
1,808
Reaction score
325
Points
83
We should make that a "to be investigated" issue/bug. It is interesting to investigate and create stable, but for now it is not that important I think.
As face's fix is absolutely sane the issue is minor (now).
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,363
Reaction score
429
Points
83
Website
users.kymp.net
I finally got the Orbiter to run in x64. The translation work to x64 for D3D9Client is mostly done and it's located in the trunk. The orbiter seems to work well but there are still somethings that need fixing and double checking. Any ideas what "DDEServer" is ? It seems to sscanf() a text string for pointers and then it creates an object handle based on the value it scanned. That's kinda odd. I have no idea what should be done with it.

I don't have much time during the weekend but I'll try to publish the changes early next week. Still have to figure out how to do that. I may need to dumb the files in a zip package and publish that.
 

Attachments

  • Q1.jpg
    Q1.jpg
    85.6 KB · Views: 46
  • Q2.jpg
    Q2.jpg
    68.1 KB · Views: 46
  • S3.jpg
    S3.jpg
    82.8 KB · Views: 46

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,399
Reaction score
304
Points
83
Website
orbit.medphys.ucl.ac.uk
Very nice! I'd never have dreamed that it would take less than a week to port Orbiter to 64-bit ...
Any ideas what "DDEServer" is ? It seems to sscanf() a text string for pointers and then it creates an object handle based on the value it scanned. That's kinda odd. I have no idea what should be done with it.
"DDE" stands for "direct data exchange." It is an old and probably obsolete protocol for inter-process communication. I used it a long time ago to have Orbiter pass data to Matlab to draw trajectories in real time. If I remember correctly, I basically implemented the whole thing one morning before giving a lecture at ESTEC to spice up the demo. I've never used it since, but I left it in because I thought it might come useful some time. If it causes problems I can take it out.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,399
Reaction score
304
Points
83
Website
orbit.medphys.ucl.ac.uk
I am currently pulling the change of data types from 32-bit only to 32/64-bit capable ones (e.g. INT_PTR instead of BOOL for callback function return types). This is so as to remove one of the obstacles of making the code compile both for 32 and 64-bit platforms with as little modification as possible, without breaking backward compatibility for the 32-bit version.

My concern is that there are a few instances where the change affects the API interface. For example in OrbiterAPI.h,
Code:
typedef struct {
    char *name;
    DWORD key;
    int (*msgproc)(UINT,UINT,WPARAM,LPARAM);
} MFDMODESPEC;
should become
Code:
typedef struct {
    char *name;
    DWORD key;
    LRESULT (*msgproc)(UINT,UINT,WPARAM,LPARAM);
} MFDMODESPEC;
Now, while int and LRESULT may be equivalent on 32-bit, they are not identical as far as C++ typechecking is concerned, correct? So I assume that the above would be a compatibility violation. Should I do this instead:
Code:
typedef struct {
    char *name;
    DWORD key;
#ifdef _WIN64
    LRESULT
#else
    int
#endif
 (*msgproc)(UINT,UINT,WPARAM,LPARAM);
} MFDMODESPEC;
It's rather ugly. The alternative would be to give up on the idea of a unified codebase for both 32 and 64-bit versions, and just apply the changes once the 64-bit branch has split off.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
4,768
Reaction score
1,241
Points
138
IMO, a x64 branch should be created just for the x64 changes, and the trunk (or master in git) should remain x86. All the x64 conversion work is done in the branch, without the need to keep x86 compatibility or to maintain 100% functionality 100% of the time (that's what the trunk/master is for, stability). Any updates, bug fixes or new features, not x64 related, should be done in the trunk/master, or appropriate branches.
Here is the trick: the x64 (and any other branches) should be regularly updated with the work from the trunk/master, by merging it to the x64 branch. This doesn't have to be done after every single change in the trunk/master, but has to be done once in a while as to minimize the workload of converting the new changes to x64. I've watched people age because they let changes accumulate and then had to do one huge merge.
Once the x64 work is done, the trunk/master will be stable, with features "x y z" and in x86, while the x64 branch will be the same, but with 32 more 0s and 1s. :ROFLMAO:
I assume the idea is to do away with x86, so the x64 branch now gets merged to the trunk/master and, as the french say et voilá!, Orbiter x64 rules and x86 is history. BTW, this final merge is the easiest.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,363
Reaction score
429
Points
83
Website
users.kymp.net
I am currently pulling the change of data types from 32-bit only to 32/64-bit capable ones (e.g. INT_PTR instead of BOOL for callback function return types). This is so as to remove one of the obstacles of making the code compile both for 32 and 64-bit platforms with as little modification as possible, without breaking backward compatibility for the 32-bit version.

It's rather ugly. The alternative would be to give up on the idea of a unified codebase for both 32 and 64-bit versions, and just apply the changes once the 64-bit branch has split off.
Yeah, that is a bit ugly especially because some situations are more problematic to be handled via #ifdef statements like this:

C++:
Instrument_Map::Instrument_Map (Pane *_pane, LONG_PTR _id, const Spec &spec, Vessel *_vessel)
: Instrument (_pane, _id, spec, _vessel)
{
}

I have mostly used LONG_PTR which is "long" on 32bit and "long long" on 64bit. In some cases "intptr_t" is used which is "int" and "long long". I didn't really consider using the same code for x86 and x64 but it's a very good point. I could run some test on how the x64 code compiles and runs on x86. Orbiter seems to be very stable and even the ExternMFD runs well. I was just making some final checks before uploading a test package and code modifications. I'll have to get some sleep now..
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
36,681
Reaction score
1,312
Points
203
Location
Langendernbach
Why is there a need at all to maintain a "buildable" 32 bit version?

IMHO, it makes sense to keep one such version for reference during the transition to x64 only. This way, it could be possible to test against x86 until other automated tests (unit, component, acceptance) can cover this without any historic implicit assumptions on a x86 build.

But after the transition, it should be retired for good.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,399
Reaction score
304
Points
83
Website
orbit.medphys.ucl.ac.uk
Guys, I have finally managed to build a 64-bit version of the Orbiter server as well. I shamelessly borrowed from other people's repositories, in particular Face :cheers:
I haven't yet tried it with the 64-bit D3D9Client, and I think I now need a bit of rest from the screen before proceeding to that.

I may be late to the party, but my version has the intriguing detail that it should compile both for x86 (inline graphics + server versions) and x64 (server only). Please give it a try!
I've also had somebody kindly set up continuous integration on github for me, so before any push to master I will at least know if I have broken something badly. I haven't advanced to testing yet ...
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,363
Reaction score
429
Points
83
Website
users.kymp.net
Here is my Orbiter x64 source package. For testing. It should also include some modifications from Face. I still need to run some tests on how it compiles on x86. And I'll try to upload the code to the GitHub but it's likely going to take some time since I have never used that before and starting to practice it with a large and complex project like the Orbiter isn't the easiest thing.

I'll upload a binary package containing modules for Orbiter x64 and D3D9Client x64 later today or early next week.

Orbiter x64 Src Package

List of Modified Files:
Code:
Orbitersdk/include/GraphicsAPI.h
Orbitersdk/include/MFDAPI.h
Orbitersdk/include/OrbiterAPI.h
Src/Module/LuaScript/LuaInterpreter/Interpreter.cpp
Src/Orbiter/Body.cpp
Src/Orbiter/Body.h
Src/Orbiter/CustomControls.cpp
Src/Orbiter/DlgHelp.cpp
Src/Orbiter/DlgVishelper.cpp
Src/Orbiter/FlightRecorder.cpp
Src/Orbiter/GraphicsAPI.cpp
Src/Orbiter/Help.cpp
Src/Orbiter/Log.h
Src/Orbiter/MFDAPI.cpp
Src/Orbiter/Mfd.cpp
Src/Orbiter/Mfd.h
Src/Orbiter/MfdAlign.cpp
Src/Orbiter/MfdAlign.h
Src/Orbiter/MfdComms.cpp
Src/Orbiter/MfdComms.h
Src/Orbiter/MfdDocking.cpp
Src/Orbiter/MfdDocking.h
Src/Orbiter/MfdHsi.cpp
Src/Orbiter/MfdHsi.h
Src/Orbiter/MfdLanding.cpp
Src/Orbiter/MfdLanding.h
Src/Orbiter/MfdMap.cpp
Src/Orbiter/MfdMap.h
Src/Orbiter/MfdMap_old.cpp
Src/Orbiter/MfdMap_old.h
Src/Orbiter/MfdOrbit.cpp
Src/Orbiter/MfdOrbit.h
Src/Orbiter/MfdSurface.cpp
Src/Orbiter/MfdSurface.h
Src/Orbiter/MfdSync.cpp
Src/Orbiter/MfdSync.h
Src/Orbiter/MfdTransfer.cpp
Src/Orbiter/MfdTransfer.h
Src/Orbiter/MfdUser.cpp
Src/Orbiter/MfdUser.h
Src/Orbiter/Orbiter.cpp
Src/Orbiter/Pane.cpp
Src/Orbiter/Pane.h
Src/Orbiter/Planet.cpp
Src/Orbiter/Planet.h
Src/Orbiter/PlaybackEd.cpp
Src/Orbiter/Psys.cpp
Src/Orbiter/Psys.h
Src/Orbiter/TabModule.cpp
Src/Orbiter/TabScenario.cpp
Src/Orbiter/Vessel.cpp
Src/Orbiter/Vessel.h
Src/Orbiter/ddeserver.cpp
Src/Orbiter/ddeserver.h
Src/Orbiter/htmlctrl.c
Src/Plugin/LuaMFD/LuaMFD.cpp
Src/Plugin/LuaMFD/LuaMFD.h
Src/Plugin/ScnEditor/Editor.cpp
Src/Plugin/ScriptMFD/ScriptMFD.cpp
Src/Plugin/ScriptMFD/ScriptMFD.h
Src/Plugin/TransX/transx.cpp
Src/Plugin/TransX/transx.h
Src/Plugin/TransX/transxstate.cpp
Src/Vessel/Atlantis/Atlantis/AscentAP.cpp
Src/Vessel/Atlantis/Atlantis/AscentAP.h
Src/Vessel/Atlantis/Atlantis/Atlantis.cpp
Src/Vessel/DeltaGlider/AAPSubsys.cpp
Src/Vessel/DeltaGlider/DeltaGlider.cpp

CMake Errors: I am using VS2015
Code:
22>  No update step for 'plsplit'
20>  CMake Error at CMakeLists.txt:6 (project):
20>    Generator
20>      Visual Studio 16 2019
20>    could not find any instance of Visual Studio.
20>  -- Configuring incomplete, errors occurred!
20>  See also "C:/Software/OrbiterX64Build/Utils/tileedit/qt/CMakeFiles/CMakeOutput.log".
20>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code 1.
22>  No patch step for 'plsplit'
22>  Performing configure step for 'plsplit'
22>  CMake Error at CMakeLists.txt:6 (project):
22>    Generator
22>      Visual Studio 16 2019
22>    could not find any instance of Visual Studio.
22>  -- Configuring incomplete, errors occurred!
 
Last edited:

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,399
Reaction score
304
Points
83
Website
orbit.medphys.ucl.ac.uk
I think I know where the errors relating to plsplit are coming from. I should be able to fix that, at least for the x64 build. The problem is that this is built as an "external project" which spawns it own cmake configure and VS build process, because I wanted it to build as x64 regardless of the setting for the Orbiter build. Unfortunately I had do hard-code the VS version into that call, so it fails when it doesn't find VS2019.
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,079
Reaction score
1,339
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
He/Him
I have the latest code from the trunk building successfully (BTW all, be sure you re-run the VS 2019 setup program and install the latest MFC build package if you didn't already select that when you installed your VS 2019), but when I load a scenario, all the vessel loads fail with errors like this:

============================ ERROR: ===========================
000000.000: Could not load vessel module: DeltaGlider (code 126)
000000.000: [Vessel::LoadModule | ..\..\..\Src\Orbiter\Vessel.cpp | 5760]
000000.000: ===============================================================

From debugging it, the LoadLibrary call is failing here:

Code:
bool Vessel::RegisterModule (const char *dllname)
{
    char cbuf[256];
    sprintf (cbuf, "Modules\\%s.dll", dllname); <<< also fails if I hardcode the full path here as "D:\\Orbiter_x64\\orbiter\\out\\build\\x64-Debug\\Modules"
    hMod = LoadLibrary (cbuf);
    if (!hMod)
        return false;
    ...
}

That Modules directory contains the newly compiled DeltaGlider.dll, as expected:

Code:
01-Aug-2021  02:13 PM           787,456 DeltaGlider.dll
01-Aug-2021  02:13 PM         3,507,264 DeltaGlider.ilk
01-Aug-2021  02:13 PM         3,035,136 DeltaGlider.pdb

Could it be a missing dependent DLL required by DeltaGlider.dll? If so, how would I check that?

I'm running Orbiter from my D:\Orbiter_x64\orbiter\out\build\x64-Debug folder by then launching Modules\Server\Orbiter.exe.

As a side note, is there a way to configure the CMake project to set the debugger's working directory so I can launch the VS debugger from directly inside the IDE while configuring a working directory for it (like you can do with .vcxproj projects)? Currently I'm having to launch Orbiter from the command line (because otherwise the working directory is wrong) and then use 'attach to process' to debug it, but that's proving to be quite clunky. From Googling it, I found references to setting a project property named VS_DEBUGGER_WORKING_DIRECTORY, but I couldn't figure out where to set that.

One more question -- is there a tool to convert a CMake project to a .vcxproj project? I'm much more familiar with those projects than CMake. If not, no biggie. :)
 

DarkWanderer

Active member
Orbiter Contributor
Donator
Joined
Apr 27, 2008
Messages
213
Reaction score
76
Points
43
Location
Moscow
I've also had somebody kindly set up continuous integration on github for me, so before any push to master I will at least know if I have broken something badly. I haven't advanced to testing yet ...
Glad to be of help, Dr. Schweiger:salute:

I have mostly used LONG_PTR which is "long" on 32bit and "long long" on 64bit. In some cases "intptr_t" is used which is "int" and "long long". I didn't really consider using the same code for x86 and x64 but it's a very good point. I could run some test on how the x64 code compiles and runs on x86.
As a side note - intptr_t is indeed 32-bit in x86 builds+correct "pointer" size in x64 - we might actually be able to just use it instead of the OAPI_MSGTYPE #define? Backward compatibility should be preserved well in theory.

Side note #2 - a lot of x64-related changes in code seem to be about pointers converted to 32-bit integers and back. There's a very helpful MSVC warning C4311 which highlights those cases - perhaps it would help to make it an error (see PR)
 
Last edited:

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,363
Reaction score
429
Points
83
Website
users.kymp.net
Here's a binary package containing Orbiter x64 modules ( .dll only ) and D3D9Client x64. It's a "Release" Build so it shouldn't depend on debug runtimes. API headers (.h) and libraries (*.lib) are included.

OrbiterX64-bin

1) Create a clean Orbiter Beta r.90 installation.
2) Unzip Orbiter x64 binary package. (Replace All)
3) Install Planetary textures. (Would be nice to provide a link but I didn't find one.) (You can also copy planetary texture folders from an other installation)
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,363
Reaction score
429
Points
83
Website
users.kymp.net
I have the latest code from the trunk building successfully (BTW all, be sure you re-run the VS 2019 setup program and install the latest MFC build package if you didn't already select that when you installed your VS 2019), but when I load a scenario, all the vessel loads fail with errors like this:

I had that error as well. If I recall correctly it was due to missing of lua5.1.dll x64 check that you have it in Orbiter root.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,363
Reaction score
429
Points
83
Website
users.kymp.net
One more question -- is there a tool to convert a CMake project to a .vcxproj project? I'm much more familiar with those projects than CMake. If not, no biggie. :)

I though that CMake is that tool. I downloaded it and it created VS Solution and Project files. https://www.orbiter-forum.com/threads/orbiter-is-now-open-source.40023/post-584963
Sadly it doesn't get a file destinations right (VS problem). I moved the files manually and then edited the output directory in project properties for files being often modified.

EDIT: Also you may need to manually add "Htmlhelp.lib" in the link libraries list.
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,079
Reaction score
1,339
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
He/Him
Here's a binary package containing Orbiter x64 modules ( .dll only ) and D3D9Client x64. It's a "Release" Build so it shouldn't depend on debug runtimes. API headers (.h) and libraries (*.lib) are included.

OrbiterX64-bin

1) Create a clean Orbiter Beta r.90 installation.
2) Unzip Orbiter x64 binary package. (Replace All)
3) Install Planetary textures. (Would be nice to provide a link but I didn't find one.) (You can also copy planetary texture folders from an other installation)

Thanks for this!! Once I extracted that binary package to my orbiter\out\build\x64-Debug folder (with Replace All) and activated the D3D9 module, everything worked! Still don't know what caused the original error, though, because orbiter\out\build\x64-Debug already had LuaInline.dll in it (but the size was smaller than the one extracted from your binary package).
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,079
Reaction score
1,339
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
He/Him
Here's a binary package containing Orbiter x64 modules ( .dll only ) and D3D9Client x64. It's a "Release" Build so it shouldn't depend on debug runtimes.

BTW any chance you could upload a Debug build of these libraries? I'm working on linking XRSound x64 with Orbiter, and I have the x64 release build of XRsound working now (w00t!), but I'd like to link with and test the Debug version, too. :)
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,363
Reaction score
429
Points
83
Website
users.kymp.net
Here's a debug binary package. I didn't do any extensive testing with but it seems to work.
OrbiterX64-dbg-bin.zip

An other topic:
I tested building the x64 code base in x86 and the orbiter_server compiled without errors/warnings but the linking phase failed due to zlibwapi.dll being x64, so, we would probably need to have both x86 and x64 libraries included in the repository.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,399
Reaction score
304
Points
83
Website
orbit.medphys.ucl.ac.uk
Thanks for this!! Once I extracted that binary package to my orbiter\out\build\x64-Debug folder (with Replace All) and activated the D3D9 module, everything worked! Still don't know what caused the original error, though, because orbiter\out\build\x64-Debug already had LuaInline.dll in it (but the size was smaller than the one extracted from your binary package).
That was my fault. I copied the wrong version of the Lua dll to the binary and install directories. Should be fixed now with the last commit.
 
Top