From: "deckerben" Newsgroups: comp.os.msdos.djgpp References: <054d01c2fdc9$ffa76710$0600000a AT broadpark DOT no> Subject: Re: porting PCI card driver from NT to DOS Date: Tue, 8 Apr 2003 17:04:50 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Lines: 48 Message-ID: <3e92e439$0$18023$9b622d9e@news.freenet.de> NNTP-Posting-Host: 213.7.8.176 X-Trace: 1049814075 news.freenet.de 18023 213.7.8.176:1227 X-Complaints-To: abuse AT freenet DOT de To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com "Gisle Vanem" wrote in message news:054d01c2fdc9$ffa76710$0600000a AT broadpark DOT no... > "Octavi Fors" said: > > > I understand porting to DOS would be complex, but do you it would > > be possible, in theory. > > Yes, of course. > > > In particular, is djgpp able to handle PCI bus 32-bits I/O interrupts? > > Which djgpp command could handle this? > > AFAIK, interrupts coming from a PCI device is handled in the same > way as coming from a ISA device. So you can use the "normal" > interrupt hooking (_go32_dpmi_set_protected_mode_interrupt_vector() > or _go32_dpmi_allocate_real_mode_callback_iret). The problem is that the resulting port will not work for any DJGPP user under NT/W2K/XP because the NT kernel locks all PCI ports and will not allow direct access via DOS or DPMI. This is the biggest problem we were trying to crack with the MSDOS Mesa port... we ended up just supporting VGA (which is all NT will allow - even if I have a good on-board VESA chip). > You biggest problem would be to query the PCI-BIOS where > the IRQ and I/O ports are assigned. Look at my libpcap port > for an PCI / BIOS32 example. > http://www.bgnett.no/~giva/pcap/libpcap.zip Gisle, have you ever tried to port the pcap library from www.tcdump.org to DJGPP-Watt32? The API it uses seems to be the one of choice ammong some of the GNU developers. I was successful porting it using the --with-pcap=bpf configure option, and replacing the distribution copy of bpf\net\bpf.h with the one from the Watt32 distribution. Nevertheless, I have encountered two problems: 1. pcap_findalldevs crashes (at least under W2K). 2. appearant lack of any system device name for network (like /proc/net/dev) The third possibility would be if Watt-32 supported an ifaddrs interface (getifaddrs & freeifaddrs). Do you know if this is possible? Ben