Porting radio driver from MS to Linux

[Arjen Verweij]

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);

[Robert Shearman]

> -----Original Message-----
> From: wine-devel-admin(a)winehq.org [mailto:wine-devel-admin(a)winehq.org]On
> Behalf Of Arjen Verweij
> Sent: 07 September 2003 14:38
> To: wine-devel(a)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

[Eric Pouech]

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

[Arjen Verweij]

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