Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: Iss Mneur on July 28, 2010, 04:30:37 pm
-
Update: see http://www.hard-light.net/forums/index.php?topic=70596.msg1397177#msg1397177
TL;DR: Download the binaries in the 7-zip at the bottom of the post, and try them on as many windows computers as possible (especially fs2_open_detect_home.exe as it doesn't require any game data to work).
I have implemented detect_home() for the windows, so that now it doesn't just return the working directory, but rather returns the correct Application Data directory per user.
Thus on Vista and 7 the fs2_open_test_home.exe should show two message boxes with something like C:\Users\<username>\AppData\Roaming.
On Windows XP it should show C:\Documents and Settings\Owner\Application Data.
This code should work on all windows platforms all the way back to Win98, which is what I need help with. I don't have a machine that has Windows 98 on it, so anyone that does, please at least run the fs2_open_test_home.exe on it and report back what it reports. fs2_open_test_home.exe does not require any freespace related game data to run (the binary has been broken so that it will only do the message boxes). But because it is still a freespace binary OpenAL (http://connect.creativelabs.com/openal/Downloads/Forms/AllItems.aspx) must be installed or you will still get the OpenAL error.
Otherwise if you don't have a Windows 98 machine, please test both the fs2_open and fred2_open binaries to make sure that nothing has been broken. You can run fs2_open_test_home.exe if you like or are having trouble with the other two binaries to see what the path is that detect_home is trying to use.
These are built against .13 trunk, and have the same code as the 28 Jul 2010 - Revision 6329 - Nightly (http://www.hard-light.net/forums/index.php?topic=70594.msg1395995#msg1395995) except for detect_home patch.
A 7-zip with all of the three binaries can be found here: http://www.box.net/shared/gvpjdsvkbk
-
C:\Users\Cliff\AppData\Roaming, looks good to me on Win7 Pro x64.
-
Which method are you using?
Can you post a .patch or the function itself?
- Works fine here under Windows XP SP3
However, this is a very standard install with Home being on drive C:
- Would be great if someone can test who has their Home on another drive
-
Which method are you using?
Can you post a .patch or the function itself?
- Works fine here under Windows XP SP3
However, this is a very standard install with Home being on drive C:
- Would be great if someone can test who has their Home on another drive
I am dynamicly loading shell32.dll to use SHGetSpecialFolderPath (http://msdn.microsoft.com/en-us/library/bb762204(VS.85).aspx) so it should work correctly on all windows installs regardless of the install location. The function falls back to using the current working directory if it cannot use the function for some reason, which is the current trunk behaviour.
I will provide the patch later when I am back at my computer.
-
Got a machine with Windows 98 here, home_test failed to run, error message:
The C:\\WINDOWS\DESKTOP\FS2_OpEN_HOME_TEST.EXE file expects a newer version of Windows.
Upgrade your Windows version.
:lol:
-
Got a machine with Windows 98 here, home_test failed to run, error message:
The C:\\WINDOWS\DESKTOP\FS2_OpEN_HOME_TEST.EXE file expects a newer version of Windows.
Upgrade your Windows version.
:lol:
Hmm. That's odd. I assume that you don't get that message when you use the 3.6.12 RC4 build?
-
I am dynamicly loading shell32.dll to use SHGetSpecialFolderPath (http://msdn.microsoft.com/en-us/library/bb762204(VS.85).aspx) so it should work correctly on all windows installs regardless of the install location. The function falls back to using the current working directory if it cannot use the function for some reason, which is the current trunk behaviour.
I will provide the patch later when I am back at my computer.
MSDN docs for that function say that if you want to use it below Win 2000, you have to distribute ShFolder.dll with the exe.
-
I am dynamicly loading shell32.dll to use SHGetSpecialFolderPath (http://msdn.microsoft.com/en-us/library/bb762204(VS.85).aspx) so it should work correctly on all windows installs regardless of the install location. The function falls back to using the current working directory if it cannot use the function for some reason, which is the current trunk behaviour.
I will provide the patch later when I am back at my computer.
MSDN docs for that function say that if you want to use it below Win 2000, you have to distribute ShFolder.dll with the exe.
I have had a chance to re-read the MSDN docs. And it seems you were misled by the docs, just as I was when I was researching the functions to see if it works.
The note in the remarks section that talks about ShFolder.dll appears to be referring to SHGetFolderPath as the function that was added to Win2000. If you check the DLL requirements for SHGetFolderPath it requires version 5.0 of Shell32.dll, but SHGetSpecialFolderPath requires version 4.71. According to the Shell and Common Control Versions (http://msdn.microsoft.com/en-us/library/bb776779(VS.85).aspx), version 4.71 is good for Win98 with IE4.0.
That being said, the binary should not require a specific os version because of this feature, because it uses LoadLibarary.
The cause of the requirements could actually be from the version of the CRT that I am using (VS2010), based on my googling of the error message.
-
VS2010 does not support setting a target of lower than NT5 I believe. I think that means moving to VS2010 would prevent Win98 support in the builds.
Reference (http://msdn.microsoft.com/en-us/library/6sehtctf.aspx)
-
FRED release builds made with 2010 are already incompatible.
-
Yes I meant in general, and not just with this code. 2010 can't target WINVER < 0x0500.
-
That's not a VS2010 issue - that's an issue with the Windows SDK that you're using.
Install an earlier WINSDK - they even supply a utility to switch between the SDK versions that VS will use.
-
Ok true, thanks for that clarification, the SDK that comes with VS2010 doesn't support a lower target. But, the publicly available SDKs don't come with the MFC files, correct? And then it would either not have them to build FRED, or use the VS2010 ones anyway defeating the purpose wouldn't it? We could use the VS2008 SDK but then why even use VS2010 at all.
-
That's not a VS2010 issue - that's an issue with the Windows SDK that you're using.
Install an earlier WINSDK - they even supply a utility to switch between the SDK versions that VS will use.
What is the most recent SDK that is usable for targeting Win98?
We could use the VS2008 SDK but then why even use VS2010 at all.
Because VS2010 is a far better IDE than VS2008.
@qazwsx: Please try this set of binaries?
http://www.box.net/shared/q1qfn0y9pa MD5 = 9607B4ADFE9F02F04FD8283C867E485B
-
But is it worth having licenses for both? A VS2008 Pro license only for the SDK, and a VS2010 license only for the IDE? That's some expensive software right there.
-
That's not a VS2010 issue - that's an issue with the Windows SDK that you're using.
Install an earlier WINSDK - they even supply a utility to switch between the SDK versions that VS will use.
What is the most recent SDK that is usable for targeting Win98?
We could use the VS2008 SDK but then why even use VS2010 at all.
Because VS2010 is a far better IDE than VS2008.
@qazwsx: Please try this set of binaries?
http://www.box.net/shared/q1qfn0y9pa MD5 = 9607B4ADFE9F02F04FD8283C867E485B
will do, tomorrow hopefully, need some sleep
-
But is it worth having licenses for both? A VS2008 Pro license only for the SDK, and a VS2010 license only for the IDE? That's some expensive software right there.
You don't need a license to use the Windows/Platform SDK. MFC as far as I know is not dependent on specific SDKs, so you can use MFC that comes with VS2010.
EDIT: I just realized that I still haven't posted the patch as I promised
Index: code/osapi/osapi.cpp
===================================================================
--- code/osapi/osapi.cpp (revision 6340)
+++ code/osapi/osapi.cpp (working copy)
@@ -18,6 +18,8 @@
#include <winsock.h>
#include <stdarg.h>
#include <direct.h>
+#include <Shlwapi.h>
+#include <Shlobj.h>
#include "globalincs/pstypes.h"
#include "io/key.h"
@@ -96,17 +98,74 @@
// OSAPI FUNCTIONS
//
-// detect home/base directory (placeholder for possible future Win32 userdir support, just returns current directory for now)
-char Cur_path[MAX_PATH_LEN];
+/* detect home/base directory
+returns current working directory on windows 9x machines
+and returns the proper working directory on all NT windows. */
const char *detect_home(void)
{
- if ( strlen(Cfile_root_dir) )
- return Cfile_root_dir;
+ static char Home_path[MAX_PATH] = {'\0'};
+ if ( Home_path[0] != '\0' )
+ return Home_path;
- memset( Cur_path, 0, MAX_PATH_LEN );
- GetCurrentDirectory( MAX_PATH_LEN-1, Cur_path );
+ HINSTANCE shellDLL;
+ DLLGETVERSIONPROC pDLLGetVersion = NULL;
+ HRESULT hr;
+ DLLVERSIONINFO dllInfo;
+ dllInfo.cbSize = sizeof(DLLVERSIONINFO);
- return Cur_path;
+ shellDLL = LoadLibrary("shell32.dll");
+
+ pDLLGetVersion = (DLLGETVERSIONPROC)GetProcAddress(shellDLL, "DllGetVersion");
+ DWORD version = 0;
+
+ if ( pDLLGetVersion != NULL ) {
+ hr = ((*pDLLGetVersion)(&dllInfo));
+ if ( SUCCEEDED(hr) ) {
+ version = MAKELONG(dllInfo.dwMajorVersion, dllInfo.dwMinorVersion);
+ }
+ }
+
+ if ( version >= MAKELONG(6, 0) ) {
+ // vista or better
+ WCHAR* folder;
+ hr = SHGetKnownFolderPath(FOLDERID_RoamingAppData, KF_FLAG_CREATE, NULL, &folder);
+ if ( SUCCEEDED(hr) ) {
+ if ( 0 != WideCharToMultiByte(CP_ACP, 0, folder, -1, Home_path, sizeof(Home_path), NULL, NULL) ) {
+ FreeLibrary(shellDLL);
+ return Home_path;
+ } else {
+ mprintf(("Failed to convert home path for version 6.0\n"));
+ }
+ } else {
+ mprintf(("Failed to get home path for version 6.0\n"));
+ }
+ }
+
+ if ( version >= MAKELONG(4, 71) ) {
+ // Win98 with IE4.0 or Windows NT 4.0 or better
+ if ( SHGetSpecialFolderPath(0, Home_path, CSIDL_APPDATA, TRUE) == TRUE ) {
+ FreeLibrary(shellDLL);
+ return Home_path;
+ } else {
+ mprintf(("Failed to get home path for version 4.71\n"));
+ }
+ }
+
+ if ( strlen(Cfile_root_dir) ) {
+ scp_strcpy_s(LOCATION, Home_path, Cfile_root_dir);
+ return Home_path;
+ } else {
+ mprintf(("Failed to get home path by using Cfile's root dir\n"));
+ }
+
+ // Last ditch effor, try using the current working directory
+ DWORD ret = GetCurrentDirectory( sizeof(Home_path), Home_path );
+ if ( ret > sizeof(Home_path) ) {
+ mprintf(("Working directory too long to use as home path\n"));
+ } else if ( ret == 0 ) {
+ mprintf(("Unhandled error (%x) while attempting to retrive the working directory to be used as a home_directory()\n", GetLastError()));
+ }
+ return Home_path;
}
// initialization/shutdown functions -----------------------------------------------
-
I would think that mixing the VS2010 MFC and a previous WSDK would be a bad idea, but I'm not an expert on that subject.
-
If we're making improvements to this area of code, I'll also cleanup and post my patch to detect the .app location correctly (i.e. using the proper Apple supplied API call) on OS X.
FS2_Open also uses the wrong spot to save the per-user OS X config data, so I might look at including my patch for that too. Doing this as a post-3.6.12 breakage may be the least worst option.
-
Please try this set of binaries?
http://www.box.net/shared/q1qfn0y9pa MD5 = 9607B4ADFE9F02F04FD8283C867E485B
I am still waiting for someone to report back about Win98, WinME, and Windows 2000.
Because this will also affect FRED, if someone is feeling adventurous try these binaries on WINE as well.
-
Running in Wine for OS X, I get:
Z:\Users\cliffgordon\Downloads\fs2_open_3_6_13d_INF_SSE_detect_home_2010.08
Which is Wine's idea of where the binary is executing from, so not sure that's what we were going for.
-
Running in Wine for OS X, I get:
Z:\Users\cliffgordon\Downloads\fs2_open_3_6_13d_INF_SSE_detect_home_2010.08
Which is Wine's idea of where the binary is executing from, so not sure that's what we were going for.
Well, current directory is not bad as that is the old behaviour so at least nothing broke, or its not whining about missing .dll's.