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: Eric K. <ek...@rz...> - 2001-11-12 10:20:37
|
"Brian Palmer" <br...@sg...> wrote: > As of version 11.0c, Watcom C/C++ is going to be open source. > www.openwatcom.org AFAICS it is only an update yet. The full version is not available. And it is huuuuge, the update is more than 45MB. :-/ > Although it would be useful for loadros to support the registry, and being > able to boot from DOS is handy, I don't think that turning it into a full > boot loader would be worthwhile. There is too much that would need to be > added that is already there in FreeLoader. To me loadros has always seemed > like a hack that needs to be put out to pasture. You're right, the existing loadros is a hack. But OTOH, FreeLoader is not that much better. For each bios call FreeLoader must switch to real mode and back to protected mode while a modified loadros runs in flat real mode, this means it can call into the bios without mode switching and can access the full 4GB physical memory space. AFAIR, the main problem with FreeLoader was the 32bit disk access. IMHO it is extremely bad to call these bios functions from protected mode. It is not only the mode-switching but especially the fact that all parameters have to be passed to the bios in a buffer. Brrr.. :-/ - Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Jason F. <jas...@ya...> - 2001-11-12 09:42:18
|
--- Brian Palmer <br...@sg...> wrote: >As of version 11.0c, Watcom C/C++ is going to be open source. >www.openwatcom.org This looks good! >To me loadros has always seemed like a hack that needs to be put out >to pasture. But its the only way I can test ros on real hardware! - Jason __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Brian P. <br...@sg...> - 2001-11-12 09:11:18
|
As of version 11.0c, Watcom C/C++ is going to be open source. www.openwatcom.org Although it would be useful for loadros to support the registry, and being able to boot from DOS is handy, I don't think that turning it into a full boot loader would be worthwhile. There is too much that would need to be added that is already there in FreeLoader. To me loadros has always seemed like a hack that needs to be put out to pasture. Brian -----Original Message----- From: Eric Kohl [mailto:ek...@rz...] Sent: Sunday, November 11, 2001 6:40 PM To: ros...@re... Subject: [ros-kernel] Thoughts about loadros Hi! As we all know, the boot process of ReactOS is not as good as it should be. Although Brian Palmer has done a very good job with writing FreeLoader, I think we really need to fill in some very really huge gaps. The main problem is that no boot loader, neither FreeLoader nor loadros, is able to load the system hive, load drivers accroding to the system hive, analyze the system-configuration and pass the drivers, the system hive and the hardware hive to ntoskrnl. One of the major showstoppers is djgpp. It generates 32-bit protected mode code that uses a dos extender to run on 16-bit real mode dos. Unfortunately we need a 16-bit real mode compiler to build the boot loader. Within the last two or three weeks I had a look at some freely available compilers and I found 'Digital Mars', the former Zortech/Symantec compiler (http://www.digitalmars.com). Today I was looking for something called 'real flat mode' or 'unreal mode', a nice feature of x86 processors that allows 4GB(!) data segments real mode. I found a little 'library' (flat100.zip) that provides easy access to such a large data segment. This library is available with source included (precompiled with nasm) and seems to be usable with the Digital Mars compiler. IMHO, it is a good idea to use the Digital Mars compiler and flat100 to add the registry hive code to loadros. In a second step we can change loadros from a dos program to a stand-alone boot-loader. Of course we can, use some FreeLoader code too. For example the .ini-file code or the tui code. What do you think?? - Eric Kohl ==================================================== = 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: Steven E. <Ste...@kn...> - 2001-11-12 05:16:33
|
I dont know why it needs shell32 and comcrtl its screwy. Anyway here it is http://65.8.134.110/temp/vim.exe Go figure Steven########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ |
|
From: Phillip S. <ps...@cf...> - 2001-11-12 01:52:58
|
Could someone remove this guy from the mailing list? I'm getting tired of all of these bounced messages. >Conversion: Allowed >Original-Encoded-Information-Types: IA5-Text >Priority: normal >Disclose-Recipients: Prohibited >Alternate-Recipient: Allowed >Date: 12 Nov 2001 01:23:12 +0100 >From: Mailer-Daemon <Mai...@ze...> >To: psusi <ps...@cf...> >Subject: Undeliverable Mail > >------------------------- Could not deliver Message to >------------------------- > CN=Heiko Ronsdorf/OU=DEMAI/O=Schott@SCHOTT > >Router: Unable to open mailbox file SDEJENS2000/SERVER/SCHOTT mail.box: >Server not responding > >----------------------------- Your Original Message >---------------------------- > >Date: 11/11/2001 01:12 AM >From: ps...@cf...@Internet >Subject: [ros-general] Re: GUI commision >Priority: Normal >Importance: 2 >Nice... how is that going? I was thinking of trying to get emacs to work. > >At 06:13 PM 11/10/2001 -0500, you wrote: > > >As for the text mode stuff I've been working on getting vi and mc to work > >under reactos. > >==================================================== >= 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: Eric K. <ek...@rz...> - 2001-11-12 01:51:58
|
Hi! As we all know, the boot process of ReactOS is not as good as it should be. Although Brian Palmer has done a very good job with writing FreeLoader, I think we really need to fill in some very really huge gaps. The main problem is that no boot loader, neither FreeLoader nor loadros, is able to load the system hive, load drivers accroding to the system hive, analyze the system-configuration and pass the drivers, the system hive and the hardware hive to ntoskrnl. One of the major showstoppers is djgpp. It generates 32-bit protected mode code that uses a dos extender to run on 16-bit real mode dos. Unfortunately we need a 16-bit real mode compiler to build the boot loader. Within the last two or three weeks I had a look at some freely available compilers and I found 'Digital Mars', the former Zortech/Symantec compiler (http://www.digitalmars.com). Today I was looking for something called 'real flat mode' or 'unreal mode', a nice feature of x86 processors that allows 4GB(!) data segments real mode. I found a little 'library' (flat100.zip) that provides easy access to such a large data segment. This library is available with source included (precompiled with nasm) and seems to be usable with the Digital Mars compiler. IMHO, it is a good idea to use the Digital Mars compiler and flat100 to add the registry hive code to loadros. In a second step we can change loadros from a dos program to a stand-alone boot-loader. Of course we can, use some FreeLoader code too. For example the .ini-file code or the tui code. What do you think?? - Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: James T. <jim...@ad...> - 2001-11-11 22:45:49
|
Hi, Jakob Eriksson wrote: > > AFAIK there are two vims for windows out there. > > A unix one - compiled under cygwin. > > A native windows version with a lot of windows bells and whistles. > > On Sun, Nov 11, 2001 at 03:54:32PM -0500, Phillip Susi wrote: > > Isn't vim console based? Then why the heck is it importing things from > > user32, comctl32, and shell32? > > > > At 03:40 PM 11/11/2001 -0500, you wrote: > > > > >vim.exe crashes because it cant import GetSysColotPen which is a export of > > >user32. This is what happens when i try to run vim.exe for win32 Of course! It's just a stub right now in user32!. "GetSysColorPen". > > > > > >Transferring control to image at 4011d4 > > >(misc/dllmain.c:38) ADVAPI32: DllMain() done > > >LdrFixupForward: failed to load NTDLL > > >LdrGetExportByName(): failed to find GetSysColorPen > > >Failed to import GetSysColorPen > > >LdrFixupImports() failed > > >LdrFixupImports:failed to load comctl32.dll > > >LdrFixupImports() failed > > >LdrFixupImports:failed to load SHELL32.dll > > >LdrFixupImports() failed > > >Failed to initialize image > > > > > >I've made a install script for wine so if anyone needs to test this or > > >other programs under reactos just go to the root or the reactos source > > >tree and run installwine.bat this will install the wine dlls to > > > > > >%SYSTEMROOT%\system32 and the winelib programs to C:\bin. > > > > > >Steven########################################### I'm in the process of reading a book called "Windows Graphics Programming, with Win32 GDI & DirectDraw". Soon I'll start implementing new functions in user32 to get it ready. James ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Jakob E. <ja...@vm...> - 2001-11-11 21:40:15
|
AFAIK there are two vims for windows out there. A unix one - compiled under cygwin. A native windows version with a lot of windows bells and whistles. On Sun, Nov 11, 2001 at 03:54:32PM -0500, Phillip Susi wrote: > Isn't vim console based? Then why the heck is it importing things from > user32, comctl32, and shell32? > > At 03:40 PM 11/11/2001 -0500, you wrote: > > >vim.exe crashes because it cant import GetSysColotPen which is a export of > >user32. This is what happens when i try to run vim.exe for win32 > > > >Transferring control to image at 4011d4 > >(misc/dllmain.c:38) ADVAPI32: DllMain() done > >LdrFixupForward: failed to load NTDLL > >LdrGetExportByName(): failed to find GetSysColorPen > >Failed to import GetSysColorPen > >LdrFixupImports() failed > >LdrFixupImports:failed to load comctl32.dll > >LdrFixupImports() failed > >LdrFixupImports:failed to load SHELL32.dll > >LdrFixupImports() failed > >Failed to initialize image > > > >I've made a install script for wine so if anyone needs to test this or > >other programs under reactos just go to the root or the reactos source > >tree and run installwine.bat this will install the wine dlls to > > > >%SYSTEMROOT%\system32 and the winelib programs to C:\bin. > > > >Steven########################################### > > > > ==================================================== > = 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-11-11 21:15:45
|
Isn't vim console based? Then why the heck is it importing things from user32, comctl32, and shell32? At 03:40 PM 11/11/2001 -0500, you wrote: >vim.exe crashes because it cant import GetSysColotPen which is a export of >user32. This is what happens when i try to run vim.exe for win32 > >Transferring control to image at 4011d4 >(misc/dllmain.c:38) ADVAPI32: DllMain() done >LdrFixupForward: failed to load NTDLL >LdrGetExportByName(): failed to find GetSysColorPen >Failed to import GetSysColorPen >LdrFixupImports() failed >LdrFixupImports:failed to load comctl32.dll >LdrFixupImports() failed >LdrFixupImports:failed to load SHELL32.dll >LdrFixupImports() failed >Failed to initialize image > >I've made a install script for wine so if anyone needs to test this or >other programs under reactos just go to the root or the reactos source >tree and run installwine.bat this will install the wine dlls to > >%SYSTEMROOT%\system32 and the winelib programs to C:\bin. > >Steven########################################### > ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Steven E. <Ste...@kn...> - 2001-11-11 20:58:44
|
vim.exe crashes because it cant import GetSysColotPen which is a export of user32. This is what happens when i try to run vim.exe for win32 Transferring control to image at 4011d4 (misc/dllmain.c:38) ADVAPI32: DllMain() done LdrFixupForward: failed to load NTDLL LdrGetExportByName(): failed to find GetSysColorPen Failed to import GetSysColorPen LdrFixupImports() failed LdrFixupImports:failed to load comctl32.dll LdrFixupImports() failed LdrFixupImports:failed to load SHELL32.dll LdrFixupImports() failed Failed to initialize image I've made a install script for wine so if anyone needs to test this or other programs under reactos just go to the root or the reactos source tree and run installwine.bat this will install the wine dlls to %SYSTEMROOT%\system32 and the winelib programs to C:\bin. Steven########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ |
|
From: Aliberti E. <ea...@io...> - 2001-11-11 20:42:30
|
Overcoming User32.dll Initialization Failure Errors: http://support.microsoft.com/support/kb/articles/Q126/9/62.asp ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Aliberti E. <ea...@io...> - 2001-11-11 20:39:51
|
http://support.microsoft.com/support/kb/articles/Q126/9/62.asp ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Steven E. <Ste...@kn...> - 2001-11-11 20:10:57
|
Filesystems are ext2. fat16. fat32. minix Programs? almost everything in the source tree plus some console win32 apps and win32 apps ported via mingw -----Original Message----- From: Brandon Sharitt [mailto:bra...@ho...] Sent: Sunday, November 11, 2001 2:13 PM To: ros...@re... Subject: [ros-kernel] A Few question before I start I just had a few technical questions before I start work with ReactOS. First off, what file systems does it support? Second, are there any programs that run under it yet? _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ |
|
From: Brandon S. <bra...@ho...> - 2001-11-11 19:17:53
|
I just had a few technical questions before I start work with ReactOS. First off, what file systems does it support? Second, are there any programs that run under it yet? _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Eric K. <ek...@rz...> - 2001-11-11 16:24:26
|
"Phillip Susi" <ps...@cf...> wrote: > Ohh... odd.. what was the error message? Maybe it doesn't like the exe in > there because it could be a virus, try zipping the exe or changing the > extention. If that still does not work, I'll have to yell at them. > I already packed it. Usually I don't send 500k++ files unpacked. ;-) Perhaps your ISP established an attachement size limit?? - Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-11 16:09:36
|
Ohh... odd.. what was the error message? Maybe it doesn't like the exe in there because it could be a virus, try zipping the exe or changing the extention. If that still does not work, I'll have to yell at them. At 04:44 PM 11/11/2001 +0100, you wrote: >"Phillip Susi" <ps...@cf...> wrote: > > > > Odd... the last message I got from you had the script11.rc attached, and I > > just got the midnight commander attachment. I have noticed though that > > whenever I post something to the mailing list, I get a bounce back saying > > the message is looping. I think someone who is subscribed to the list has > > a broken email server, but I don't think it is me. > > >I also sent a fixed windres.exe to 'ps...@cf...' and it bounced. This >has nothing to do with the mailing-list. > >- Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Eric K. <ek...@rz...> - 2001-11-11 15:49:01
|
"Phillip Susi" <ps...@cf...> wrote: > Odd... the last message I got from you had the script11.rc attached, and I > just got the midnight commander attachment. I have noticed though that > whenever I post something to the mailing list, I get a bounce back saying > the message is looping. I think someone who is subscribed to the list has > a broken email server, but I don't think it is me. > I also sent a fixed windres.exe to 'ps...@cf...' and it bounced. This has nothing to do with the mailing-list. - Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-11 15:46:31
|
At 11:28 AM 11/11/2001 +0100, you wrote: >For asynchronous i/o the FSD can't only queued up to request to the >underlaying driver. At some points, the FSD must synchronisize the access >to some internal structures. With which other functions as a thread can the >FSD wait for acquireing a synchronisation object, such a ersource? At the >moment, vfat ask for acquireing the eresource and when the caller can't >wait for completion of the request, vfat queue the request as a thread to >the system worker queue. The thread wait for acquireing the eresource >object. I doesn't know an other function, that can do this. I thought that acquiring an ERESOURCE was like a spin lock - it can be done from any IRQL and does not context switch. Even if it does though, this would only introduce the context switching in the rare event of contention of the resource, most of the time the FSD will directly queue the IO to the device driver, and return to the caller with no context switching. Also in the event of contention on the resource, you can do one better than having another thread block waiting for the resource. Instead you can insert the request into an interlocked queue of requests waiting on the resource, and when the resource is released, the next request will be handled right then and there. This is how system IRP queuing and serialization to adapter objects works. >An other way is, that the chache manger add/merge the pages from some cache >segments within one mdl and then call the FSD with this large mdl for a >paging io. For paging io as a result from page faults in section views, the >memory manger should read and map more then one page. So it sounds like you want to rewrite the cc to work the way NT's does: map views of the data to cache and fault it in? ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-11 15:36:46
|
Odd... the last message I got from you had the script11.rc attached, and I just got the midnight commander attachment. I have noticed though that whenever I post something to the mailing list, I get a bounce back saying the message is looping. I think someone who is subscribed to the list has a broken email server, but I don't think it is me. At 04:16 PM 11/11/2001 +0100, you wrote: >Your e-Mail address seems to be broken or your mail server does not accept >any attachments. I wanted to send you the fixed windres.exe but the mails >bounced. > >- Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Eric K. <ek...@rz...> - 2001-11-11 15:17:40
|
Your e-Mail address seems to be broken or your mail server does not accept any attachments. I wanted to send you the fixed windres.exe but the mails bounced. - Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Heinz R. <Hei...@st...> - 2001-11-11 13:04:54
|
Hello Would it be possible that the loader code gets a addtion call to interrupt 0x15 to be exactly to function 0xC0. So that the infos Model Byte,Submodel Byte and Feature Information could be given to the kernel so that ReactOS drivers and also the kernel can access this infos ?. This would be a great help because PS/2's needs on some parts special handling and threw this check this special handling would become automatic and it would not be needed to recompile the kernel with a kernel switch to compile in the different support. If it is not possible does someone know a way to get on this infos when reactos is already started ? I know that i can read out the Model and Submodel byte at F000:FFFE but i don't know a place where to read out the MCA flag and a list with all models that have a MCA bus would no good solution. With nice greetings Heinz ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Hartmut B. <har...@te...> - 2001-11-11 10:38:41
|
> This is just not true. A higher level driver that context switches to > another thread only to have it block until IO completion is just as nasty > of a kludge as a lower level driver that constantly busy waits until it's > device is done, rather than waiting for the device to interrupt. The whole > idea behind async IO is that a program can request the IO, the FSD tells > the device driver to request the IO, and the device driver tells the > hardware to start the IO, and returns back to the calling program which can > then do other work while the IO is in progress. The device can then > interrupt, and then IO be completed back to the calling program, all > without a single context switch, as long as the calling program has enough > other work to keep it busy while the IO is going on, and if it doesn't have > any more work to do, then switching to the idle thread isn't wasting any > cycles that could be better used anyhow. By the way, an ISR and DPC is not > a context switch, at least in NT terminology. Switching threads is far > more costly than handling an interrupt or calling a DPC in > KeLowerIrql(). NT and all other decent kernels that support async IO do it > this way, and so should we. For asynchronous i/o the FSD can't only queued up to request to the underlaying driver. At some points, the FSD must synchronisize the access to some internal structures. With which other functions as a thread can the FSD wait for acquireing a synchronisation object, such a ersource? At the moment, vfat ask for acquireing the eresource and when the caller can't wait for completion of the request, vfat queue the request as a thread to the system worker queue. The thread wait for acquireing the eresource object. I doesn't know an other function, that can do this. > >The current cache manger can only handle small memory segments. This > >results in many calls to the fsd, when there is a read or write with large > >datas, which are not in the cache. The cooperation betwen the cache and the > >memory manger isn't good. Each missing page results in a single call to the > >fsd for 4K page. The cache manager has no read ahead or delayed write > >function. But this is not only the problem of the cache or memory manger. > >Vfatfs must also provide some functions for the cache manager. > > I see. So you think we need to implement the cache manager the NT way then? An other way is, that the chache manger add/merge the pages from some cache segments within one mdl and then call the FSD with this large mdl for a paging io. For paging io as a result from page faults in section views, the memory manger should read and map more then one page. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Hartmut B. <har...@te...> - 2001-11-11 10:35:39
|
> > The current cache manger can only handle small memory segments. This > > results in many calls to the fsd, when there is a read or write with large > > datas, which are not in the cache. > > > This is not true; the fileystem can select the size of the segments which > are used. The filesystem know the size. For a read operation the kernel seclect the correct size. When the datas are in the cache, there is a simple copy operation within memory. When the datas are not in the cache, the cache manger makes for each cache segment a call to the FSD for reading the segment. On FAT32 it is a call for a 4k page. This is result from moving the cache manager function from vfat to the kernel. > > The cooperation betwen the cache and the memory manger isn't good. Each > > missing page results in a single call to the fsd for 4K page. The cache > > manager has no read ahead or delayed write function. > > > I'm working on fixing this. Could you give more detail about what is > missing in the cache manager to support asynchronous i/o. The missing functions are not for asynchronous i/o. For a 'big' rewrite of the vfat driver, there needs some more of the Cc-functions (CcFlushCache, CcCanIWrite, CcDefereWrite, CcPurgeCacheSection, ...). Vfatfs must also implement some callback functions (AcquireForLazyWrite, ReleaseFromLazyWrite, AcquireForReadAhead, ReleaseFromReadAhead). ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Robert C. <rob...@it...> - 2001-11-11 10:23:44
|
----- Original Message ----- From: "Steven Edwards" <Ste...@kn...> To: <ros...@re...> Sent: Sunday, November 11, 2001 2:35 PM Subject: [ros-kernel] RE: Re: mingw was RE: windres help > When I submited a bug report it took about a month and a half to get it > addressed. At this rate getting mingw updated would take a long time. Eric > had suggested submitting everything back to mingw. I'd definately submit your patches back in. Bug reports and patches are _very_ different things. I would be very surprised to see a patch ignored for a month and a half. Rob ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Steven E. <Ste...@kn...> - 2001-11-11 09:03:49
|
it loads, works for a bit, then hangs. Still its a nice improvement. Steven########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ |
8 messages has been excluded from this view by a project administrator.
