28.06.2013 20:42, Mateusz Viste пишет:
>> This has the downsides too. dosemu releases are so
>> infrequent that the new features of slirp, if any, will be
>> delayed for too long.
> Sure. But on the other hand, if it works today, there's no reason it
> will stop working tomorrow ;)
But there may be new features added, like pings.
There are the efforts to allow pings/icmp without a root
requirement:
http://lwn.net/Articles/420801/
Not sure if that happened already or not.

> Having a setting named naively 'nat' that says 'check this and you
> will have a working internet connectivity' is, IMHO, much more sexy
But why would we call it a nat, if it is not nat by any means?

>> IF vde have some better availability in the repos, then
>> my vote will be with it.... but it doesn't seem to be the
>> case. :)
>
> In fact, it would not change much. Something like 'install VDE and
> configure DOSemu to hook on it' instead of 'install SLIRP and
> configure DOSemu to hook
Well, I was thinking about the possibility to maybe add the
package dependency on slirp or VDE. But...

> on it'. At the architecture level, it would be DOSemu -> VDEslirp
> instead of DOSemu -> slirp.
The main point is to see if maybe VDE also has everything
_you_ wrote (I mean librouter). Then there could be fewer
additions to dosemu itself.
If VDE does not replace any of your code, then I immediately
stop talking about it. :) (since anyway it doesn't seem to have
any advantages on other fronts too)

> But of course you are right that in such situation the availability of
> the 'auxiliary' software would be a strong argument. But still, having
> the whole thing integrated into DOSemu would provide a universal &
> unified solution, and the user wouldn't have to care about anything,
> just installing DOSemu itself.
Maybe VDE can also be integrated?
My main concern is the overlap between the VDE and librouter.

>> Not directly related to you problem, but see if pty suits
>> better for your needs then socketpairs etc. It usually
>> always does.
>
> I don't know pty very much (never used them), that's why I use socket
> pairs, because I'm simply more familiar with them. But after taking a
> look at the documentation, both sound quite similar.. What kind of
> benefit could I have from using pty rather than normal sockets? is pty
> 8bit safe? can it be used with select() ?
Yes to all, but that's not all.
ptys allow you to send (via special chars) the signals, the
EOFs etc. Also there are different buffering strategies, so
for instance pty can send the line after every EOL, rather
than by the parts you write() to it, etc. It also supports
line-editing and echo.
If you don't need any of these features, then you don't
need pty.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Dosemu-devel mailing list
Dosemu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dosemu-devel

Reply via email to