Methods to convert Windows Code to Linux Code
Johnson
codes, STD, and Windows APIs. Now I want to create an equivalent for
Linux, what will be the best and fastest solution?
I think libwine might provide the fastest solution, right? I haven't
used libwine before, really not sure how it will solve my problem.
Any other idea or concern? Thank you!
Johnson
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
J.O. Aho
> I have a windows program written in C/C++, including standard C/C++
> codes, STD, and Windows APIs. Now I want to create an equivalent for
> Linux, what will be the best and fastest solution?
Fastest: use libwine (microsoft windows api library for Linux)
Best: Rewrite all microsoft api parts of the code to use Linux native
libraries (suggest you use Qt for GUI, as it's far more portable than gtk2).
> I think libwine might provide the fastest solution, right? I haven't
> used libwine before, really not sure how it will solve my problem.
Using libwine will not give you a 100% compatible api, this has to do with the
closeness of microsoft and the wine project hasn't used any code from
microsoft but written everything from scratch.
The big drawback with libwine is that you will not get a multi architecture
support, you will mainly just get a x86/amd64 working application, supporting
mips, alpha, sparc, m68k and so on can need a lot more work, those using a
native code can be a lot better.
--
//Aho
unruh
> I have a windows program written in C/C++, including standard C/C++
> codes, STD, and Windows APIs. Now I want to create an equivalent for
> Linux, what will be the best and fastest solution?
Depends on what th eprogram does. It is is a window based program, it is
going to be more difficult as AFAIK there is no real translation form
Windows gui code to X say. If it is a command line problem it should be
very straightforward.
>
> I think libwine might provide the fastest solution, right? I haven't
> used libwine before, really not sure how it will solve my problem.
I think you will still have problems with the gui, but do not know.
Johnson
I would like my program runs with ARM9 instead of x86, and it is the
main drive for me to switch from Windows to Linux. Based on the info you
have provided, it may need a lot more work, so libwine might not be a
good solution for my problem, right?
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Johnson
My program is a command-line program focusing on algorithm, so it will
be easier than the GUI-based programs when converting into the Linux, right?
It seems that I will need to convert each Windows API to their
equivalent POSIX system call/calls, right?
I also have part of the codes written in STL (Standard Template Library)
to take advantage of the containers and algorithms, should I rewrite
this part for Linux, or it is not necessary?
Any other thoughts/concerns for the converting work?
Thank you!
J.O. Aho
> J.O. Aho wrote:
>> Johnson wrote:
<fixed the top posting error>
>>> I have a windows program written in C/C++, including standard C/C++
>>> codes, STD, and Windows APIs. Now I want to create an equivalent for
>>> Linux, what will be the best and fastest solution?
>>
>> Fastest: use libwine (microsoft windows api library for Linux)
>> Best: Rewrite all microsoft api parts of the code to use Linux native
>> libraries (suggest you use Qt for GUI, as it's far more portable than
>> gtk2).
>>
>>
>>> I think libwine might provide the fastest solution, right? I haven't
>>> used libwine before, really not sure how it will solve my problem.
>>
>> Using libwine will not give you a 100% compatible api, this has to do
>> with the
>> closeness of microsoft and the wine project hasn't used any code from
>> microsoft but written everything from scratch.
>> The big drawback with libwine is that you will not get a multi
>> architecture
>> support, you will mainly just get a x86/amd64 working application,
>> supporting mips, alpha, sparc, m68k and so on can need a lot more work,
>> those using a native code can be a lot better.
>
> Thanks a lot.
> I would like my program runs with ARM9 instead of x86, and it is the
> main drive for me to switch from Windows to Linux. Based on the info you
> have provided, it may need a lot more work, so libwine might not be a
> good solution for my problem, right?
In the long run it's not the best solution, it's just a temporarily solution,
just look at the Linux Google Earth project, the first version was based on
libwine, it did work, sluggish and tend to crash, nowadays there is a Linux
native one which is far more usable.
Running on ARM9, you may want to optimize the code more than just make the use
of libwine, do write our code to depend as little as possible on closed APIs
and write as much as possible with lightweight libraries or use crossplatform
libraries as QT (if you need a GUI), sdl (if you need mutlimedia) and so on.
Use only microsoft api in those cases when you write code specific for the
microsoft windows version. I think you will be able to support far more
platforms with as little modification of your new code than you need with your
current code.
--
//Aho
unruh
> Thanks a lot.
> My program is a command-line program focusing on algorithm, so it will
> be easier than the GUI-based programs when converting into the Linux, right?
> It seems that I will need to convert each Windows API to their
> equivalent POSIX system call/calls, right?
Which API? Could you give an example of what you are worried about?
> I also have part of the codes written in STL (Standard Template Library)
> to take advantage of the containers and algorithms, should I rewrite
Sorry,I at l,east have no idea what STL is
Jasen Betts
> My program is a command-line program focusing on algorithm, so it will
> be easier than the GUI-based programs when converting into the Linux, right?
should be.
> It seems that I will need to convert each Windows API to their
> equivalent POSIX system call/calls, right?
you may find that some are not needed, eg: under linux the shell is
udually resposible for globbing so you may not need to do directory
scanning at all.
> I also have part of the codes written in STL (Standard Template Library)
> to take advantage of the containers and algorithms, should I rewrite
> this part for Linux, or it is not necessary?
STL is a real standard (ISO) not something microsoft invented, so no
that part won't need alteration, unless you're relying on undocumented
behavior.
> Any other thoughts/concerns for the converting work?
linux has real argv[] which Windows emulates (or just uses a single
string) so the command-line parsing code may need a touch-up
but the linux version should be simpler than the code it replaces.
(if it's not there's a disign problem)
linux and windows command-line enviroments are different in several
subtle ways so if you have questions ask.
--
¡spuɐɥ ou 'ɐꟽ ʞooꞀ
Johnson
Any more details about the subtle difference between the Linux and
Windows command-line environments?
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Johnson
InternetOpen.
Thanks.
Lew Pitcher
> Here are a few examples:
> FindFirstFile,
No direct equivalent in Linux.
Typically, Windows developers use FindFirstFile() and FindNextFile()
within application code to perform filename matching for commandline
arguments. In Linux, such matching ("globbing") happens within the shell,
and an application receives only matching filenames in it's argument list.
I.e.
command *.*
in Windows results in an argument list which includes (literally) "*.*",
and the Windows app must then resolve, on it's own, which filenames "*.*"
refers to. OTOH
command *.*
in Linux results in an argument list which includes the full filenames of
all the files that match the expression, and the app doesn't need to glob
for them.
Sometimes, Windows apps use FindFirstFile() and FindNextFile() to perform
explicit directory processing (i.e. to do what ls or ln does). In Linux,
the APIs are opendir()/readdir()/closedir(), and these APIs *do not*
include the explicit globbing feature that the Windows FindFirstFile() API
does.
> InternetGetConnectedState,
Unnecessary on a Linux system. Your system, /as a system/ is either network
connected, or it is not. Application programs have no say in the matter,
and should work whether or not the "network" is active (the loopback
address, for instance, is /always/ available, so the system
is /always/ "connected", even if there is no explicit network available).
> InternetOpen.
Unnecessary on a Linux system. Your system, /as a system/ is either network
connected, or it is not. Application code is not permitted to modify the
state of the network (not without going through hoops of all sorts,
including requiring "root" priviledges, accessing network parameters
through the /sys or /proc filesystem, and/or through ioctl() calls on
network devices.
[snip]
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------
Lew Pitcher
> I have a windows program written in C/C++, including standard C/C++
> codes, STD, and Windows APIs. Now I want to create an equivalent for
> Linux, what will be the best and fastest solution?
Best? Rearchitect and rewrite your app to remove it's Windows dependancies
and assumptions. Linux isn't Windows, and programs written for Windows are
written with different (and usually conflicting) assumptions on how the
system is "managed".
Besides the API differences, there are philosophical differences in what an
app is expected or permitted to do, and usually Windows apps take on more
system-level ownership than is permitted by Linux.
Fastest? Use libwine. You won't have to change anything in your app, and it
will work (mostly) properly. Be aware that, where Linux operational
philosophy differs from Windows, libwine will likely /not/ be able to act
like Windows.
> I think libwine might provide the fastest solution, right? I haven't
> used libwine before, really not sure how it will solve my problem.
>
> Any other idea or concern? Thank you!
As I said, the way that Linux systems are run is different from how Windows
systems are run. This means that the Windows approach to system management
rarely fits (or even works) in Linux systems.
No, you can't tweak system settings through the registry. There is no
registry, so don't expect one.
Per-user configuration files are stored in the user's $HOME directory, in a
dotfile or as files in a dotdirectory (for example, $HOME/.bittorrent for
personal bittorrent settings). Per-user config files override systemwide
config files. Per-user config files are editable by the owning user.
Systemwide configuration files are stored in /etc, as a file or as files in
a subdirectory of /etc (for example, /etc/gtk for systemwide GTK settings).
Systemwide config files are editable only by root, or by specific
authorized users for that subsystem.
Applications /do not/ attempt to determine "the directory that they were run
from". Especially, they /do not/ do that in order to locate their settings
files or special modules.
The filesystem hierarchy is different between Windows and Linux. You don't
place things in Linux in the same (or even similar) places as you would in
Windows. And, you don't look for them in those same places either (usually
means code changes for config files, data files, log files, DLLs, etc)
/etc is for system-wide settings
/bin, /usr/bin and /usr/local/bin are for user application executables
(/sbin, /usr/sbin, and /usr/local/sbin are for system-level executables)
/lib, /usr/lib, and /usr/local/lib are for callable libraries (DLLs, in
Windows-speak)
/var is for "variable" data, such as log and lock files.
/usr is for application fixed data files
/usr/share and /usr/local/share are data files that are shared between
many users and applications.
the heir(7) manual page ("man 7 heir") will tell you a lot about where
file-like things go on Linux.
Linux systems are true simultaneous multi-user environments. You need to
respect that. Expect that your app will be run /simultaneously/ by multiple
users, and handle this condition "nicely". Lock files when program
instances need exclusive use of them. Don't pollute one user's environment
with another users data.
No, you /cannot/ change the environment of one running process from another
process. Don't expect to back-populate environment variables. If you want
to share data between processes, use one of the many IPC mechanisms
available to you.
Applications don't have the right to alter the system's configuration. Don't
do things behind the sysadms back; if the system is not network connected,
don't attempt to force it to become connected, if the system is running,
don't force it to shutdown. If the system is in single-user mode, don't
force it into multi-user mode. If there is no X available, don't start X.
Those aren't your decisions; you aren't responsible for them, and your
actions are contrary to how the owner of the system wants it to run. If
your program /needs/ any of those features, then it is perfectly capable of
reporting such and refusing to run until such has been established. If you
need X and it isn't there, tell the user, and terminate. If you need a
network connection and it isn't there, tell the user and terminate. You get
the picture.
Don't implement the world. If your program sorts data, let it sort data. It
doesn't need a GUI to do that. If your program converses with another
program, let it converse; it doesn't need to control the modem. If you need
two disparate features, implement two programs. Keep It Simple.
Read "The Art of Unix Programming" (http://catb.org/esr/writings/taoup/),
and wrap your head around the differences between Windows and Unix (Linux
is a form of Unix).
HTH
Lew Pitcher
> On August 16, 2010 01:07, in alt.os.linux, gpsa...@hotmail.com wrote:
>
>> I have a windows program written in C/C++, including standard C/C++
>> codes, STD, and Windows APIs. Now I want to create an equivalent for
>> Linux, what will be the best and fastest solution?
[snip]
>> Any other idea or concern? Thank you!
[snip]
> Read "The Art of Unix Programming" (http://catb.org/esr/writings/taoup/),
> and wrap your head around the differences between Windows and Unix (Linux
> is a form of Unix).
To quote the book, on design of apps in Unix (and therefore Linux),
1. Write simple parts connected by clean interfaces.
2. Clarity is better than cleverness.
3. Design programs to be connected to other programs.
4. Separate policy from mechanism; separate interfaces from engines.
5. Design for simplicity; add complexity only where you must.
6. Write a big program only when it is clear by demonstration that nothing
else will do.
7. Design for visibility to make inspection and debugging easier.
8. Robustness is the child of transparency and simplicity.
9. Fold knowledge into data so program logic can be stupid and robust.
10. In interface design, always do the least surprising thing.
11. When a program has nothing surprising to say, it should say nothing.
12. When you must fail, fail noisily and as soon as possible.
13. Programmer time is expensive; conserve it in preference to machine
time.
14. Avoid hand-hacking; write programs to write programs when you can.
15. Prototype before polishing. Get it working before you optimize it.
16. Distrust all claims for “one true way”.
17. Design for the future, because it will be here sooner than you think.
John Hasler
> /usr/share and /usr/local/share are data files that are shared between
> many users and applications.
/usr/share is for architecture-independent files that may be shared
among systems with different architectures
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA
Lew Pitcher
> Lew Pitcher writes:
>> /usr/share and /usr/local/share are data files that are shared between
>> many users and applications.
>
> /usr/share is for architecture-independent files that may be shared
> among systems with different architectures
We're both slightly off the mark. hier(1) says
/usr/share
This directory contains subdirectories with specific application
data, that can be shared among different architectures of the
same OS. Often one finds stuff here that used to live in
/usr/doc or /usr/lib or /usr/man.
I caught "specific application data", while you caught "different
architectures". Looks like we're both right ;-)
FWIW, hier(1) says
/usr/local/share
Local application data that can be shared among different
architectures of the same OS.
Lew Pitcher
> the heir(7) manual page ("man 7 heir") will tell you a lot about where
> file-like things go on Linux.
It appears that I can't spell..
That should be
hier(7) and "man 7 hier"
[snip]
Johnson
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Jasen Betts
> /usr/share and /usr/local/share are data files that are shared between
> many users and applications.
actually for files that are platform independant, like
documentation, sound files, pictures, the maps used by games,
wordlists, i18n data, etc. prettty much anything that's not
effected by the type of processor or its endianness.