Hi,
I am looking to port a MSVC++ driver to Linux. The recommended approach, to convert the Makefile and compile it didn't work for me, so I am trying to compile seperate cpp.files by implementing the winapi functions I need in a seperate linuxapi.cpp
There are about 30 functions I have to port at the moment, and some of them are easier than others. Basically they are part of the DLL (so), thread/event/mutex, File*Find apis, with some miscellaneous ones. I think I could do myself a favor by asking if the MSVC++ code could use libpthread instead of the MS threads, so I'm not too worried about those, and simulating DLL with the dl* api seems easy enough as well. Still, there are problems with Find*File, FindClose, GetModuleFileName and so on.
I'm not too familiar with winapi myself, because I learn C/C++ in a college environment, where most programming assignments are geared towards Linux. Can anyone comment sensibly on this? If you are of the opinion that I should just rewrite the app from scratch, I agree in part, but the assignment is to leave as much of the original code as it is, apart from isolated cases where g++ can't quite follow the MSVC++ compiler.
At the end of the email is a list of prototypes included, that I ripped from winbase.h
Looking forward to read your thoughts on this matter,
Regards,
Arjen Verweij
Here is the list:
DWORD GetModuleFileName(HMODULE, LPTSTR, DWORD);
HANDLE FindFirstFile(LPCSTR lpFileName, LPWIN32_FIND_DATA lpFindFileData);
BOOL FindNextFile(HANDLE hFindFile, LPWIN32_FIND_DATA lpFindFileData);
BOOL FindClose(HANDLE hFindFile);
BOOL SetEvent(HANDLE hEvent);
FARPROC GetProcAddress(HMODULE hModule, LPCSTR lpProcName);
HMODULE LoadLibrary(LPCSTR lpLibFileName);
BOOL FreeLibrary(HMODULE hLibModule);
HANDLE CreateMutex(LPSECURITY_ATTRIBUTES lpMutexAttributes, BOOL bInitialOwner, LPCSTR lpName);
DWORD WaitForMultipleObjects(DWORD nCount, CONST HANDLE *lpHandles, BOOL bWaitAll, DWORD dwMilliseconds);
BOOL CloseHandle(HANDLE hObject);
BOOL ReleaseMutex(HANDLE hMutex);
DWORD GetCurrentProcessId(VOID);
HANDLE CreateEvent(LPSECURITY_ATTRIBUTES lpEventAttributes, BOOL bManualReset, BOOL bInitialState, LPCSTR lpName);
VOID Sleep(DWORD dwMilliseconds);
BOOL ResetEvent(HANDLE hEvent);
DWORD _beginthread(void(__cdecl *start_address) (void*), unsigned, void*);
VOID OutputDebugString(LPCSTR lpOutputString);
DWORD WaitForSingleObject(HANDLE hHandle, DWORD dwMilliseconds);
void _endthread(void);
BOOL ReleaseSemaphore(HANDLE hSemaphore, LONG lReleaseCount, LPLONG lpPreviousCount);
HANDLE CreateSemaphore(LPSECURITY_ATTRIBUTES lpSemaphoreAttributes, LONG lInitialCount, LONG lMaximumCount, LPCSTR lpName);
BOOL UnmapViewOfFile(LPCVOID lpBaseAddress);
HANDLE CreateFileMapping(HANDLE hFile, LPSECURITY_ATTRIBUTES lpFileMappingAttributes, DWORD flProtect, DWORD dwMaximumSizeHigh, DWORD dwMaximumSizeLow, LPCSTR lpName);
DWORD GetLastError(VOID);
LPVOID MapViewOfFile(HANDLE hFileMappingObject, DWORD dwDesiredAccess, DWORD dwFileOffsetHigh, DWORD dwFileOffsetLow, DWORD dwNumberOfBytesToMap);
-----Original Message----- From: wine-devel-admin@winehq.org [mailto:wine-devel-admin@winehq.org]On Behalf Of Arjen Verweij Sent: 07 September 2003 14:38 To: wine-devel@winehq.org Subject: Porting radio driver from MS to Linux
I'm not too familiar with winapi myself, because I learn C/C++ in a college environment, where most programming assignments are geared towards Linux. Can anyone comment sensibly on this? If you are of the opinion that I should just rewrite the app from scratch, I agree in part, but the assignment is to leave as much of the original code as it is, apart from isolated cases where g++ can't quite follow the MSVC++ compiler.
It may be best to first compile the app using Mingw (minimalist GNU compiler for Windows). That will get rid of the the the MSVC++ specific stuff from the program.
At the end of the email is a list of prototypes included, that I ripped from winbase.h
A lot of the functions you list are primitives (i.e. processed in wineserver). If you are not planning on using wineserver, then you will have to reimplement those in your own way, as the Wine code probably won't be compatible.
You don't say how big the code is, but if it is not too big then I would try and rewrite it without Wine. Reimplementing Wine is quite a hard task, even if you are using a very small amount of it.
Rob
Arjen Verweij wrote:
Hi,
I am looking to port a MSVC++ driver to Linux. The recommended approach, to convert the Makefile and compile it didn't work for me, so I am trying to compile seperate cpp.files by implementing the winapi functions I need in a seperate linuxapi.cpp
what kind of driver is it ? wine is not generally well suited to run driver. Do you know how the driver communicates with hardware. Depending on what the driver does, it may not work on Wine/Linux. A+
It is a driver to stear a radiochip over a 3-wire bus. Currently test models are mounted on par.port plugs, but there is an USB version and an iPAQ has been "operated upon" and had a chip implanted. The chip works with Linux, just using inb() and outb(), but now the request has been made to try and compile the existing source on Linux, altering as few of the original code as possible, so that when the driver is updated, the maintenance effort for the ported code is as small as it can be.
While this is a nice approach in theory, I'm not really convinced it will work, but since I can't make an educated guess I'm just trying anyway. Thusfar it seems that a lot of stuff could be implemented more or less directly, aside from the few functions I mentioned.
Currently I'm compiling my updated cvs, maybe I make some progress the regular way.
Thanks for your input.
Arjen Verweij
On Sun, 7 Sep 2003, Eric Pouech wrote:
Arjen Verweij wrote:
Hi,
I am looking to port a MSVC++ driver to Linux. The recommended approach, to convert the Makefile and compile it didn't work for me, so I am trying to compile seperate cpp.files by implementing the winapi functions I need in a seperate linuxapi.cpp
what kind of driver is it ? wine is not generally well suited to run driver. Do you know how the driver communicates with hardware. Depending on what the driver does, it may not work on Wine/Linux. A+
-- Eric Pouech