cxxtools
cxxtools copied to clipboard
windows version of cxxtools needed
as the title
Unlikely. cxxtools is coded for a POSIX environment. Stream based things like cxxtools::Arg
already work on Windows. You could extract them easily based on you needs.
aggsol is right. Most of cxxtools can be compiled on windows if you create a build environment. I guess network would need some small changes. Feel free to try it and contribute. I have personally no need for a windows version and I even do not have that operating system here.
Most of the code can be compiled by msvc but the code about thread and ipc. for linux os don't have a thing can be called "real thread".in linux,in fact,thread is a special process. But windows have process and thread and they are differente by many feature and using.
fork is the main matter.
Really? I did not know, that linux do not have threads. It may be that processes and threads are different. But how that affect a possible windows port of cxxtools?
In linux, fork can be call by main process and sub process run from "fork"'s next line code。 but on windows,no any syscall can do the same thing between 2 process
if you can generalize that why you use fork and form some common functions,i can write the function which can be run on windows os
All uses of fork can be found in the namespace cxxtools::posix. The whole namespace can be skipped in a windows port.
but the functions in this would be lost……i mean you can make the functions more modulelized and then may be i can write it for windows os……"getProcessIpcWrite" for make a writeable ipc channel,for example.
Portable threads can be done with C++11 or newer (regex too). All the POSIX stuff, which is a lot?, would require coding from scratch for windows.
If you want a cross-OS-library with network support just use something like Boost.Asio or Qt. Or search projects done with them, because both provide cross-platform network sockets but no straight web server functionality out of the box.
I understand wanting to have a windows port, cxxtools/tntnet might be one of the easiest C++ http servers to setup with a lot room to do stuff, but POSIX happens...
My general feeling, unless you're doing some Windows IoT device (in which case use .Net), a full blown Windows port probably isn't needed; if you've got a windows machine you can easily run a different web server.
After having said that, I DO need a windows port of the ecppc tool! I'm using tntnet to build a small, lightweight web browser in an embedded device, and Visual C++ to do the cross-compilation (Linux target). However, it wants to run the ecppc tool locally, THEN copy it over to the Linux machine.
So some of the tools could be handy.
Any ideas?
Regarding threads vs. forks, etc. Windows does things fundamentally different, and somewhat lighter weight. When you have a thread running inside the same context, you don't pay for a context switch with as many clock cycles. So in Windows, you want one .exe with many threads in it. Linux tends to have one thread in an executable with many executables. They don't always equate. I haven't seen benchmarks recently though. Some of Russinovich's slides are great. Don't assume the other O/S is "broken" because it doesn't do things the way your favorite one does :) :)