line-devel — LINE development list

[line-devel] newbie question

[David E. <te...@ge...>]

Hi,

I have downloaded line and runned it,

What I'm looking for, is a way to run a FlexLM daemon that is compiled for
Linux, under Windows, to serve licenses for Linux computers.

I have tried /cygdrive/c/linux/line-0.5/line.exe
/cygdrive/c/linux/lm/lmgrd.exe and it exits with error level -2.

Any ideas from any of you?

Thanks in advance, and please forgive my english.

David.

[line-devel] RE: Line development

[McMechan, J. <McM...@na...>]

Not much work has been going on with Line itself.

Some similar work is going on over at user-mode-linux.sourceforge.net
I don't recall anyone reporting Line as being moved but that may have
happened.
It was mildly active back in December.

If you want to work on Line, its recent status is "reasonably useable" as I
recall.

Good Luck:)

[line-devel] Line development

[John V. <jp...@ho...>]

Hi,

Is anyone currently doing any work on "LINE"?
(ie. http://line.sourceforge.net)

Thanks,
/John



_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

[line-devel] Job posting

[Erik P. <epa...@cs...>]

This is a bit off-topic, but I know there's at least one person who's qualified
for this job on this list :) 

My research project at the University of Wisconsin is looking for someone to 
do low-level hacking on Windows NT/2K/XP. We write a distributed batch
system, and Microsoft gave us some money to get the Windows version at the
same level as the Unix version (specifically, we want to support Process 
checkpoint and migration, along with transparent I/O redirection across the
network.) We also do a lot of work in the Grid Computing world, and there
would probably be some work on that front involved with this as well.

Please send any questions to me off the list, and I apologize if this is 
out of line for the list. The official job listing is linked to from
http://www.cs.wisc.edu/condor/

Thanks,

-Erik
 

Title: Systems Programmer
Minimum number of years and type of relevant work experience: 
 Must have a minimum of 2 years of experience with C/C++ and WIN32 API System 
Services. (Experience with MFC or other GUI technologies is NOT important.) 
Instead, successful applicant will have experience and understanding of 2 or 
more of the following: WIN32 API, WIN32 memory architecture, WIN NT/2K 
process/thread management and internals, security subsystem internals 
including impersonation and DACL manipulation, use of the DDK. Experience in 
development and maintenance of a large software package system using C++/C 
and/or experience with UNIX, POSIX, Windows NT/2K/XP system administration, 
net technologies, SOAP/XML, WIN2K/XP device driver development, Java, and/or 
scientific computing applications an advantage. Must have excellent oral and 
written communication skills. Must have a minimum of 7 years of experience to 
be hired at the senior level.  

Principal duties: 
 As a member of a research team of faculty, staff, and students at the UW 
Computer Sciences department, the systems programmer will assist in 
development, maintenance, support, and deployment of current and future 
versions of "Condor", a distributed resource management system. 
http://www.cs.wisc.edu/condor/. The systems programmer will collaborate with 
the rest of the research team on code development, maintenance, and porting by 
performing systems level code development. The systems programmer will have 
primary responsibility for the port of Condor to Windows NT/2K/XP. As such, 
systems programmer will be responsible for development of mechanisms on 
Windows NT/2K/XP as required to support Condor research. Examples include 
trapping of WIN32 system calls, transparent process migration, redirection of 
I/O, process sandboxing, integration of active directory, API exposure via 
DCOM and SOAP; also some systems administration work on WIN NT/2K/XP. The 
systems programmer will interact with users and help them install and utilize 
the Condor system. S/he will work to maintain Condor releases, including work 
on bug tracking, documentation, web-site maintenance, and consulting. 

Re: [line-devel] Information Request

[Erik P. <epa...@cs...>]

On Fri, Dec 07, 2001 at 05:06:34PM +1100, Chris Hocking wrote:
> Hello List,
> 
> I am a newbie to this list so please bear with me! ;)
> 
> I just want to ask a question regarding the compadibility and capacity of
> Line. I am making (or administrating really) a Open Source OS project. One
> of the functions of the OS is to natively emulate Linux/Unix functions.
> Could the Line source be useful in that regard?
> 

Yes, but probably not that useful.

LINE would be useful from the angle of seeing just what is needed to load a 
Linux ELF binary and execute it, and servicing the system calls it makes. 

If you were writing the OS from scratch, you could implement a lot of what LINE
needed right in the OS, instead of having to hack it on top of Win32.

Make sure your OS can service the software interrupts the Linux binaries will
make, and ideally allow those to be services by another user-level process.

Another really cool call that Windows has is being able to allocate memory in
another processes address space. 

Good luck!

-Erik
 

[line-devel] Information Request

[Chris H. <ho...@pl...>]

Hello List,

I am a newbie to this list so please bear with me! ;)

I just want to ask a question regarding the compadibility and capacity of
Line. I am making (or administrating really) a Open Source OS project. One
of the functions of the OS is to natively emulate Linux/Unix functions.
Could the Line source be useful in that regard?

Any information would be fantastic!

Bye,

Chris Hocking

RE: [line-devel] Hrm.

[Michael V. <mv...@qu...>]

Hi Michael,

These fixes you've been doing sound really useful.  If you sent them to me 
in small patches, I'll apply them to the LINE source tree as soon as I can.

Thanks!
Mike


>I've been looking at the following issues:
>
>1. Fixed an apparent bug in exec which meant command line parameters
>weren't being passed properly to exec'd processes.
>
>2. Modified exec to try adding a .exe extension to the filename so that
>Linux programs could call Windows programs (or the Cygwin equivalents of
>Unix utilities).
>
>3. Prevented cygwin from VirtualAllocing in the lower 1.5GB area of
>virtual memory. My executable wouldn't load because it need to mmap at
>an absolute address which was stolen by Cygwin's initial VirtualAllocs.
>The method I used was to call VirtualAlloc to reserve the memory before
>the Cygwin DLL was fully initialized, forcing Cygwin to use a higher
>address. Once in mmap_setup, this reserved memory is freed for use by
>LINE.
>
>4. Tried to maximize the amount of (contiguous) virtual memory space
>available to the Linux programs. This opened up a can of worms - you
>can't really control where cygwin1.dll will get loaded... I tried quite
>a few schemes. Basically, if Cygwin has already been loaded before LINE
>runs, you have to use the address it was already loaded at. Cygwin has
>what appears to be a fairly broken scheme of allocating memory directly
>after the end of where the DLL was loaded, which is very difficult to
>avoid being right on top of another DLL if you try to squeeze the memory
>map.
>
>5. Added support for detecting and utilizing 4GB tuning. This gives the
>Linux program an extra 1GB more virtual address space when running under
>Windows 2000 Advanced Server with the /3GB boot.ini setting enabled.
>
>6. Commented back in a few of the syscalls which #ifdef'ed out in LINE
>0.5 and hacked in support for l_times.
>
>7. Cygwin seems to number some of its signals differently to Linux (e.g
>SIGCHLD). I failed to get a remapping layer in the system call handling
>code to work - I never got one of my programs that relied on SIGCHLD
>working.
>
>8. rt_ signal syscalls aren't fully supported. I didn't get around to
>seeing what changes needed, but I noticed that the Cygwin DLL has a
>compile time option to enable them.
>
>9. Doesn't support IPC... I tried and failed to use some IPC code
>already available for Cygwin.
>
>10. Made a few cosmetic changes to make LINE less verbose.
>
>A bit of background - most of my work involves running Windows programs.
>One of these programs is now only supported under Linux and no longer
>under Windows, so my aim was to get it working under LINE to avoid
>rebooting my computer all day long. In all, I got around 90% of the way
>there - most of the features work perfectly under LINE. In the end, I
>bit the bullet and started running it under Linux itself... I soon
>discovered that Linux's VM was (and pretty much still is) broken (both
>Rik's and Andrea's, both in different ways). Programs that ran perfectly
>well under LINE struggled on the same machine under Linux, taking
>several times longer to execute. In the end I topped up the machine to
>4GB of memory. Now the only problems I'm getting are intermittent kernel
>oopses and strange lockups, which I'm working on. Bring back the BSOD,
>all is forgiven!

Re: [line-devel] Hrm.

[Michael V. <mv...@qu...>]

 > Like 8 months ago, I promised to look into NtMapViewOfSection. Well,
 > Friday I finally did, and like the book says, it can mmap() on 
page-boundries,
 > and not just 64K boundries. I've been reading the LINE mmap.c code, and I'm
 > starting to understand what it's doing.
 >
 > Hopefully later next week, when I get back from San Diego,  I'll have a 
patch
 > that ditches the cygwin mmap() and lets LINE manage it internally.

Cool.  Send it along when you have it working!

 > I'll also probably have to redo a lot of the memory management stuff - 
it looks
 > like memory is managed with a big array, with one byte per 64K chunk. Maybe
 > it's time to steal the page table code out of Linux...

Yeah, that would probably be a good idea.  At the time I did the 64K chunk 
array setup because it was quick (to implement).  But it definitely could 
be improved upon :)


Mike

RE: [line-devel] Hrm.

[Michael C. <mc...@ti...>]

Hi Erik,

I've been looking at the following issues:

1. Fixed an apparent bug in exec which meant command line parameters
weren't being passed properly to exec'd processes.

2. Modified exec to try adding a .exe extension to the filename so that
Linux programs could call Windows programs (or the Cygwin equivalents of
Unix utilities).

3. Prevented cygwin from VirtualAllocing in the lower 1.5GB area of
virtual memory. My executable wouldn't load because it need to mmap at
an absolute address which was stolen by Cygwin's initial VirtualAllocs.
The method I used was to call VirtualAlloc to reserve the memory before
the Cygwin DLL was fully initialized, forcing Cygwin to use a higher
address. Once in mmap_setup, this reserved memory is freed for use by
LINE.

4. Tried to maximize the amount of (contiguous) virtual memory space
available to the Linux programs. This opened up a can of worms - you
can't really control where cygwin1.dll will get loaded... I tried quite
a few schemes. Basically, if Cygwin has already been loaded before LINE
runs, you have to use the address it was already loaded at. Cygwin has
what appears to be a fairly broken scheme of allocating memory directly
after the end of where the DLL was loaded, which is very difficult to
avoid being right on top of another DLL if you try to squeeze the memory
map.

5. Added support for detecting and utilizing 4GB tuning. This gives the
Linux program an extra 1GB more virtual address space when running under
Windows 2000 Advanced Server with the /3GB boot.ini setting enabled.

6. Commented back in a few of the syscalls which #ifdef'ed out in LINE
0.5 and hacked in support for l_times.

7. Cygwin seems to number some of its signals differently to Linux (e.g
SIGCHLD). I failed to get a remapping layer in the system call handling
code to work - I never got one of my programs that relied on SIGCHLD
working.

8. rt_ signal syscalls aren't fully supported. I didn't get around to
seeing what changes needed, but I noticed that the Cygwin DLL has a
compile time option to enable them.

9. Doesn't support IPC... I tried and failed to use some IPC code
already available for Cygwin.

10. Made a few cosmetic changes to make LINE less verbose.

A bit of background - most of my work involves running Windows programs.
One of these programs is now only supported under Linux and no longer
under Windows, so my aim was to get it working under LINE to avoid
rebooting my computer all day long. In all, I got around 90% of the way
there - most of the features work perfectly under LINE. In the end, I
bit the bullet and started running it under Linux itself... I soon
discovered that Linux's VM was (and pretty much still is) broken (both
Rik's and Andrea's, both in different ways). Programs that ran perfectly
well under LINE struggled on the same machine under Linux, taking
several times longer to execute. In the end I topped up the machine to
4GB of memory. Now the only problems I'm getting are intermittent kernel
oopses and strange lockups, which I'm working on. Bring back the BSOD,
all is forgiven!

I didn't see any problems with the 64k page boundary limitation in LINE;
I only saw mmaps being made to the same file within any given 64k page,
which works in LINE by virtue of all of its rounding up and down of
pointers in mmap.c.

Hope this helps,

Michael.

-----Original Message-----
From: lin...@li...
[mailto:lin...@li...] On Behalf Of Erik
Paulson
Sent: 03 December 2001 16:14
To: lin...@li...
Subject: Re: [line-devel] Hrm.


On Fri, Nov 30, 2001 at 10:32:23PM -0000, Michael Clarke wrote:
> 
> Hi Erik,
> 
> I am... I've made quite a few modifications of my own in order to get
> program to working with LINE... I guess I should have got them into 
> the source tree somehow.

Michael, 
	What have you been working on?

Like 8 months ago, I promised to look into NtMapViewOfSection. Well,
Friday I finally did, and like the book says, it can mmap() on
page-boundries, and not just 64K boundries. I've been reading the LINE
mmap.c code, and I'm 
starting to understand what it's doing. 

Hopefully later next week, when I get back from San Diego,  I'll have a
patch 
that ditches the cygwin mmap() and lets LINE manage it internally.  

I'll also probably have to redo a lot of the memory management stuff -
it looks like memory is managed with a big array, with one byte per 64K
chunk. Maybe it's time to steal the page table code out of Linux...

-Erik
 

_______________________________________________
line-devel mailing list
lin...@li...
https://lists.sourceforge.net/lists/listinfo/line-devel

Re: [line-devel] Hrm.

[McMechan, J. <McM...@na...>]

That does sound useful, I was idly trying to figure out how to get
user-mode-linux
to use 64KiB pages but my ambition has been limited recently.  You could
look how
user-mode-linux uses mmap to manage page tables in addition to the kernels
native page tables.  One of the other Architectures uses 64KiB, Itanium I
think.

I seem to recall someone mentioning NtMapViewOfSection to be NT only.
Does it still exist in the newer versions of windows.
NT 5 became  Win2000 so it and XP likely have this.
I would not expect Win95/Win98 to have this call correct?

WinME is one I could not even guess well on.  Not that I am all that 
confident of my other guesses.

LINE is nice to, for example, bring up bash under Win98 and use real tools
I think I also was running WeirdX the Java based X server under windows for
some display windows.

> On Fri, Nov 30, 2001 at 10:32:23PM -0000, Michael Clarke wrote:
> > 
> > Hi Erik,
> > 
> > I am... I've made quite a few modifications of my own in order to get
> > program to working with LINE... I guess I should have got them into the
> > source tree somehow.
> 
> Michael, 
> 	What have you been working on?
> 
> Like 8 months ago, I promised to look into NtMapViewOfSection. Well,
> Friday I finally did, and like the book says, it can mmap() on
> page-boundries,
> and not just 64K boundries. I've been reading the LINE mmap.c code, and
> I'm 
> starting to understand what it's doing. 
> 
> Hopefully later next week, when I get back from San Diego,  I'll have a
> patch 
> that ditches the cygwin mmap() and lets LINE manage it internally.  
> 
> I'll also probably have to redo a lot of the memory management stuff - it
> looks
> like memory is managed with a big array, with one byte per 64K chunk.
> Maybe
> it's time to steal the page table code out of Linux...
> 
> -Erik
>  
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> line-devel mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/line-devel
> 
> 
> End of line-devel Digest
> 
> 

Re: [line-devel] Hrm.

[Erik P. <epa...@cs...>]

On Fri, Nov 30, 2001 at 10:32:23PM -0000, Michael Clarke wrote:
> 
> Hi Erik,
> 
> I am... I've made quite a few modifications of my own in order to get
> program to working with LINE... I guess I should have got them into the
> source tree somehow.

Michael, 
	What have you been working on?

Like 8 months ago, I promised to look into NtMapViewOfSection. Well,
Friday I finally did, and like the book says, it can mmap() on page-boundries,
and not just 64K boundries. I've been reading the LINE mmap.c code, and I'm 
starting to understand what it's doing. 

Hopefully later next week, when I get back from San Diego,  I'll have a patch 
that ditches the cygwin mmap() and lets LINE manage it internally.  

I'll also probably have to redo a lot of the memory management stuff - it looks
like memory is managed with a big array, with one byte per 64K chunk. Maybe
it's time to steal the page table code out of Linux...

-Erik
 

Re: [line-devel] Hrm.

[Vivek J. <viv...@ya...>]

What is PO-devel???

----- Original Message -----
From: "Erik Paulson" <epa...@cs...>
To: <lin...@li...>
Sent: Friday, November 30, 2001 11:50 AM
Subject: [line-devel] Hrm.


> I was reading the archives today, and it seems that line-devel has been
taken
> over by PO-devel.
>
> So who's reading this? :)
>
> -Erik, who actually has line-devel things to say...


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[line-devel] RE: line-devel digest, Vol 1 #24 - 1 msg

[McMechan, J. <McM...@na...>]

I am subscribed to line-devel and have not seen much activity either these
last few months.

I have tested it mildly and it did work for the few programs I ran but I
have not booted into NT much recently and so have had little need for LINE

LINE is certainly a interesting project the part that I was thinking would
be most interesting was running user-mode-linux under line under NT/2000 as
this would eliminate several classes of problems I had and I was hoping to
examine it later this winter.

What is PO-devel.  I was just thinking the list had hit a dry spell.

Re: [line-devel] Hrm.

[Erik P. <epa...@cs...>]

On Fri, Nov 30, 2001 at 10:32:23PM -0000, Michael Clarke wrote:
> 
> Hi Erik,
> 
> I am... I've made quite a few modifications of my own in order to get
> program to working with LINE... I guess I should have got them into the
> source tree somehow.
> 
> What is PO-devel by the way... I haven't come across it?
> 

PO is some sort of online game. I don't get any mail from it, and I don't 
think that they get mail from us, but both our archives go to the same
spot

Phoenix online:
http://www.murtos.com/games/po/nav.php?doc=main.php

An example of the strange archives:

http://www.geocrawler.com/lists/3/SourceForge/10551/0/

-Erik

> Thanks,
> 
> Michael.
> 
> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...] On Behalf Of Erik
> Paulson
> Sent: 30 November 2001 06:20
> To: lin...@li...
> Subject: [line-devel] Hrm.
> 
> 
> I was reading the archives today, and it seems that line-devel has been
> taken over by PO-devel. 
> 
> So who's reading this? :)
> 
> -Erik, who actually has line-devel things to say...
> 
> 
> _______________________________________________
> line-devel mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/line-devel
> 

[line-devel] Hrm.

[Erik P. <epa...@cs...>]

I was reading the archives today, and it seems that line-devel has been taken
over by PO-devel. 

So who's reading this? :)

-Erik, who actually has line-devel things to say...

Re: [line-devel] LINE Questions

[Michael V. <mi...@bl...>]

On Fri, 20 Jul 2001, Alex Rzasa wrote:

> Dear All;
>
> I am a neuroscientist at the University of Maryland, and I currently use a
> Linux machine for data collection and analysis.  However, it would be
> absolutely fantastic if I was able to run my Linux-based analysis software
> in Windows 2000.  I currently have the latest Cygwin installed; could
> somebody please tell me how to install LINE, as well as how to determine
> what files I should transfer from my Linux box to let my program work
> through LINE?  I would greatly appreciate anyone's help.  Your project is an
> amazing piece of work, and could help me immensely.  Thank you for your time
> and assistance.

Hi Alex,

To run LINE, you need three things from your Linux box:
1) The executable that you want to run
2) Any shared objects that the executable requires
3) Any data files that the executable requires.

Checkout <http://line.sourceforge.net/docs.php?f=chroot.txt> for a little
more details (although not much!) on how to setup the directory structure
on your Win2K machine.

Let me know if you need any more help!

Mike

[line-devel] LINE Questions

[Alex R. <ar...@wa...>]

Dear All;

I am a neuroscientist at the University of Maryland, and I currently use a
Linux machine for data collection and analysis.  However, it would be
absolutely fantastic if I was able to run my Linux-based analysis software
in Windows 2000.  I currently have the latest Cygwin installed; could
somebody please tell me how to install LINE, as well as how to determine
what files I should transfer from my Linux box to let my program work
through LINE?  I would greatly appreciate anyone's help.  Your project is an
amazing piece of work, and could help me immensely.  Thank you for your time
and assistance.

-Alex Rzasa

RE: [line-devel] RE: Interrupt vector

[Michael V. <mi...@bl...>]

On Wed, 13 Jun 2001, Andrew G. Tereschenko wrote:

> ntddk.h:119
> extern NTSYSAPI CCHAR KeNumberProcessors;
> ntdef.h:504
> typedef char CCHAR;          // winnt
>
> I think it's my DDK incompatibility.

I can't seem to find any version information on the DDK that I have, but
just downloaded it from Microsoft about a month ago.  In my DDK, it's:

wdm.h:111
extern PCCHAR KeNumberProcessors


> I will not post files (even 8K in ZIP) in list, here is a link:
> http://tag.odessa.ua/line/20010613.zip

ok, sounds good.


> > > Note about 64K pages - we heed own pagefault handler to support
> > SEG_FAULT
> > > signal ?
> >
> > I'm not sure what you mean?
>
> Can linux app proccess SEG_FAULT signal ?

Good question.  I wrote a quick little Linux app:

-------
#include <signal.h>
#include <stdio.h>

void seg_fault(int x)
{
  printf("Opps, segfault occured.\n");
  exit();
}

int main()
{
  signal(SIGSEGV, seg_fault);

  printf("Trying a segfault.\n");
  *(char*)0 = 0;

  return 0;
}
-----

Under Linux, the output is:
-----
$ ./fault
Trying a segfault.
Opps, segfault occured.
$
-----

When running under LINE without the driver enabled, the LINE debugger
kills the application when the segfault occurs.  LINE really should try to
pass that back to the app.  This will be a little tricky to do, but it's
possible.

With the driver, the app output "Trying a segfault" and then it just sits
there doing nothing!



I just found a new BSOD :)

I reboot my system with the driver installed (the driver is set for ..),
then I immediately remove the driver with 'remove.bat'.   That gives a
"BAD_POOL_CALLER" BSOD.

However if I reboot, run LINE once, and then remove the driver I don't get
a BSOD.



Mike

RE: [line-devel] RE: Interrupt vector

[Andrew G. T. <ta...@ib...>]

> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of Michael Vines
> Sent: Wednesday, June 13, 2001 7:44 PM
> To: lin...@li...
> Subject: RE: [line-devel] RE: Interrupt vector
>
[...]
> I tried switching the driver to use METHOD_BUFFERED but the 80.exe test
> program couldn't talk with it.  So I guess since METHOD_NEITHER seems to
> be working fine, we might as well leave it as is until somebody finds a
> problem with it.  This just means that line/src/int80/int80.h will need to
> be changed slightly, not a big deal.

Yea. I think the same.

[...]
> Cool.  It's not crashing anymore!

Nice to hear.

>
> BTW, I still had to add the dereferences to DebugServiceHooks.cpp before
> it would compile for me.  Here's a diff:
> ------------
> 137c137
> <       oldIDT =(PNT_IDT) ExAllocatePool(NonPagedPool,
> *KeNumberProcessors*sizeof(NT_IDT));
> ---
> >       oldIDT = (PNT_IDT) ExAllocatePool(NonPagedPool,
> KeNumberProcessors*sizeof(NT_IDT));
> 143c143
> <     for ( char cpu=0; cpu<*KeNumberProcessors; ++cpu )
> ---
> >     for ( char cpu=0; cpu<KeNumberProcessors; ++cpu )
> 172c172
> <     KeSetAffinityThread( pThread, (1<<*KeNumberProcessors)-1 );
> ---
> >     KeSetAffinityThread( pThread, (1<<KeNumberProcessors)-1 );
> ---------
It's valid fix, but i have:

ntddk.h:119
extern NTSYSAPI CCHAR KeNumberProcessors;
ntdef.h:504
typedef char CCHAR;          // winnt

I think it's my DDK incompatibility.

I've moved this to NUMBER_PROCESSORS definition for easy fix.

I will not post files (even 8K in ZIP) in list, here is a link:
http://tag.odessa.ua/line/20010613.zip

>
> > Note about 64K pages - we heed own pagefault handler to support
> SEG_FAULT
> > signal ?
>
> I'm not sure what you mean?

Can linux app proccess SEG_FAULT signal ?

If  ViewSection will be be able to map in 4Kb we can use

1. PAGE_GUARD page protection and SEH (structured exception handling)
 "If a program attempts to access an address within a guard page, the system
raises a STATUS_GUARD_PAGE (0x80000001) exception. The system also clears
the PAGE_GUARD modifier, removing the memory page's guard page status. The
system will not stop the next attempt to access the memory page with a
STATUS_GUARD_PAGE exception."
2. NT Kernel event Tracing
Event trace controllers can include all page fault events by specifying
EVENT_TRACE_FLAG_MEMORY_PAGE_FAULTS in the Flags member of an
EVENT_TRACE_PROPERTIES structure.
[Are this allow to change behaivior of page fault or only log ????]
3. Installing own Page fault interrupt ?

BTW, Does anybody know how NTVDM handle interrupts ?

>
> Is there anybody on the list that has access to a NT 4.0 machine?  It
> would be nice to know whether or not the driver works on NT, and perhaps
> provide a compiled binary for NT.

Will be realy nice :o)
Due to my firm developement nature we don't have NT :o(

=============================
Andrew G. Tereschenko
Software Engineer

RE: [line-devel] RE: Interrupt vector

[Michael V. <mi...@bl...>]

On Tue, 12 Jun 2001, Andrew G. Tereschenko wrote:

> > Then I had a little trouble enabling the driver.  I tracked it down to the
> > IOCTL parameters.  The original driver used METHOD_BUFFERED, but your
> > driver uses METHOD_NEITHER.  I'm not sure what the difference is though,
> > but the 80.exe test program works fine when I recompile it using
> > METHOD_NEITHER.
>
> Do you know that this bit mean in IoCtls ?
>
> METHOD_BUFFERED if the driver transfers small amounts of data for the
> request
> METHOD_IN_DIRECT if the underlying device driver will read a large amount of
> data for the request using DMA or PIO and must transfer the data quickly
> METHOD_OUT_DIRECT if the underlying device driver will write a large amount
> of data to the device for the request using DMA or PIO and must transfer the
> data quickly
> METHOD_NEITHER if the driver can be sent such a request only while it is
> running in the context of the thread that originates the I/O control request
>
> What is the best ?
> I don't transfer anything except errcode for command.

I tried switching the driver to use METHOD_BUFFERED but the 80.exe test
program couldn't talk with it.  So I guess since METHOD_NEITHER seems to
be working fine, we might as well leave it as is until somebody finds a
problem with it.  This just means that line/src/int80/int80.h will need to
be changed slightly, not a big deal.


> > But:
> > 0) Reboot machine
> > 1) Run LINE (without the driver loaded)
> > 2) Load the driver using 'install.bat'
> > 3) Run LINE using driver
> > 3) Unload the driver using 'remove.bat'
> > 4) Run LINE.
> >
> > and I get a BSOD everytime. (DRIVER_IRQL_NOT_LESS_OR_EQUAL)
> >
>
> Try this new version. I make valid cleanup code.

Cool.  It's not crashing anymore!


BTW, I still had to add the dereferences to DebugServiceHooks.cpp before
it would compile for me.  Here's a diff:
------------
137c137
<       oldIDT =(PNT_IDT) ExAllocatePool(NonPagedPool, *KeNumberProcessors*sizeof(NT_IDT));
---
>       oldIDT = (PNT_IDT) ExAllocatePool(NonPagedPool, KeNumberProcessors*sizeof(NT_IDT));
143c143
<     for ( char cpu=0; cpu<*KeNumberProcessors; ++cpu )
---
>     for ( char cpu=0; cpu<KeNumberProcessors; ++cpu )
172c172
<     KeSetAffinityThread( pThread, (1<<*KeNumberProcessors)-1 );
---
>     KeSetAffinityThread( pThread, (1<<KeNumberProcessors)-1 );
---------


> Note about 64K pages - we heed own pagefault handler to support SEG_FAULT
> signal ?

I'm not sure what you mean?




Is there anybody on the list that has access to a NT 4.0 machine?  It
would be nice to know whether or not the driver works on NT, and perhaps
provide a compiled binary for NT.


Mike

RE: [line-devel] RE: Interrupt vector

[Andrew G. T. <ta...@ib...>]

> Hi Andrew,
>
> I tried building it on my W2K machine this morning, I had to make a small
> change to the source before it would compile:
>
> --------
> diff -r int80.new/src/DebugServiceHooks.cpp
> int80.andrew/src/DebugServiceHooks.cpp
> 137c137
> <     for ( char cpu=0; cpu < *KeNumberProcessors; ++cpu )
> ---
> >     for ( char cpu=0; cpu<KeNumberProcessors; ++cpu )
> 160c160
> <     KeSetAffinityThread( pThread, (1<<*KeNumberProcessors)-1 );
> ---
> >     KeSetAffinityThread( pThread, (1<<KeNumberProcessors)-1 );
> --------

Hmm.. I agree - it was original source.

>
> Then I had a little trouble enabling the driver.  I tracked it down to the
> IOCTL parameters.  The original driver used METHOD_BUFFERED, but your
> driver uses METHOD_NEITHER.  I'm not sure what the difference is though,
> but the 80.exe test program works fine when I recompile it using
> METHOD_NEITHER.

Do you know that this bit mean in IoCtls ?

METHOD_BUFFERED if the driver transfers small amounts of data for the
request
METHOD_IN_DIRECT if the underlying device driver will read a large amount of
data for the request using DMA or PIO and must transfer the data quickly
METHOD_OUT_DIRECT if the underlying device driver will write a large amount
of data to the device for the request using DMA or PIO and must transfer the
data quickly
METHOD_NEITHER if the driver can be sent such a request only while it is
running in the context of the thread that originates the I/O control request

What is the best ?
I don't transfer anything except errcode for command.

> LINE seems to run normally with the new driver.  However, when I remove
> the driver then try to run LINE again I get a BSOD.  I guess it isn't
> cleaning up after itself properly.

Yea. You are right....


> Here's a little more information that might help:
> 0) Reboot machine
> 1) Run LINE (without the driver loaded)
> 2) Load the driver using 'install.bat'
> 3) Unload the driver using 'remove.bat'
> 4) Run LINE.
>
> This works fine.
>
> But:
> 0) Reboot machine
> 1) Run LINE (without the driver loaded)
> 2) Load the driver using 'install.bat'
> 3) Run LINE using driver
> 3) Unload the driver using 'remove.bat'
> 4) Run LINE.
>
> and I get a BSOD everytime. (DRIVER_IRQL_NOT_LESS_OR_EQUAL)
>

Try this new version. I make valid cleanup code.

> I also noticed that on the top of all the driver source files, there is
> the copyright notice '1999 Jose Flores' but there is no indication of what
> license (if any) the source has been released under?

I think there is no any restriction.
It's listed as code sample for article.
http://www.wdj.com/articles/2000/0002/0002a/0002a.htm


Note about 64K pages - we heed own pagefault handler to support SEG_FAULT
signal ?

=============================
Andrew G. Tereschenko
ICQ: 220220


begin 666 src.zip
M4$L#!!0``@`(`-6+R2J3X(IUCP$``#\$```/`"0`1&)G5')A<$-O;6UO;BYH
M"@`@```````!`!@``)7TPO#PP $`"#QZN?+ `4 .8]:4,;\!K9'?;]HP$,??
MD?@?3IVT@80@C!=XZ$/FN"5;$E=)6FD2D@7A:#R!7=EN@?^^)OQLR[H]<%$L
MZ^[R^=[EV^E<7R3JM4X'JB.8/.9Z_$348J%DN]SDJGQW,!C 3V40;N9*HSD4
MJH,H:<="&ICB3$AAA9*F!7;]A"[A;F@+*"HD3)0MP2JP)<+M?0A?8:K%"^H#
M;/]>:K-Z[8N823<'\.#';9[Z=YRP.&8)+[FK51/CV=KFN>@?_FO$X .!%!AD
M<.'==_L%.7^@:1:R!*#AK;J>YS4WQCUKC=*",\ XTV")WS2"NS2&XK&$R=HB
M"%.95:_!)^%8B_$?I?>D-D1J^>;[A9"[<KMY.ME-&%$>T(>04#YD[%>8Y #>
MR@WH]7N>=]H:,I)'5=-1>),A+*"-,YR6X_1[W1;$-!^R@"<TS(<T;6TU_>0W
M]PFA6=9\+W&?G(K\6^+[_T@<19)\3TG\F&Y%HJO1*, 74>!H% GYO,K6IAC/
MYRE.A<;"*GUUXB;+/A J@#);AOD$XC HIV)6K[T"4$L#!!0``@`(`)B&R2IH
M$J!LIP```%T!```,`"0`1&)G5')A<$1B9RYH"@`@```````!`!@``+B+=^OP
MP $`"#QZN?+ `<#S7-:4,;\!?8]!#H(P$$7W)-QA`IMR!7$CEE2B"X6Z(YEH
M'$@3;+3@^6-;))(8_+.9_L[K_,:JT3=J`)%+Y'EV%KA##(/8FDK3C^_*,@[A
MF?"GSR271Z/TP.#>MY" $[^VHQ?93IK+8P51DMJ+.@Q@61/F7YKI/Y5^M]7:
MKIEGVU157DHLRM.!0>?3C1:#/0D:MB]C2 ^%>78L@;4;\3AU/2W_<1S1-]7,
M@TV>;=Y02P,$% `"``@`9H[)*DR*#1?.`0``@P4```X`) !$8F=4<F%P4')O
M8W,N: H`( ```````0`8``"P%Z#S\, !``@\>KGRP %@>E[6E#&_`;546VO;
M,!1^GL'_X9#"R$9PV&/8!9PX:;JVL;$5QIZ,+\>QJ",926X7QO[[)-EIL]%'
M5T*W[QQ_Y^@[PO/YUU&:Z\SG8*<@/Q"1M9'@A?1J`UGXTV*Q@.]<(FP:+E ^
M&^RDO157IQ8EO(<2*\JHHIQ)Z"26D)^ JQK%F1LD[T2!<.1EAXV$9QXSQKJ/
MZUS1BNE<($V#Y36)_2B-XG"5I-LTU4:;);YN-!U_*10,)JO);T/%BJ8K$;XP
M598/7OWM$GNB)HX%_US@D^&Z>O'JR2N&%3\>.;,VT\>LY3O3X+)=PQV$L 1?
MK\FX0K]QZA'$.G-BQT]]6H^=__"2-X(?(<"\.R0H'FF!6\X?I%>T;>_B.CN2
M$)_L=?@;1I4I88MB^N&SL2W#\,[@4F5-\S_+U'7.MS%^D!NPQ_JO7UZ;ZSQR
M6KI.0"S)`86),P3I34M!V2'@3^S?#-ZH#'O80:#%7^G=O19_I\NPU@A HG=[
MV.@^;CTNQ0A^A''@.K>8H/(K^V,YD5I@5O::1K=D&Z_]8&9/UANRP>\^D[W(
M9WU>B'7&E"G8$3^Z<1W9:D55-86BS@1\S+NJ0C&#@NMJ#EC%Q3%3,_ \;Z"[
M0E;2RG7^`E!+`P04``(`" `EI\PJ,MVL@3H'```X$@``%0`D`$1E8G5G4V5R
M=FEC94AO;VMS+F-P< H`( ```````0`8``"?!!II\\ !``@\>KGRP %@>E[6
ME#&_`;58_T_;R!+_&23^AWE4:IUK&J"]=VJ;HB>3&$A)$PN;*ZBJHHV]27PX
M7FMW#<G=Z__^9G9MQP%ZTDD\2]CQSL[,9[[MC#DX.'Z6:V_WX #,K3^=AY+E
MG2C/Z=VL'7WX\ $^"\7A-!62JYI@;H-EGO(ES[0"EJ:@%QPB$7/0`A9"W)I%
M,8-1^$I!GT^+.2@N[Y*(*]S+-!*,F"6[Q94"E>#FNX0!RR#)-+R-.P"U-OI[
M+I-?)%F4%HATOS3:ER)2G<5^DY3$VJP\I^*#@QVZH'F=P1#&< (N/H/G5+:W
MV_\ZONRCBIB<'UC?_\XC+20<P^'J_6&7`% D,\VE+'(-=Y:,T8AANC8AVML]
M&8^'M'/ZE9]C8)%T#*?N,/"ZQ.Q*#O?<A!PI:ZX[G?M$+T"))<=;D9((?Q1.
M!OT00*0Q/8]A=#4<=G=*`&.9S).,I4 TGFFYAAG"H)0RX.=<5LE#NB3/4Q;Q
MIHU+MCHI9C,N@^1/CN+?_ONW7XX.W_[:M0J^L!48BIB!*"3P.]0"4\,!#I^V
M-I*FM9@N/+S(W$@7"/0%29JN-3?)+R*FT7C"S*<;45FQ]-"8A*LG11$H;NF0
M9,;:)JZ]W8O 'XPFPW'OPO),TR?E6,-A**);]'2E/$^RF*\>,U@>7R04="I6
M4[B%E*39\%1@*AC_MQ(8P!?P80@>/CT800@N_@U@#*/GK811&(1N>!7L[0ZR
M1%/)YUPZ&/2_]G:M0ZHGT(:$I90K&Q] :GS;W'K!-SL#]#5YWX&7TQ1:75))
M>R37A<S ZIX$5[V>%P1(_6%]:@ZW4\DY%+G)2FV!(9_"UZ@Z<.]$$N_MGL@D
MF_?%??88OK<B*;X0J6/KJ]4%2]DNMU+SBURR^9+9Q)UHOM+.ON^>>?OM?M@O
MRXV4H *D<;1@O[=O8< DYE&J<AXY&;OE,=7-%D\#E=),)Q%4^=B\U%I%J/V<
M97'*I:]E6:8^DVS)4:6"G"DZA,K\+(N_<NR$J:7]]1?UB#IXO06/;DT9!C=!
MSQT.)\/!R+OV>I-S=]0?>I=V9[3,#0S.5FTX['MN_\3S3A>6^'GD@0W>+.61
MGI18*RU?QK\;<C_X^,B*-G@GUW;;X-(+^\2SM_M T$>[P;\*SDWLW.N&`2JA
MI@J*98E>0T3F;*O%[>TG==MMO2_^9MMA:9"U!S(Q6=CME<(:P\GU0_-PJ5V&
MS@\OX9L7^*_??Z].#\E93$U"IB@0O($/,RF6%/&'>!^):!.V2H[BVG!CE$N#
MH(0(CP"Y3P!Z??3VNQ$T)T'!8QC!U<F&^]>_AT;"2G0H\5XFFD/&[XW<GW.Z
MU]]-V#='J^E-QBR1H64Y=8K:5R4V*R\791Y.5W;!WO^HTG.5Z&;(-@'\^("?
ME?QYH1;T?//N/?SD0H!$/3X&;S0.;@(2W%2T$;VS)3J17,?VYX_R'*G/L'"1
M*)@7:V"F.:9K2#(T-$V5*5XS#8ILT\[K7F['C8X1<FD.2P7AY94'R8SZ?"TN
M3F)@V5HODFS>MK,';<F$[M33(8S&H??18I&BT$G&P4F36PX"%<NRQ2(QELD=
MERW G\B":R:;%9MQ"V1<2+A?""K#8JK62O-EU1\1"E_E"%H!`X5@<%,D,BUQ
MMWQ3+I X"AB*<J:%AHAEL&!W'):%3A,J;Y-;4CD1QJO5ZFQC5@M1I#$Y2_*9
MD-P($AFJGJ(R= >/R;U)C/Y!QZB<Z6A1<YL"($>?70W:(&39RXT00LI7FO+1
MG*G&M%<*[H6\I5' .H)&\+YQ$<TN:R/D*DL%BSO6U78@I%9J8MQO3)<T'CHV
M2:K+#(]3(M3Y%\JB_DJHHHFODB_%';?<FRY238YY$NL3IOBFEU7ETFC>;IDC
M)"X6_]FF)S-PFC/L<0FK57:2#>ZR;Y<S;GG5N6].@-"72:8=</9)!JK<;YG&
M_\0T`4K+(D*)W'2FA4AC@H@/&G=5!<ZI>K4UL$6 =NK^[91^:(&W<LN!TS3\
MD<A\-N<QO;3A@H^*Y91+^J+A2@FI?E')GUS,G)*]POACYR'6&O-0T+&"H9#F
M$RZO1<%+6\H_J^-M262K`]&"28CRXOBP2X]/CP%VX?5KI#3"4 ?"OPC/+SVW
M#WEH<_,8#3SCNF>KT2XZE4EF* NX=F>SA-IG2:Z8VW#TZ9-1U&VHJ-!:TU&V
M/2-JHU\I\TTRI<QC<2QQ\2G>1G:B#.2@%\=JJC?9!&SFW /N;T]]JGWOH$T.
MI5QSSFKO[9I!>@?CV@O:4+VBZLGIT#VK!IZ)?^D%WBB$_S[:T?>'D\-W3Q#<
MX5?W)CB<V,I\3 ]O?&\2W 3OWO\V. LWNE_:;/U&@8;OZ.=-V5 G217_!U:C
M)[?$=6$SZ?W83$QUU@8F=+P\Q3!LK$P#C%UT:\Z7(J,NM)W3VW+^6<+]?;8Y
M1Y^>R/;6FZ-&`C;PCP30H4,G@P&<B?M.IV/^AR*IT=&QMLW4_!S_5_W2W;BI
M/,:HH5:C__\`4$L#!!0``@`(`"&IS"JWFZ4RO@D``,XC```/`"0`96YT<GEP
M;VEN=',N8W!P"@`@```````!`!@``#-GPFKSP $`"#QZN?+ `:"'8=:4,;\!
MM5G_;]K($O^YD?(_3'-Z+4B4M'=]3VJCM") 6O>(C< T.CU5:+&7L(W9]=M=
MAW)5_O>W7VS\!9/0*W74`O;,[,QG9F=FQ\='O\4<W2P1K!"GA-XT("0"S2(,
M;^'U[R]?P>M_OWH-KU_^YV7S^.CT]/P@EY8$YK\^E7P=,T*E: =QK.^9^Z_>
MO'D#GYC <!DQCL7F@?FORZA$A I 401R@4%(1$/$0\!*'K'R`'^+<2!Q"+,U
MN'X;.I%@$*2L1D[&3BB1!$7D;R0)H_ ,@@@CFL2*.L0P9QQ"3NXPAT9"FQ%#
MH0*JO5'GD+C\1F@0)6K1D][LQN<H'G(6B/;BY/A(__W<0IK_B;FNH -=&($'
MXY\7>E#50%T^_ 5#Z$-/_;L\E(9I_/1&SN?^:#KV.WX?B(!$V !A"8>N]OHD
MAGE"`Q,(DD&()>9+0C&L%DC"BO%;(X=(H!B'0M/,,(2,XC9TA FG-%@"MHPC
MQ2X4\7-1#;(5MG)HP/$24VF)A$12"0)G#H@"YIQQ8$&0< %AP@F]`:4$HFN0
M9&D%=--0#1G.]X-6$Q(:,LUA%<?/[ZR:H(B5TE+?-3NE;<$Y/I+K&(=X#I@F
MRQ)0QT??CX^T9\ROJ>,ZOM,9M&!S*3VN,; 5!<J 8Z'0#/2FS7D^=L87D\O+
M_JA5XM%**:59@/1&U4[ =QJ,63*?8UX1T.M_=KK]<:LJ0"%HV)'RUAT)E"*S
MKSB0%>Z!X_Y95;G,+=;+&8M(`!&AMT7N*T]9[(T<]T.9FV-8,':KF!6,S/H>
MSY*;&^5]@;G6Y?CH_NRP>_<##,"#"^BHSX/LC=*64)>)P3-CXQCC\HX)B0@2
M(70`HQF[PX<S[%(9-8)K9=8(>DH+O?F[RD3]NP,^..JY>QB#\3>).863[LGQ
MD>MKPR9*;L_L6E.0&M;YC@O#U'KOXE._ZX.E\4QXM7*BB>MTO5Y?861B9(1O
MB%!BAD@N-(DE;)X=)E5N0V=#\E)!- #MP;$"SC,9%$R.GQCX7/5[?,C%-SGU
MBMUA839OL,#X[[6-(%BB8*$3YV9O4 6\?699"8W4\W(`*H\HJK$F:C0W>0=.
M3Z=(+/6WB 6W.FMF@HP/J'*H?H!#)\NG#6@,!Y[[H?G,:F/AU]0<RT2YWX;Y
M\=%]J3[L:TO,\1UAB7C<GF%*6;5I;Y-Z^.=,4@K$B*=6I;7)5JV$ZF8&AVWP
M%T1 @*B^&Z HPB',.5OJ4K-:8&Y+#642OB9"&@`L+W"62*)K'W3H&N9(HLB6
M+0$K$D5&F*)7TF=XSE)!(B:<1+HVA6Q%5[IQTZ66L65:B^X8">'X**UMZ7;4
MUP/[,2?*,:YLS(22:T+_^-U%2SR6NIR>&3I+W/.'ZI9&^20KJA:*IT]/H%E 
M6ZR(#!;02&.C:>]^SQ4(D,!;I>-M_MPZ6'%'44_7B[&M%1\9NVW 96<P[IO5
M:L2E=:PB2_<U6+<:QC.Z>EGO&8?;DDB5R1ID9+\1:D@-&N:.B%&@O%B6.Y*1
M0XF<4*(;88M8`YYMP]B"GC>>VOH\=3M79?V-N<QJ.$YK[$ I62NJ@/.V[6D'
ML&W^):$*S+6RUL!0,)Q5@J.H3,^0-$IA].*=O6M_/:B-;6AJE.'8=%E:"\E1
M'&->;8JRZT*;W&,KZENZQL[UTJ:KLIJ-P/,R307Z&<?H-KUG,L.]30Z_I@S9
MRP4?H&\^1O 7P! \4X+\0Y>@S8J;=/<1T3!2B.MCFTX^SF@XO?HT[0Z\<=\2
M935?\?3\;L0$;N1EVA1]&\AIDHE[7JOP4,F#V.%QH;*;?)-E]>P3/NE4F1T"
MS';3K)3QI0[5,KD6^.*=PW212$3;?J1^G8RGXTFWVQ^/SS(U6#<5.\+_2["0
M#<W?`L>;NM[4<;NC_E7?]:%I&$HE8EO@?:%4%+%+<4NQZ'JN/_(&\&R#YZAO
MRIL].I0@[1$1(QDL#H&J2?J?/:>G(XS0.)$7YFBP\?LYN)-!%O(;2I;(+=(2
M9>_:&U5E#C"],1W;.;RLDA4%9G0YV<;\!RYA?5JZ-@YV/7_J7 T'QF_]7N;H
MH?*HHNC^.1UXW8[O>.X3#=)8HN!6,3OL`Y;=A'-,979[H,]2A%$3$ED`U$2G
MXK2-C#X"VH[ CD*4F:?6VO04!HB&]G0:&<-S4?9;C5?.8:/FBW=#Q-%2'Z-%
MVZ96';Y4<A:U_76,_W!R_A3.&N^=IUMD(C OT=;X;]_5G2IKS?*IS'U%>ENL
MJ<S:;>[0N<X&9AZ@@PEJ_)1M)I@A/:I0E$OTE7&8!]2,I[*:G;%DS4E!WRO-
M<)D.-9HI_7>HE)G2OGX+VW7F@814+C5YTJD*+R<3O<B32N>U@[#QK[!YTMK7
MK]FWKL*GN=6**%!S5!6>CM?U!U5[MU'<?\&RJ.^5WSDF>MWI1\_3[=R3+2 V
M3T^V3<@N,H?&[D[2'TWZNG&MY_U>?]NDL_P(MF/A^UVL]>2[PJ>>.FM8'L1M
MXCZ,G'W^C[%+N_!_`%[EO+<;P$-"M9\K0CQ'223?UM.?GL+[]W"MCWL0DM">
MV@*VQ/8P\?[]?@KO*&7[:'Z_(YODM^LM^$'-?U#CQY/VSFZ[D-#3>:&9P*Z(
M7(!SZ@&W[5L;8(0#IH_!]F6&5H_-;<^HR)#)W&UXN%>T?(7LJZL'H\\ES!@3
M$F).&"=R#:L%IFD_J ]<@M `6\PD8[<0$2DC;";,[9]O.'.M[M-&Q/[I3LUT
MBQ,S2-B<\1\>NF54NCF$NI.[E:;,JA[:LUE"29QY?E]4*WL=IDOK5.";QHD^
M5)TT?_VD...@N6...?34D.[:4%3P'<-0%Q9G7[L.R79!KL`1#8U>@$F
ME\)%0J+PJ4F_4-^ .MG[$ PW$9NA2%0:F1U'VX<$Z0U3?'50E&7VB*8M'K4W
MA>"IZV>IMF&IE>JP-=DISHA8$H5Z=Y%\_8C0Y)LY\X-8S\1:2+RLE*#=<9A1
ME#=.X=Q>7YH+*6;C(_U>R+S62-]);$U",F!V3WB*<=("A4[=="?'E=GUTHE*
M3<JOV1"EZV4+=A2E:Y,U%=")P/D['CW$I_I%1(VL+?UK:"Z=03^S27<*CNO_
MF%HNRU\[ISH%"\11(#$G0I) U*VJVXI6G3@S@77&YK7?MR!*A((KE5MG83$1
MU#RO!L?N&-\KQ(-J,/UT4#\:UJ5&IF;7C[',9FQAULS/:2"JI]/R;*]T%/IO
MZ<CS11\<\^'%V?[L>K+T!2R[&2?MSUL^YWQY7 /[RU8Y0VV_GM5BE.: RIM-
M,]W1KOPP<8IH/981]I[Y;F6%\M!W=^N<[=VME727_Z1N9S\B+"__>@/4Q/\/
MAW\)R5^7VHNA7\-W7].H*%/^#U!+`P04``(`" "]J,PJI9*/^M4&```I%0``
M!0`D`$E$5"Y("@`@```````!`!@```>[5&KSP $`"#QZN?+ `:"'8=:4,;\!
MK5C[;]K(%O[9D?(_G-656IS+$AYI;@M+*Q)(PM8+7.RTBG0E:X+'8=2)Q^L9
M0J(H__N=EVV@A&RC0"#VF?.=US>/@_?W#@^[;_)2ED!_D4C4YNI*WS4^??H$
M?S*.X8RR#/-B0'^=L@B#8'"+DD6ZH$A@&"8"9]DB%=#'?):15+ ,`G1-,0>6
MP/W'8T@S-L.<LXP7EO+/6R7S+Q(G$8XA'/:#\"*4`GE'$EP*S/M-R_?LZR_H
MP2E,80P^O*7/(BVG/_1[)]X@'(X"W_DZG/[7@S#L$T8CDOU-P[ #_]O?>RZ\
MKWB*",=#J5F!B^'Y1>@-O@V\*KQ;LP'N3BLAXK?.(Z0+/H\CYTG+7E:?4:+N
MC/KSVF6F@U&9J/.HK:0LC:/2RLY,/;;$F<YT+3>W8V;#IE<I&05PR3$',<<0
M,TK9DB0W<(?H0@ICE@$1[SFTFK]?$P$Q10(XIG@F[/1>84F:"D]]IU*__^BN
M"2^-M'&R+NYK:;.U+CW3TE;=-1'K&,\HNC'!#/N!"N)&!C$3A"5J>"4"-?O/
MO-YY>-$;];W!-)Q,!_Y@%#@RIGJ]#H<'0(H%/$=)1'$&:88Y3@0<'#YO9S0.
MK"E=N?I]_5ES<8;Q5EO]B1=*T.:KM"45H MU"=Y_!MW8@FZNH1L[T$W'D84X
M6M-O[M!O;?%VO(9N;4?WO.^]*[\>GO4\?Z!\YAE^^;*U,KE^,+W4ZHTU]6)M
M%/K!U600^E>^8F3Z;=!O6!>.Q"@RLSL<K3CZ&=C\>!SXOHZL86!2`E($Z X1
MJK;SG7BO'VAPTX IFR$*47D@B!<M2'\G_I4VTEJ/X'K!'UZ"GIX;_T<E5$9 
MX48=4;NP0<__:K$?#%8@_N-EG/0PM+CCTF<Y^?^)@< :^$]I0&0H?1F;T]Q4
MZ(\;-*,;1)*=\%9)]B<#;OT2V;G[EK+0>XW[G.F3=?<O,MTJF3XMH?^,Z3SJ
M(X7NOR;JG/!!Z?H7"&^5A)^5!M8(+_9W7V2+F= ;/)JIWDD=07J;OR;"'C/B
M(<6JY5DDA"7%U@&/^WO.]_&T#TMU2'3D'3?&'LMCTKD\O>A-83'S!9K].$T?
MVA^48B&>VK*T6YTMH$ Z;A]UU@_P8K1'E^B!U]N-;=!^2MO-;0,3<^1HE/,D
MOY[RA*IP,,FOI?S-NBEIR%&OU=T\@"N8P #Z\G,&_MNV;KHQ2#-T<XL@E66O
MZ-:I"I/I0!WB;LFH)6P4J.9U?R]GU%EZ;!SSCN,<'H+'EO"=91&P6'<J0W_Z
MGLN;F&-1Z/NV,>DHA-'(>Y5"1[<2QJ:^+ 8N2.'L@A2^UOVHMRJ<FH_F/P1S
MPF'.V \.2$]+&"0B>U"_&E)&$J$N$"1X:8W4I$,5G0"*T9WMNV:++%,=2)HQ
M8?H:&;@0)+F15K7*@X&A#->@%T5$Z2!*'ZI !&18+++$MG"J0S.NE&LI,DA&
M(Y5,WJ74)/M,.8$9NTTI%I@^Z"A70C# 6/=>"X[!QZ+BPC6F;%DKZR"U[AB)
MX$+6H *3;^-A7QF2Q:S:NW1,(WG;'5UZ'KA[SJ/CJ-6WVM,K*PZ)H9(KPV]=
MR/4=YZ RZ2N6W'RTZU0,87_\T3AVX=]@Y@IT]J2ZN7:<+BA,Q03CRC''LEP,
M52K&K%7Y_%D9TZVRL]J(JS7Z:]2CS;+JC3/?-XOJP65"R0]LIWZ[K6OH5B5K
MTC*^3RF9$2$M2)X,NPK]GA?PDJPJ7#,Q!\E]K@84WV$*[X#<%G:61.KH*6$-
MS-0/W'R-0(HXQ]$6;A7SEDRF>-4;;@ZSMWJ>5&TJ<*"8&D9"D^Z"MOBXR?J^
MI=VP+K5+UM7D<S3 L6._?[8<2_+LSK QG"]_I5!L!1LZYI>$TC ;P<9P,3WL
M=J"&GTR8&[.*Z2FE!U;\\E6WN3,ICPMGS\Q 5DR_'?//L<5E*<Z0]-*MY-7.
M0A()5VH\4^,R>*V9U_*G^/-1_^<\5L&F=K">3SZ85^ZG))3 ;%5PH&9XY\6\
M?C&MVJZL:CN3JNW(J?:*E,P!FV\69KOHG;=A^/X6%@F?LPR#F.OE2CC(OSM$
M201Z0:ZBI;V3\=B#(?^F%"JNU$BXR$MB?5? ;H<NO'LGK_-,NUW]D]P%MPCL
MR:Y0U6>8J\[F,<W2U5/Z=8^15AXV#.$OF( '`_E_`",(H"<_0QC+Z]>9+AN+
M)<H2DMQ4(")<]_%M.*JW/H"K3JY E8;%,23,'I'FL4:.6GG <([50PZU=>I]
M_!IQK+O1C</9/-8S*))0U??:(CIA&",N=&LNC4G)B;11<74[HY\'J4<Y\ AP
MR^X`H_LJA)/3*7R57S7E$IX<24Y._;8,<8P65!09V@X+)Q&)]_X/4$L#!!0`
M`@`(`,!K"2&BWX6_X@````L!```(`"0`34%+149)3$4*`" ```````$`& ``
MA,&WW86[`0`(/'JY\L !0 YCUI0QOP%3YN525G#Q5_#S#U%P=?$,40CQ\ Q6
M<//T<5545%10<$W)+%'0BRG.+RU*3BW64\A,4ZC,+U4H3\PK42C)5TA,25%(
M5,A++5> J `9EI:9DPJ2*\G(+%9(SL\MR,]+S2O14U (`0F 97-3BU)S*A4R
M\U(RBU*32XHARE,5BE(3<Q1R$[-3P<I AI5D))8H`+459R06I:8H)%4J).;D
M@-6F%&66I18A+"A6R$\#2X0#C<TO+U;P"U%P<?$&&L++Q<NEZ.GG[!/JXJJ@
MHN$7XNOH[>KJ%Z89`[(*9)->2FH:+Q<`4$L#!!0``@`(`*.2R2H_+&B_#P$`
M`%X!```'`"0`4T]54D-%4PH`( ```````0`8``!=9LWW\, !``@\>KGRP ' 
M\US6E#&_`46046O",!2%GRWT/_3!!WVH,C;&$/H0<Z\:S-*2I)5!(6BM4N;:
MH*W@OU^JCCTEW.^<W'.BB5RB%N03(]@=]7EK?>\Q2XA>17'7VJ[]&^FOQ,DD
MRU#ZGN\Q07D*J*+A:$X4`I/CO*J+'JDXE=01K-OSS395W5XFA;5![GL#*'?=
M497G:U64JZ;YOI/!H+?Y'C6 "R:<-814,!H#!B$H+1G5[@*QT:AT<%__^O%N
M-D0*)I:&8X8\FF[>>L*96*,T"TZ6[IV?K9T-1_^EQOEP1).T/P#6\Y1Q0)&-
M\V?_B=,'O:FJ#\WL5-7E)0CW?>;V9LM9<0VF=;,O#]ONU)ZJW2/V,_P*Z1K!
M$*Z-^XWHY1=02P$"&0`4``(`" #5B\DJD^"*=8\!```_! ``#P``````````
M`" `````````1&)G5')A<$-O;6UO;BYH4$L!`AD`% `"``@`F(;)*F@2H&RG
M````70$```P````````````@````X $``$1B9U1R87!$8F<N:%!+`0(9`!0`
M`@`(`&:.R2I,B@T7S@$``(,%```.````````````( ```-4"``!$8F=4<F%P
M4')O8W,N:%!+`0(9`!0``@`(`"6GS"HRW:R!.@<``#@2```5````````````
M( ```/,$``!$96)U9U-E<G9I8V5(;V]K<RYC<'!02P$"&0`4``(`" `AJ<PJ
MMYNE,KX)``#.(P``#P```````````" ```"$# ``96YT<GEP;VEN=',N8W!P
M4$L!`AD`% `"``@`O:C,*J62C_K5!@``*14```4````````````@````DQ8`
M`$E$5"Y(4$L!`AD`% `"``@`P&L)(:+?A;_B````"P$```@````````````@
M````KQT``$U!2T5&24Q%4$L!`AD`% `"``@`HY+)*C\L:+\/`0``7@$```<`
M```````````@````VQX``%-/55)#15-02P4&``````@`" #1`0``,R `````
`
end

Re: [line-devel] RE: Interrupt vector

[Erik P. <epa...@cs...>]

On Mon, Jun 11, 2001 at 03:43:02PM -0400, Michael Vines wrote:
> On Mon, 11 Jun 2001, Michael Stout wrote:
> 
> > P.S.  I have seen threads about the intrinsic differences between
> > linux/posix
> > mmap and NT memory management.  does it just have to do with the allocation
> > granularity?
> 
> Yes, allocation granularity is the main problem.  Linux can mmap on a page
> granularity, but all the Win32 implementations that I know of can only do
> 64K.
> 
> A couple months ago Erik Paulson mentioned that the native NT api function
> ZwMapViewOfSection() may be able to allocate at a page granluarity.  He
> mentioned that he'd try to take a look at it, but I guess he didn't have
> the time.
> 

Sorry; I will get around to it (though if someone beats me to it I certainly
won't be offended :)

-Erik

RE: [line-devel] RE: Interrupt vector

[Michael V. <mi...@bl...>]

On Mon, 11 Jun 2001, Michael Stout wrote:

> P.S.  I have seen threads about the intrinsic differences between
> linux/posix
> mmap and NT memory management.  does it just have to do with the allocation
> granularity?

Yes, allocation granularity is the main problem.  Linux can mmap on a page
granularity, but all the Win32 implementations that I know of can only do
64K.

A couple months ago Erik Paulson mentioned that the native NT api function
ZwMapViewOfSection() may be able to allocate at a page granluarity.  He
mentioned that he'd try to take a look at it, but I guess he didn't have
the time.

http://www.geocrawler.com/archives/3/10551/2001/4/0/5575403/


Mike

RE: [line-devel] RE: Interrupt vector

[Michael S. <ms...@ac...>]

[...]
>> The 3 major
>> reasons
>> I dont really work on line is that
>> 1) I get really frustrated using GDB/emacs under cygwin.
>> 2) I really dont know enough about linux
>What is the third ??

Oops
	I really dont have the time


>> 1) make interrupt 80 reflect through an LPC port to a ring 3 process
>> 2) implement the linux APIs in the ring3 process
>> 3) move that implementation to the ring 0 interrupt handler.

>Hmm...Michael. Can I ask you to spend a few time and make everything for
me?

>You propose to create something like Win32 sybsystem does in NT3.51 ?
>I.e. create native NT app which will create new native NT thread for each
>Linux
>process and make fast context swaps using int 80/8x ?
>What does 3) mean ? Are syscalls will be processed in ring3 or ring0
>(i.e. are Win32 API will be called in ring0 (????) or ring3 or no Win32
will
>be used) ?

Not exactly.
step 2)
	a) when an int 80 gets called, the interrupt handler makes a call to an LPC
port.
	b) that gets handled by a single threaded process running in ring 3. This
process
	will use the Native API to implement the syscall.  The process context swap
gets
	handled by the LPC port.
in step 3)
	remove the LPC call and move the code that handles the syscall into the
device driver.

In step 2, syscalls are processed in ring 3, in step 3 syscalls are
processed in ring 0.

in step 3 there is no process context swap.

an implementation that stops at step 2 will be slow, but relatively easally
developed.

it's been a while, but i checked in come code in
<lineroot>/un/hookint/hookint.c that
uses LPC to pass the interupt registers up to ring 3 and back out again.

At the point that I stopped developing,  I also had code that basically
created a native
process and emptied all the mapped dlls that I could from it.  the next step
would
have been to look at the linux current_process structure (I think thats what
it is)
and build an equivilent to map into that process space (or ring 0 space).
Then create an executable memory segment in that process space that does an
exec of bash.

much easier said than done.

>Do you propose create own sybsystem and call NT microkernel directly or
>we will create Win32 service which will only extend Win32 sybsystem API
>(preffered for fast development speed, but not for fast execution) ??

eventually it would get rid of win32 entirely. build the service under win32
so
you can use the debugger, but implement the syscalls using the native api.
I'm not sure about your definition of microkernel.  If it means
"anything that runs under ring 0" then yes.  if it means "only the HAL" then
no.


>Sorry for a lame questions, there is a lot of ways to implement that we
need
>and
>it's not clear from your e-mail how you propose to do this.

They're not lame questions,  It's lame of me to pontificate on how to do
things without a) knowing much about linux and b) having much intention
of actually doing it.
	Mike

P.S.  I have seen threads about the intrinsic differences between
linux/posix
mmap and NT memory management.  does it just have to do with the allocation
granularity?

=============================
Andrew G. Tereschenko
Software Engineer
Integrated Banking Information Systems
ta...@ib...



_______________________________________________
line-devel mailing list
lin...@li...
http://lists.sourceforge.net/lists/listinfo/line-devel

RE: [line-devel] RE: Interrupt vector

[Michael V. <mi...@bl...>]

On Sat, 9 Jun 2001, Andrew G. Tereschenko wrote:

>
> > > No I am not sure the interrupt vector will work under SMP.  It
> > looks like
> > > your code is much better.
> >
> > I come to agreement with Vines to replace current code. I'll do it in near
> > future.
>
> Attached is a draft (not yet fully cleaned) new interrupt installation code.
>
> It need to cleaned a few and moved to CVS tree if everybody agree.
>
> I have some problems to determine thich function make in pageable area
>  - so only one (actual int handler) are pageable.
>
> Can somebody build and test on W2K and NT ?


Hi Andrew,

I tried building it on my W2K machine this morning, I had to make a small
change to the source before it would compile:

--------
diff -r int80.new/src/DebugServiceHooks.cpp int80.andrew/src/DebugServiceHooks.cpp
137c137
<     for ( char cpu=0; cpu < *KeNumberProcessors; ++cpu )
---
>     for ( char cpu=0; cpu<KeNumberProcessors; ++cpu )
160c160
<     KeSetAffinityThread( pThread, (1<<*KeNumberProcessors)-1 );
---
>     KeSetAffinityThread( pThread, (1<<KeNumberProcessors)-1 );
--------


Then I had a little trouble enabling the driver.  I tracked it down to the
IOCTL parameters.  The original driver used METHOD_BUFFERED, but your
driver uses METHOD_NEITHER.  I'm not sure what the difference is though,
but the 80.exe test program works fine when I recompile it using
METHOD_NEITHER.

---------
$ diff src/int80/int80.h.org src/int80/int80.h -u
--- src/int80/int80.h.org Mon Jun 11 11:50:40 2001
+++ src/int80/int80.h     Mon Jun 11 11:47:40 2001
@@ -14,11 +14,11 @@
                                                FILE_ANY_ACCESS)
 #define IOCTL_ADDINT_SYSTEM_SERVICE_USAGE
CTL_CODE(FILE_DEVICE_HOOKINT,  \
                                                ADDINT_IOCTL_INDEX,  \
-                                               METHOD_BUFFERED,       \
+                                               METHOD_NEITHER,       \
                                                FILE_ANY_ACCESS)
 #define IOCTL_REMOVEINT_SYSTEM_SERVICE_USAGE
CTL_CODE(FILE_DEVICE_HOOKINT, \
                                                REMOVEINT_IOCTL_INDEX,  \
-                                               METHOD_BUFFER,       \
+                                               METHOD_NEITHER,       \
                                                FILE_ANY_ACCESS)
 #define IOCTL_CALLPORT_SYSTEM_SERVICE_USAGE     CTL_CODE(FILE_DEVICE_HOOKINT,\
                                                CALLPORT_IOCTL_INDEX,  \
---------

LINE seems to run normally with the new driver.  However, when I remove
the driver then try to run LINE again I get a BSOD.  I guess it isn't
cleaning up after itself properly.

Here's a little more information that might help:
0) Reboot machine
1) Run LINE (without the driver loaded)
2) Load the driver using 'install.bat'
3) Unload the driver using 'remove.bat'
4) Run LINE.

This works fine.

But:
0) Reboot machine
1) Run LINE (without the driver loaded)
2) Load the driver using 'install.bat'
3) Run LINE using driver
3) Unload the driver using 'remove.bat'
4) Run LINE.

and I get a BSOD everytime. (DRIVER_IRQL_NOT_LESS_OR_EQUAL)


I also noticed that on the top of all the driver source files, there is
the copyright notice '1999 Jose Flores' but there is no indication of what
license (if any) the source has been released under?


Mike