Image Map Image Map
Page 3 of 3 FirstFirst 123
Results 21 to 28 of 28

Thread: DOS Networking / Win 3.11 Networking

  1. #21

    Default

    Quote Originally Posted by mbbrutman View Post
    You designed code that didn't bother encoding a length
    True. I was naive (and I admited that immediately back then) to follow the packet driver specification too literally in my quest for simplicity. There are obviously many kinds of packet drivers, and some may behave in ways that one may not expect.

    Quote Originally Posted by mbbrutman View Post
    and didn't bother with a higher level check on the data other than the Ethernet CRC.
    Also true. It is still my (own, personal, private) belief that an application level checksum is overkill in most situations for a protocol that runs over raw Ethernet. But I gladly admit that there are also cases where it may be helpful (LPT-attached network adapters is one example). And it was also certainly very helpful to detect and diagnose the PE3 issue, no doubts about that.

    Quote Originally Posted by mbbrutman View Post
    And then you gave it to other people. *Bad.*
    I don't necessarily agree, but I respect this opinion. My (again - own/personal/private) opinon is that it is good to provide software - even if not 100% perfect - to people to play with. If I wanted to publish only perfect software, I would never publish anything. But this may very well be my own limitation, that does not apply to you or other programmers.

    Quote Originally Posted by mbbrutman View Post
    The history of the debug effort on your code is clear in the thread for everybody to read.
    Indeed it is.

    Quote Originally Posted by mbbrutman View Post
    I did my part to help you understand your bug.
    That's where our opinions diverge. But I propose to leave this subject to rot, and never come back to it ever again. No need for heated debates - we both could surely better spend our time on actual coding.

    That being said - I must admit that I am surprised by the moderation and relative good will of your last message. I was expecting further escalation, which frankly wouldn't be productive nor healthy for any of us. I thereby thank you for that.

    Quote Originally Posted by mbbrutman View Post
    My advice; test more before releasing code.
    That's definitely a good, common-sense advice. Unfortunately, applying it wouldn't let me discover the issue in question anyway, since none of my NIC cards exhibits the PE3's behavior. I should probably extend my retro-collection of hardware to test software on a richer variety of platforms.

    Mateusz

  2. #22

    Default

    Quote Originally Posted by mbbrutman View Post
    The redirector interface is a mixed bag. There is enough sample code out there but the interface was never formally documented by Microsoft. So it is usable but there is no one specification to consult; you have to consult open source code and some 3rd party books to get the full picture.
    I will have to dig into this at some point as well, unfortunately. Do you know any specific document (or good code) pointing out pitfalls, or is it better to simply consult EtherDFS? My usecase does not involve Ethernet, but it does need to deal with SHARE support/compatibility.

    Quote Originally Posted by mateuszviste View Post
    There is also the block device approach which should be simpler and it is well documented.
    That is a very valid option, but one has to be aware that with such solution, only one PC must be allowed to access the drive at any given time - because of the risk of concurrent writes of course, but also because of the fact that the OS is fooled into believing it's a "real" drive that is being accessed, and as such it could be tempted to perform caching on its own, unaware that the data may spontaneously change at the other end.
    Exactly that is why I can't take that approach. Sigh.

  3. #23
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,995
    Blog Entries
    1

    Default

    Quote Originally Posted by mateuszviste View Post
    none of my NIC cards exhibits the PE3's behavior. I should probably extend my retro-collection of hardware to test software on a richer variety of platforms.
    If you revisit this issue in the future, grab an Intel Etherexpress 8/16 card, as it exhibits the same problem. Here's the exact packet driver I was using: ftp://ftp.oldskool.org/pub/drivers/I...APTER/EXP8.COM

    I think one reason some people initially reacted strongly to bugs in etherdfs is because it was targeted to now-vintage systems, which are known to be failing and flaky. When the software mistakenly causes data corruption, it actually triggers a whole slew of "what caused that?" troubleshooting: The RAM, hard drive, and NIC must now be extensively tested to ensure one of them aren't starting to fail, since it is common for them to fail. When earlier versions of etherdfs lacked error checking, the symptoms (copied files were corrupt; programs would hang; etc.) presented as everything from a failing hard drive, bad RAM, or even bad components on the motherboard. For people new to the hobby, it could have sent them on a wild goose chase for days.

    TL;DR Programming defensively is essentially mandatory when writing new software for older systems.

    PS: I am in favor of etherdfs and its core concept; it's an option for those who don't want to invest in XT-IDE hardware. Maybe someday you'll let me rewrite the DOS TSR into pure assembler (just because you *can* hack up C doesn't mean you *should* ;-)
    Offering a bounty for:
    - The software "Overhead Express" (doesn't have to be original, can be a copy)
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  4. #24

    Default

    Quote Originally Posted by Svenska View Post
    I will have to dig into this at some point as well, unfortunately. Do you know any specific document (or good code) pointing out pitfalls, or is it better to simply consult EtherDFS?
    There are a few places that you might want to consult regarding the redirector API:
    - source code of open-source/public domain CDROM drivers (but you must be comfortable with assembly, and obviously you will only find there READ-related operations)
    - the FreeDOS kernel - a truly interesting read, although you will have to work your way backward, from the "consumer-side" code into deducing what the "producer" is expected to provide
    - the "Undocumented DOS" book, by Andrew Schulman et al. If you're serious about this, you really should acquire this book. The authors did a marvelous job at reverse-engineering the INT 2Fh API, tracking it across several versions of MS-DOS

    Quote Originally Posted by Svenska View Post
    Exactly that is why I can't take that approach. Sigh.
    May I ask, what is it that you are working on, if it's not a secret?

  5. #25

    Default

    Quote Originally Posted by Trixter View Post
    If you revisit this issue in the future, grab an Intel Etherexpress 8/16 card, as it exhibits the same problem. Here's the exact packet driver I was using: ftp://ftp.oldskool.org/pub/drivers/I...APTER/EXP8.COM
    Thanks! I will remember to grab such a card if only I get the occasion.

    Quote Originally Posted by Trixter View Post
    I think one reason some people initially reacted strongly to bugs in etherdfs is because it was targeted to now-vintage systems (...) For people new to the hobby, it could have sent them on a wild goose chase for days.
    That's a possible theory, yes, but I must say that the few people that got actually bitten by EtherDFS (including yourself and Brian) have been always very helpful and cooperative. The only heat I ever got was from "non-users" (one, to be specific).

    Quote Originally Posted by Trixter View Post
    Maybe someday you'll let me rewrite the DOS TSR into pure assembler (just because you *can* hack up C doesn't mean you *should*
    Well, I am more of a "C" person - I can read and write assembly, but I get a severe headache as soon as there is more than a couple dozens of lines to decipher... To each his own, I guess. That being said, you are most welcome to produce an alternative 'asm' version of the EtherDFS client, if that's something you'd enjoy. I probably won't maintain such a version (due to my aforementioned mental limitation), but still I'd be happy to see such thing happen, esp. if it comes from someone as talented in this art as yourself. Although to be honest, the part that is the most in need of love today is the server part (the current implementation is mostly a quick & dirty hack).
    I have also two major EtherDFS issues that I'd like to solve within my lifetime: games that refuse to start from a network drive (possibly due to stack exhaustion by the packet driver, but needs to be investigated) and the fact that files copied on a network drive loose their original timestamp (the INT 2F API does not provide a "setdate" function sadly, this would need to be implemented as a very nasty workaround). Some SHARE support would also be nice somewhere in the future... Currently two concurrent writes from two different machines to the same file will likely lead to troubles. So many things to do, so little time!

  6. #26

    Default

    Quote Originally Posted by mateuszviste View Post
    Exactly that is why I can't take that approach. Sigh.
    May I ask, what is it that you are working on, if it's not a secret?
    Basically, an application-specific DOSBox-alike, so an emulator. I want/need to be able to run a true DOS, support FOSSIL, and have file-based access to the host file system with SHARE support. The feature list makes it quite obvious where this is going, I guess. In any case, I haven't found any program supporting this - apart from vDOS, which is closed-source and Windows-only.

    Thanks for the hints, I'll definitely come back to them when I am closer to a working environment.

  7. #27

    Default

    Quote Originally Posted by Svenska View Post
    Basically, an application-specific DOSBox-alike, so an emulator. I want/need to be able to run a true DOS, support FOSSIL, and have file-based access to the host file system with SHARE support. The feature list makes it quite obvious where this is going, I guess. In any case, I haven't found any program supporting this - apart from vDOS, which is closed-source and Windows-only.
    Interesting... But isn't that exactly what Dosemu is capable of? BTW, DOSemu sources may also be an interesting lecture, since it relies on the network redirector for accessing host files. I don't know if it comes with SHARE support, though.

  8. #28

    Default

    You are right, but DOSEMU is Linux-only (and not the easiest software to configure). I did a prototype using an i8080 core and CP/M (obviously without file access), which is tiny (some 30 KB executable, 230 KB RAM) and I'd like to extend that.

    But thanks for the hints, before I derail the thread completely.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •