X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f References: Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Jose Miguel =?ISO-8859-1?B?UOlyZXo=?= Newsgroups: comp.os.msdos.djgpp Subject: Re: Need to hook INT 21h from a DJGPP TSR Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit Lines: 66 X-Complaints-To: abuse AT easynews DOT com Organization: EasyNews, UseNet made Easy! X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly. Date: Fri, 07 Oct 2005 09:44:26 GMT To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Hi All! Thank for your replies, especially Rod Pemberton and DJ Delorie. Indeed I don't wanted to start a flame. :-) So please don't begin flamming like "why you said that". :-) Rod Pemberton writes: > This is your mistake -> PM TSR <- > I STRONGLY suggest a RM TSR(16-bit) by using OpenWATCOM or BorlandC > or assembly. If you were just writing an application there wouldn't > be too many problems with implementing int 0x21. But, you are > wanting a TSR. Rod, thanks for your kind reply. Since I'm using the DJGPP TSR kit (as pointed by DJ Delorie) this closes your A) and B) points. (My TSR is working, although may be not rock solid). As for C), I was not aware the TSR kit itself calls RM INT 21 (keep.c, line 31). I hope however this is not a problem since in my little example I just chain to the old handler. So lets assume C) point is solved. Talking about D), my TSR will not be invoked in the middle of a DOS operation (At least not invoked via a keystroke or something). Anyway, I don't care if it is, I will be serving INT 21 long file name operations *ONLY*. I suppose I will be called by DOS itself, and since it's the responsibility of the caller to swap and restore these DOS structures, let's assume I WILL NOT call DOS again inside my handler. All disc operations will be done via BIOS. I hope all DPMI memory operations (malloc) don't call DOS. :-) I'm not saying I'm not aware of the INDOS or the Critical Error flag, but I don't know to what extent this will be needed. And about E), I don't care about other DPMI extenders. Really. This will be used as a backup/restore utility to access foreign ext2 partitions, perhaps NTFS in the future. In fact, may be this utility will be used with a DOS bootable disk and the user will never use DOS again. I may fall back using a real mode TSR, with those ugly and far long forgotten 16 bits near pointers, using XMS for extra memory buffers, but I hoped this could be done easily with DJGPP. The problem is: I know this can be done. There are programs doing exactly like that. I know at least one TSR Device Driver for accesing NTFS partitions in DOS written in DJGPP (Protected Mode). Talking back about my post, I have tried different documentation, including: DJ Delorie's own "Guide: Intercepting And Processing Hardware Interrupts", [http://www.delorie.com/djgpp/doc/ug/interrupts/hwirqs.html] and "The Dark Art of writing DJGPP Hardware Interrupt Handlers" (By Alaric B. Williams) [http://www.geocities.com/SiliconValley/Vista/6552/djints.txt]. But the problem remains, I don't want a hardware interrupt. I was looking for a replacement wrapper for _go32_dpmi_allocate_real_mode_callback_iret since I suspect my problem lies in the fact those wrappers are non reentrant. Rod, I'm not a such assembly guru but I can understand it and write some code. I'm not confident to write an assembly wrapper myself, but I can manage to understand. Let's get straight again with my requirements: I need to hook INT 21 to service function AH=71 ("Windows95 Long File Names", Perhaps a few others). The problem is that I need a TSR and I want to code it using DJGPP Protected Mode. I will forget some facilities like virtual memory/paging, for simplicity. I returned to DOS since long, long, long, long ago :-) but I remember this was easily done using Borland TurboC and the like. Why is this so hard to do now? Cheers, Jose Miguel.