Menu
▾
▴
reactos-kernel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(64) |
Oct
(438) |
Nov
(183) |
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(132) |
May
(466) |
Jun
(366) |
Jul
(392) |
Aug
(31) |
Sep
(18) |
Oct
|
Nov
|
Dec
|
|
From: Phillip S. <ps...@cf...> - 2001-09-30 14:51:46
|
I'm not sure, but I think that sometimes the directory data is cached, such as when opening files or changing directories, it does not seem to read the disk, but when doing a simple dir command, there is intense disk IO and each file in the directory is printed one at a time, very slowly, as if it were still reading in a sector from the disk for each file found in the directory. At 11:52 AM 9/30/2001 +0100, you wrote: >On Sat, Sep 29, 2001 at 09:54:15PM -0700, Rex Jolliff wrote: > > > > I thought I was done with this. Perhaps I missed something, or subsequent > > changes > > altered the behaviour of the caching code. I am not currently working on > > this. I seem > > to remember that someone else picked up the vfat driver. Perhaps this > > person will > > look into this. If not, I can take a look. > > >The vfat directory read code uses the interfaces for reading file data so >it does go through the cache but it doesn't operate directly on the cached >data so it is less efficent. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: David W. <we...@cw...> - 2001-09-30 10:53:07
|
On Sat, Sep 29, 2001 at 09:54:15PM -0700, Rex Jolliff wrote: > > I thought I was done with this. Perhaps I missed something, or subsequent > changes > altered the behaviour of the caching code. I am not currently working on > this. I seem > to remember that someone else picked up the vfat driver. Perhaps this > person will > look into this. If not, I can take a look. > The vfat directory read code uses the interfaces for reading file data so it does go through the cache but it doesn't operate directly on the cached data so it is less efficent. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Rex J. <re...@lv...> - 2001-09-30 04:53:49
|
At 03:28 PM 9/29/01 -0400, you wrote: >Hey Rex, didn't you say a while back that you fixed the vfat code to cache >directory data? It seems that it is still reading in the sector of >directory data over and over, once for each file in the directory when you >do a 'dir' at the command prompt. Are you still working on this? I thought I was done with this. Perhaps I missed something, or subsequent changes altered the behaviour of the caching code. I am not currently working on this. I seem to remember that someone else picked up the vfat driver. Perhaps this person will look into this. If not, I can take a look. Rex Jolliff re...@lv... ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: waltert3 <wal...@to...> - 2001-09-29 23:16:37
|
Dear James: Actually Mingw is a minimal port of GCC the Linux compiler and most if not all are limited ports from Linux. In short the answer to your question is Yes. However, to be more specific, Mingw and more is already part of the Linux system. Mingw is just a subset of what's available in Linux to Windows in hopes of inspiring opensource development in the Win32 community. I hope that this answers your question. Walter. ----- Original Message ----- From: "jimtabor" <jim...@ad...> To: <ros...@re...> Sent: Saturday, September 29, 2001 8:04 AM Subject: [ros-kernel] Linux Tools > Hi, > Is there any mingw tools for Linux already compiles? If so where can I DL > them? > Thanks, > James > > > ==================================================== > = To remove yourself from this mailing list, go to = > = http://www.reactos.com/home/mailing.html = > ==================================================== > ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-09-29 19:32:45
|
Hey Rex, didn't you say a while back that you fixed the vfat code to cache directory data? It seems that it is still reading in the sector of directory data over and over, once for each file in the directory when you do a 'dir' at the command prompt. Are you still working on this? ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-09-29 18:41:57
|
Does mingw have something like VC's editbin utility? Something that will bind imports and/or change the subsystem of an image? ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Casper H. <ch...@us...> - 2001-09-29 12:32:53
|
On Saturday 29 September 2001 14:04, jimtabor wrote: > Hi, > Is there any mingw tools for Linux already compiles? If so where can I DL > them? > Thanks, > James None that will compile ReactOS. - Casper ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: jimtabor <jim...@ad...> - 2001-09-29 12:06:19
|
Hi, Is there any mingw tools for Linux already compiles? If so where can I DL them? Thanks, James ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Aliberti E. <ea...@io...> - 2001-09-28 08:35:06
|
> >Subject: [ros-kernel] Re: Ext2 under ROS > From: "Andrey Shedel" <an...@cr...> > Date: Fri, 28 Sep 2001 10:47:08 +0400 > To: <ros...@re...> > >> What is the current status of Ext2 under ROS? I found this site with a OSS >> driver and e2fstools for NT. > >This driver is not OSS. > This one WILL be released under GPL: http://uranus.it.swin.edu.au/~jn/linux/ext2ifs.htm I contacted Mr. John Newbigin and forwarded the reply to David, that wrote our EXT2 driver. I don't know what happened later. Probably they are simply busy at the moment (just like me). ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Andrey S. <an...@cr...> - 2001-09-28 06:42:50
|
> What is the current status of Ext2 under ROS? I found this site with a OSS > driver and e2fstools for NT. This driver is not OSS. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Steven E. <Ste...@kn...> - 2001-09-28 06:04:13
|
What is the current status of Ext2 under ROS? I found this site with a OSS driver and e2fstools for NT. http://tarzan.cr.cyco.com/~andreys/ext2fsnt/ There is also some other cool utils on here that are free. |
|
From: Mark W. <ma...@np...> - 2001-09-27 02:39:30
|
Hi, I would like to contribute my fiber implementation code to reactos. My questions is: (1) Fiber code is platform specific as it relies on manipulating register context - where should I put this? At present I have an x86 version. Stubs for the fiber functions are in lib\kernel32\thread\fiber.c, what is standard way of implementing platform specific code in reactos? (2) Currently my version compiles under VC using the __asm extension. Should I submit this code as NASM/GAS? I would prefer NASM, but I can do GAS. In the latter case, is .S OK? (3) As a final, possibly unrelated point, I discovered recently that mingw generates COFF that is not compatible with VC's idea of COFF. Specifically, the BSS data segment length is not generated in the right place (the only COFF definition I have found is the one used with djgpp (http://www.delorie.com/djgpp/doc/coff/) - this corresponds to the MS definition as far as their linker is concerned.) Would this be a problem for reactos (presuambly not if GNU ld understands the same format), and is this a known "problem"? I got quite a shock when compiling some old .S files with mingw and linking them with some VC generated code (the code appears OK at first but you get really weird crashes as the BSS segment in the final output is not the right size - eventually I found that my code was being overwritten, and why!). Thanks, Mark ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: David W. <we...@cw...> - 2001-09-27 02:17:31
|
On Tue, Sep 25, 2001 at 06:53:08PM -0700, Jack (Butch) Griffin wrote: > Included below is a patch (I think) for a problem I mentioned earlier. > Basically the behavior between Windows 2000 and ReactosOS was different in > the case of a call to VirtualAlloc with a NULL base address and MEM_COMMIT. > The patch below adds a simple test case to vmtest.c and update > NtAllocateVirtualMemory() to handle this case by calling itself recursively > first with MEM_RESERVE to reserve the address space, and then with > MEM_COMMIT to commit the memory. > I think it would be easier to fix this by adding in the MEM_RESERVE flag if it is missing. I've committed the change; let me know if this works or not. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Jack \(Butch\) G. <bu...@qw...> - 2001-09-26 02:06:15
|
I have been playing with a "HelloWorld" console application compiled under visual C++ and under Windows 2000 and trying to get this to run under reactos. I can do this with no problem if I avoid the Microsoft CRT startup code by telling the linker to start directly with main. However if I let the Microsoft CRT startup code initialize things it causes a page fault. The problem turns out to be that the WideCharToMultiByte() function is not implemented and therefore returns an error. There is an error in the microsoft CRT code that causes a NULL pointer to get accessed when this happens. I looked at the resource for WideCharToMultiByte() and found it in two places. First it is in the kernel32\misc\stubs.c. This version is the one that is linked into kernel32.dll and it returns an error indicating it is not implented. The second version is in kernel32\nls\wctomb. My question is what is the status of the second version. I seems as though the code pages are compiled into the kernel, rather than loaded from the *.nls files. Is someone working on this? Thanks Jack (Butch) Griffin ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Jack \(Butch\) G. <bu...@qw...> - 2001-09-26 01:54:18
|
Included below is a patch (I think) for a problem I mentioned earlier.
Basically the behavior between Windows 2000 and ReactosOS was different in
the case of a call to VirtualAlloc with a NULL base address and MEM_COMMIT.
The patch below adds a simple test case to vmtest.c and update
NtAllocateVirtualMemory() to handle this case by calling itself recursively
first with MEM_RESERVE to reserve the address space, and then with
MEM_COMMIT to commit the memory.
Thanks
Jack (Butch) Griffin
diff -Naur reactos.orig/apps/vmtest/vmtest.c reactos/apps/vmtest/vmtest.c
--- reactos.orig/apps/vmtest/vmtest.c Tue Sep 25 16:08:53 2001
+++ reactos/apps/vmtest/vmtest.c Tue Sep 25 18:48:44 2001
@@ -5,7 +5,14 @@
{
PVOID Base;
PVOID Ret;
-
+
+ Base = VirtualAlloc(NULL,
+ 4096 * 64,
+ MEM_COMMIT,
+ PAGE_READWRITE) ;
+ if (Base == NULL)
+ printf("VirtualAlloc failed 0\n") ;
+
Base = VirtualAlloc(NULL,
1048576,
MEM_RESERVE,
diff -Naur reactos.orig/ntoskrnl/mm/virtual.c reactos/ntoskrnl/mm/virtual.c
--- reactos.orig/ntoskrnl/mm/virtual.c Tue Sep 25 16:09:18 2001
+++ reactos/ntoskrnl/mm/virtual.c Tue Sep 25 18:48:46 2001
@@ -887,10 +887,30 @@
{
return(STATUS_INVALID_PARAMETER);
}
+
if (((AllocationType & (MEM_COMMIT | MEM_RESERVE)) == MEM_COMMIT) &&
(*UBaseAddress == 0))
{
- return(STATUS_INVALID_PARAMETER);
+ DbgPrint("In my routine\n") ;
+ Status = NtAllocateVirtualMemory(ProcessHandle,
+ UBaseAddress,
+ ZeroBits,
+ URegionSize,
+ MEM_RESERVE,
+ Protect) ;
+ if (!NT_SUCCESS(Status))
+ return Status ;
+
+ Status = NtAllocateVirtualMemory(ProcessHandle,
+ UBaseAddress,
+ ZeroBits,
+ URegionSize,
+ MEM_COMMIT,
+ Protect) ;
+ if (!NT_SUCCESS(Status))
+ return Status ;
+
+ return STATUS_SUCCESS ;
}
PBaseAddress = *UBaseAddress;
====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html =
====================================================
|
|
From: Mark W. <ma...@np...> - 2001-09-26 00:34:29
|
you are right, please ignore my ramblings!
> -----Original Message-----
> From: Robert Collins [mailto:rob...@it...]
> Sent: 26 September 2001 01:27
> To: ros...@re...
> Subject: [ros-kernel] Re: ROS ExitThread behaviour different from NT
>
>
> On Wed, 2001-09-26 at 10:09, Mark Weaver wrote:
> > >From reading the ReactOS code for ExitThread
> (lib\kernel32\thread\thread.c),
> > ExitThread will terminate the process if the thread to exit is the last
> > thread in the process. AFAIK NT will terminate the process if the first
> > thread created exits, i.e.
> My understanding is that all threads have to exit, or ExitProcess() has
> to be called. (this is based on cygwin, where we have to emulate
> pthreads behaviour - and it works fine).
>
> Possibly your linker is called ExitProcess not ExitThread when you
> return(). Try this:
>
> DWORD CALLBACK ThreadProc(LPVOID)
> {
> while (1) {
> Sleep(1000);
> }
> return 0;
> }
>
> int main()
> {
> DWORD dwThread;
> if (!CreateThread(NULL,0,ThreadProc,NULL,0,&dwThread))
> printf("No thread: %d\n",GetLastError());
> sleep(1);
> ExitThread(NULL);
> }
>
> Rob
>
> ====================================================
> = To remove yourself from this mailing list, go to =
> = http://www.reactos.com/home/mailing.html =
> ====================================================
>
>
====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html =
====================================================
|
|
From: Robert C. <rob...@it...> - 2001-09-26 00:28:16
|
On Wed, 2001-09-26 at 10:09, Mark Weaver wrote:
> >From reading the ReactOS code for ExitThread (lib\kernel32\thread\thread.c),
> ExitThread will terminate the process if the thread to exit is the last
> thread in the process. AFAIK NT will terminate the process if the first
> thread created exits, i.e.
My understanding is that all threads have to exit, or ExitProcess() has
to be called. (this is based on cygwin, where we have to emulate
pthreads behaviour - and it works fine).
Possibly your linker is called ExitProcess not ExitThread when you
return(). Try this:
DWORD CALLBACK ThreadProc(LPVOID)
{
while (1) {
Sleep(1000);
}
return 0;
}
int main()
{
DWORD dwThread;
if (!CreateThread(NULL,0,ThreadProc,NULL,0,&dwThread))
printf("No thread: %d\n",GetLastError());
sleep(1);
ExitThread(NULL);
}
Rob
====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html =
====================================================
|
|
From: Mark W. <ma...@np...> - 2001-09-26 00:13:29
|
>From reading the ReactOS code for ExitThread (lib\kernel32\thread\thread.c),
ExitThread will terminate the process if the thread to exit is the last
thread in the process. AFAIK NT will terminate the process if the first
thread created exits, i.e.
DWORD CALLBACK ThreadProc(LPVOID)
{
while (1) {
Sleep(1000);
}
return 0;
}
int main()
{
DWORD dwThread;
if (!CreateThread(NULL,0,ThreadProc,NULL,0,&dwThread))
printf("No thread: %d\n",GetLastError());
return 0;
}
will just quit. Watching this in the debugger, the spawned thread
terminates with status 0xC000004B (STATUS_THREAD_IS_TERMINATING). I'm not
sure how NT handles this itself, but one way would be to set Spare2 in the
PEB to the ID of the first thread created, check for this in ExitThread()
and call ExitProcess if this is the case. Does this sound sane? Would it
produce the same behaviour (terminate other running threads and clean
shutdown for the main thread?). I'll submit a patch if so, if not, please
advise of a better/more NT friendly method.
Thanks,
Mark
====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html =
====================================================
|
|
From: David W. <we...@cw...> - 2001-09-25 21:15:05
|
On Tue, Sep 25, 2001 at 11:05:43PM +0200, Guido de Jong wrote: > > Agreed. Although there is a little tool that is designed for "reading the new > and old versions together and trying to figure out what changed"... ;-) > Which is alright if you have the old file and the new file; not so good if you have the old file and a copy of the changed function. > It raises an interesting question btw: are you going to reject patches / > bugfixes just because they were not supplied in the preferred format? IMHO > that would only hurt the project. Why not file the patch on SF and have the > next person that comes asking for something to work on look at it and convert > it into a proper patch? > Not at all; I applied the fix provided but I don't see any harm in telling people what would be easiest for us and for them. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Guido de J. <gui...@ch...> - 2001-09-25 21:04:15
|
On Tuesday 25 September 2001 21:43, David Welch wrote: > No, but for changes even slightly more complicated a diff is much easier > than reading the new and old versions together and trying to figure out > what changed. Agreed. Although there is a little tool that is designed for "reading the new and old versions together and trying to figure out what changed"... ;-) It raises an interesting question btw: are you going to reject patches / bugfixes just because they were not supplied in the preferred format? IMHO that would only hurt the project. Why not file the patch on SF and have the next person that comes asking for something to work on look at it and convert it into a proper patch? - Guido ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Mark W. <ma...@np...> - 2001-09-25 20:21:09
|
Hi, Here's my understanding of stacks in NT/ReactOS: (1) Reserve a lump of memory for the stack (2) Commit 2 pages; one stack page and one guard page (3) Change the protection on the guard page so that it is a guard page When the guard page is touched, NT commits a new page to act as the guard page. As far as the fault handler seems to be concerned it wants to know: StackBase StackLimit *AND* DeallocationStack the DeallocationStack is used for freeing the stack/checking whether you can actually commit more pages. If the stack would grow beyond its reserve size then we raise a stack fault, and let the app handle it or barf. Of these items, we have the first two stored in the NT_TIB structure and the final one stored in the _TEB structure (which seems odd - any ideas why?). My question is - where is the fault handler in ReactOS that commits the extra page? Sorry to ask, but I've had a dig around for likely looking code (references to TEB, StackBase, DeallocationStack) and I can't seem to find it! Plus, am I correct in that the above information is all that the stack fault handling code is interested in? Thanks, Mark ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Mark W. <ma...@np...> - 2001-09-25 19:57:32
|
If you have a diff, you can just run patch. No need to find the line as patch can cope (to a certain extent) with lines shifting about, which may have changed if the developer's version of the file is different from the patch submitters. It's also easier for the submitter as they can be sure that they haven't missed a change, plus they don't have to go and find line numbers themselves. I don't think that anyone is going to reject a submission made in this way, but it's worht pointing out that for the future this is a better way to submit patches. For generating diffs, I use the GNU diff program included with cygwin (www.cygwin.com). Cheers, Mark > -----Original Message----- > From: Guido de Jong [mailto:gui...@ch...] > Sent: 25 September 2001 20:38 > To: ros...@re... > Subject: [ros-kernel] Re: Kernel Bug > > > Now I don't too much about ReactOS programming, but IMHO Jack was > quite plain > about it: > > There is this function called MiReadPage() which you can find in > mm/section.c, lines 252-337. This function does a call to IOReadPage() in > line 290, if the page in cache is not up-to-date. According to > Jack it is not > an error if this function returns STATUS_END_OF_FILE, which > apparently is not > equal to NT_SUCCESS(). So he added > > && Status != STATUS_END_OF_FILE > > to line 295. IMHO it will have been even better if you add > > && (Status != STATUS_END_OF_FILE) > > in stead. Do you really need a diff for this? > > See added line numbers below. > > - Guido > > > On Tuesday 25 September 2001 20:27, Jason Filby wrote: > > Has anyone tested/updated the tree with this update and the latest > > one from Jack? > > > > Jack: it seems that most developers prefer that you send them the > > "diffs".. but I don't think I have diff installed?.. > > > > - Jason > > > > --- "Jack (Butch) Griffin" <bu...@qw...> wrote: > > > I have been playing with the ReactOS operating system and trying to > > > get a > > > console mode app written in vistual C++ to run. The app is your > > > basic hello > > > world application. I did not really expect that the complete > > > infra-structure was in place for this to run, but I figured it > > > would point > > > out what was missing and give me a starting point for beginning to > > > learn > > > about the design of this OS. > > > > > > Anyway I have found a problem and do not know who should get the > > > updated > > > code. The problem is in MiReadPage() and the updated code is > > > below. The > > > only change is that STATUS_END_OF_FILE is a legimate return from > > > IoPageRead(). It does not mean an error occurred, just that the > > > file did > > > not contain enough data to fill the page. Function that call > > > MiReadPage() > > > assume that the data read are OK if the return value is > > > STATUS_END_OF_FILE, > > > so the update of the Page pointer must be done in this case. > > > > > > Thanks > > > Jack Griffin > > 252: NTSTATUS > MiReadPage(PMEMORY_AREA MemoryArea, > PLARGE_INTEGER Offset, > PVOID* Page) > { > IO_STATUS_BLOCK IoStatus; > PFILE_OBJECT FileObject; > PMDL Mdl; > NTSTATUS Status; > PREACTOS_COMMON_FCB_HEADER Fcb; > > FileObject = MemoryArea->Data.SectionData.Section->FileObject; > Fcb = (PREACTOS_COMMON_FCB_HEADER)FileObject->FsContext; > > if (FileObject->Flags & FO_DIRECT_CACHE_PAGING_READ && > (Offset->QuadPart % PAGESIZE) == 0) > { > ULONG BaseOffset; > PVOID BaseAddress; > BOOLEAN UptoDate; > PCACHE_SEGMENT CacheSeg; > LARGE_INTEGER SegOffset; > PHYSICAL_ADDRESS Addr; > Status = CcRosGetCacheSegment(Fcb->Bcb, > (ULONG)Offset->QuadPart, > &BaseOffset, > &BaseAddress, > &UptoDate, > &CacheSeg); > if (!NT_SUCCESS(Status)) > { > return(Status); > } > if (!UptoDate) > { > Mdl = MmCreateMdl(NULL, BaseAddress, Fcb->Bcb->CacheSegmentSize); > MmBuildMdlForNonPagedPool(Mdl); > SegOffset.QuadPart = BaseOffset; > 290: Status = IoPageRead(FileObject, > Mdl, > &SegOffset, > &IoStatus, > TRUE); > 295: if (!NT_SUCCESS(Status) && Status != STATUS_END_OF_FILE) > { > CcRosReleaseCacheSegment(Fcb->Bcb, CacheSeg, FALSE); > return(Status); > } > } > Addr = MmGetPhysicalAddress(BaseAddress + > Offset->QuadPart - BaseOffset); > (*Page) = (PVOID)(ULONG)Addr.QuadPart; > MmReferencePage((*Page)); > > CcRosReleaseCacheSegment(Fcb->Bcb, CacheSeg, TRUE); > return(STATUS_SUCCESS); > } > else > { > /* > * Allocate a page, this is rather complicated by the possibility > * we might have to move other things out of memory > */ > (*Page) = MmAllocPage(0); > while ((*Page) == NULL) > { > MmWaitForFreePages(); > (*Page) = MmAllocPage(0); > } > > /* > * Create an mdl to hold the page we are going to read data into. > */ > Mdl = MmCreateMdl(NULL, NULL, PAGESIZE); > MmBuildMdlFromPages(Mdl, (PULONG)Page); > /* > * Call the FSD to read the page > */ > Status = IoPageRead(FileObject, > Mdl, > Offset, > &IoStatus, > FALSE); > return(Status); > } > 337: } > > ==================================================== > = To remove yourself from this mailing list, go to = > = http://www.reactos.com/home/mailing.html = > ==================================================== > > ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: David W. <we...@cw...> - 2001-09-25 19:45:34
|
On Tue, Sep 25, 2001 at 09:37:57PM +0200, Guido de Jong wrote: > Now I don't too much about ReactOS programming, but IMHO Jack was quite plain > about it: > > There is this function called MiReadPage() which you can find in > mm/section.c, lines 252-337. This function does a call to IOReadPage() in > line 290, if the page in cache is not up-to-date. According to Jack it is not > an error if this function returns STATUS_END_OF_FILE, which apparently is not > equal to NT_SUCCESS(). So he added > > && Status != STATUS_END_OF_FILE > > to line 295. IMHO it will have been even better if you add > > && (Status != STATUS_END_OF_FILE) > > in stead. Do you really need a diff for this? > No, but for changes even slightly more complicated a diff is much easier than reading the new and old versions together and trying to figure out what changed. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Guido de J. <gui...@ch...> - 2001-09-25 19:38:31
|
Now I don't too much about ReactOS programming, but IMHO Jack was quite plain
about it:
There is this function called MiReadPage() which you can find in
mm/section.c, lines 252-337. This function does a call to IOReadPage() in
line 290, if the page in cache is not up-to-date. According to Jack it is not
an error if this function returns STATUS_END_OF_FILE, which apparently is not
equal to NT_SUCCESS(). So he added
&& Status != STATUS_END_OF_FILE
to line 295. IMHO it will have been even better if you add
&& (Status != STATUS_END_OF_FILE)
in stead. Do you really need a diff for this?
See added line numbers below.
- Guido
On Tuesday 25 September 2001 20:27, Jason Filby wrote:
> Has anyone tested/updated the tree with this update and the latest
> one from Jack?
>
> Jack: it seems that most developers prefer that you send them the
> "diffs".. but I don't think I have diff installed?..
>
> - Jason
>
> --- "Jack (Butch) Griffin" <bu...@qw...> wrote:
> > I have been playing with the ReactOS operating system and trying to
> > get a
> > console mode app written in vistual C++ to run. The app is your
> > basic hello
> > world application. I did not really expect that the complete
> > infra-structure was in place for this to run, but I figured it
> > would point
> > out what was missing and give me a starting point for beginning to
> > learn
> > about the design of this OS.
> >
> > Anyway I have found a problem and do not know who should get the
> > updated
> > code. The problem is in MiReadPage() and the updated code is
> > below. The
> > only change is that STATUS_END_OF_FILE is a legimate return from
> > IoPageRead(). It does not mean an error occurred, just that the
> > file did
> > not contain enough data to fill the page. Function that call
> > MiReadPage()
> > assume that the data read are OK if the return value is
> > STATUS_END_OF_FILE,
> > so the update of the Page pointer must be done in this case.
> >
> > Thanks
> > Jack Griffin
252: NTSTATUS
MiReadPage(PMEMORY_AREA MemoryArea,
PLARGE_INTEGER Offset,
PVOID* Page)
{
IO_STATUS_BLOCK IoStatus;
PFILE_OBJECT FileObject;
PMDL Mdl;
NTSTATUS Status;
PREACTOS_COMMON_FCB_HEADER Fcb;
FileObject = MemoryArea->Data.SectionData.Section->FileObject;
Fcb = (PREACTOS_COMMON_FCB_HEADER)FileObject->FsContext;
if (FileObject->Flags & FO_DIRECT_CACHE_PAGING_READ &&
(Offset->QuadPart % PAGESIZE) == 0)
{
ULONG BaseOffset;
PVOID BaseAddress;
BOOLEAN UptoDate;
PCACHE_SEGMENT CacheSeg;
LARGE_INTEGER SegOffset;
PHYSICAL_ADDRESS Addr;
Status = CcRosGetCacheSegment(Fcb->Bcb,
(ULONG)Offset->QuadPart,
&BaseOffset,
&BaseAddress,
&UptoDate,
&CacheSeg);
if (!NT_SUCCESS(Status))
{
return(Status);
}
if (!UptoDate)
{
Mdl = MmCreateMdl(NULL, BaseAddress, Fcb->Bcb->CacheSegmentSize);
MmBuildMdlForNonPagedPool(Mdl);
SegOffset.QuadPart = BaseOffset;
290: Status = IoPageRead(FileObject,
Mdl,
&SegOffset,
&IoStatus,
TRUE);
295: if (!NT_SUCCESS(Status) && Status != STATUS_END_OF_FILE)
{
CcRosReleaseCacheSegment(Fcb->Bcb, CacheSeg, FALSE);
return(Status);
}
}
Addr = MmGetPhysicalAddress(BaseAddress +
Offset->QuadPart - BaseOffset);
(*Page) = (PVOID)(ULONG)Addr.QuadPart;
MmReferencePage((*Page));
CcRosReleaseCacheSegment(Fcb->Bcb, CacheSeg, TRUE);
return(STATUS_SUCCESS);
}
else
{
/*
* Allocate a page, this is rather complicated by the possibility
* we might have to move other things out of memory
*/
(*Page) = MmAllocPage(0);
while ((*Page) == NULL)
{
MmWaitForFreePages();
(*Page) = MmAllocPage(0);
}
/*
* Create an mdl to hold the page we are going to read data into.
*/
Mdl = MmCreateMdl(NULL, NULL, PAGESIZE);
MmBuildMdlFromPages(Mdl, (PULONG)Page);
/*
* Call the FSD to read the page
*/
Status = IoPageRead(FileObject,
Mdl,
Offset,
&IoStatus,
FALSE);
return(Status);
}
337: }
====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html =
====================================================
|
|
From: David W. <we...@cw...> - 2001-09-25 19:35:40
|
On Mon, Sep 24, 2001 at 08:15:23PM -0400, Phillip Susi wrote: > We have our own win32 api headers and libs in reactos, so why do we still > use the mingw win32 api? I think we should modify the makefiles to the > headers and libs in reactos, instead of the system includes and libs, which > requires that the mingw win32 api is installed. > Why? It would be better to use the mingw header since they are more regularly updated and it prevents writing unnecessary dependencies on reactos in test programs. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
8 messages has been excluded from this view by a project administrator.
