Closed slw07g closed 9 years ago
For example, in libcfile_WriteFile() read_count read_size are used where it should be write_count and write_size.
I'll have a look.
Also, I've had the hardest time getting libpff to build on Windows (with python enabled) using MingGW.
This is not recommended. Since Python 2.7 is build with VS 2008 itself building with MinGW introduces an additional C runtime which can lead to subtle issues.
So you are trying to do something here that is deliberately not supported
I appreciate that you are creating this wonderful library. I think it would be great if you could make platform independence as seamless as possible.
Use the VS solution files instead as mention here: https://github.com/libyal/libpff/wiki/Building#python-bindings-2
To clarify, are you saying that compiling the Python bindings is not supported with MinGW? Because I assumed it was supported based on the information from the same wiki you linked to (see "Building with MSYS-MinGW"). If this is the case, perhaps it could be made clearer in the wiki that users should not attempt to install "Python bindings" via MinGW.
Thank you for directing me to the Visual Studio instructions. I was hoping to avoid using MSVS, but I see there's no way around it.
To clarify, are you saying that compiling the Python bindings is not supported with MinGW?
You probably can get it to build using distutils instead of configure/make (since that depends on python-config). I'm saying this is not recommended since it can cause issues regarding differences between MinGW and VS (since Python is compiled with VS).
I can add a note, but it typically is impossible to foresee and document all possibilities people come up with. Nor can you distribute Python extension build with MinGW since that would violate the GPL of MinGW C runtime.
I was hoping to avoid using MSVS, but I see there's no way around it.
Have a look at Microsoft Visual C++ Compiler for Python 2.7 to replace full fledged VS 2008 express
http://www.microsoft.com/en-us/download/details.aspx?id=44266
I tried it both ways (autogen.sh/configure/make and distutils), and it wouldn't build. (I've been trying for a week.)
It was actually a bit smoother doing it with Visual Studio. I did have to manually copy the lib and dll files to the proper directories in my Python installation path, so that it would work.
Hopefully someone will make a pure python PST parser one of these days for a more seamless platform-independent solution.
Thanks for your help!
Hopefully someone will make a pure python PST parser one of these days for a more seamless platform-independent solution.
Hope is something best left to religion, if you are in need of a pure python PST parser it is likely the best to write one yourself or hire someone to do it for you.
Thanks for your help!
Noprob; closing issue.
For example, in libcfile_WriteFile() read_count read_size are used where it should be write_count and write_size.
Not sure which version of libcfile you are looking at or where, but this looks correct to me: https://github.com/libyal/libcfile/search?utf8=%E2%9C%93&q=libcfile_ReadFile https://github.com/libyal/libcfile/search?utf8=%E2%9C%93&q=libcfile_WriteFile https://github.com/libyal/libcfile/search?utf8=%E2%9C%93&q=libcfile_GetOverlappedResult
BOOL libcfile_WriteFile( HANDLE file_handle, VOID buffer, DWORD write_size, DWORD write_count, OVERLAPPED *overlapped ) { FARPROC function = NULL; HMODULE library_handle = NULL; BOOL result = FALSE;
if( file_handle == NULL )
{
return( FALSE );
}
if( buffer == NULL )
{
return( FALSE );
}
if( read_count == NULL )
{
return( FALSE );
}
library_handle = LoadLibrary(
_LIBCSTRING_SYSTEM_STRING( "kernel32.dll" ) );
if( library_handle == NULL )
{
return( FALSE );
}
function = GetProcAddress(
library_handle,
(LPCSTR) "WriteFile" );
if( function != NULL )
{
result = function(
file_handle,
buffer,
read_size, <-----------------
read_count, <-----------------
I see thanks; seeing you are triggering this codepath you likely want to set WINVER correctly since this codepath should only be needed for compiling on Window 2000 or earlier (as indicated in: https://github.com/libyal/libpff/wiki/Building#using-minimalist-gnu-for-windows-mingw)
Since this should also trigger:
#error WINAPI file stat function for Windows 2000 or earlier NOT implemented yet
The instructions don't mention anything about the code path. But hopefully you fix the buggy code for open-source reasons.
The instructions don't mention anything about the code path.
Not sure what instructions you are expecting to be there, but I opt to search for WINVER in https://github.com/libyal/libpff/wiki/Building
But hopefully you fix the buggy code for open-source reasons.
Already fixed: https://github.com/libyal/libcfile/commit/c0fc644613299b6ae32e5bc0b05f6bfcff526364
There are some issues in libcfile/libcfile_file.c. It looks like code was copied and pasted, but you forgot to change the variables in the body of the function to match the names of the variables in the function parameters.
For example, in libcfile_WriteFile() read_count read_size are used where it should be write_count and write_size.
This occurred in the ReadFile() routine too, and there was an issue in the GetOverlappedResult() routine where I think "buffer" in the body of the function should be replaced with "overlapped".
Also, I've had the hardest time getting libpff to build on Windows (with python enabled) using MingGW.
I had to modify the source code for MingGW's autopoint so that it I could run the autogen.sh script. I had to find a hack for the "python-config" requirement. (python-config doesn't exist on Windows, apparently).
I appreciate that you are creating this wonderful library. I think it would be great if you could make platform independence as seamless as possible.