September 2005 - Wine-Devel

Re: [Now ns7] Dragon ns8 problem

by Kuba Ober

On Wednesday 07 September 2005 08:21, Jean Magnan de Bornier wrote: > Le 06 septembre à 20:30:10 wino(a)piments.com écrit notamment: > | I checked my ~/.wine/config and see the following: > | > | "Drivers" = "wineoss.drv" ; default for most common configurations > > More news: > I put "alsa" as drivers + have now wine 20050830 (gentoo update of today)- > everything better and faster than yesterday. > > Sound level appears now ok for dns; then it wants to learn to recognise my > voice; I have to read two phrases, and then a longer text; in this last > exercise dns gets lost after two lines of text. All the cpu is taken by > wine-preloader processes and this does not appears to ever stop. There > were (last time) 23 wine-preloader processes running! You are aware that (as of 20050111 at least) you have to manually kill -9 leftover wine-preloaders when any wine crash happens, right? And do verify that they in fact got killed. This is a general remark, and following it is by itself unlikely to fix your problem, but at least it will allow you to see that the problem got fixed if/when it gets fixed :) Cheers, Kuba

Sept. 7, 2005

Re: Need ideas about ntoskrnl

by Vitaliy Margolen

First let me thank everyone helping me and Ivan to get ntoskrnl moving forward. Summary of all the ideas and requirements: 1. wineserver should not be used to run drivers (absence of required functionality, single threaded, stability issues) 2. ntoskrnl should be used to run drivers only and link to ntdll and not the other way around. Unless we implement int 0x2e handling and replace wineserver with ntoskrnl. (this is wine not reactos, ntdll already has all the required functionality) 3. Drivers can not be ran in a process that requires them (drivers we concerned about keep information that is shared between different processes, drivers require their own environment that is different from a user process environment, ntdll has no means nor should it have them to run a driver) And that's it. This validates original design by Ivan Leo Puoti for ntoskrnl. Now, there are still unanswered questions: 1. How to talk to ntoskrnl (directly from ntdll or through wineserver). 2. How to get information required for ntoskrnl from wineserver. 3. How to identify this is a device operation and not a file/named pipe/mail slot, etc. I know folks you have more ideas, keep them coming. Vitaliy Margolen

Sept. 7, 2005

Re: Web Server Back Online

by Jeremy Newman

I'm really sorry you guys feel that way. The complaints have been very minimal overall. If I wasn't so busy I can spend more time on it. My problem is that I don't want to go back to Hypermail either. It has serious issues with security and its attachment handling. So any other options/suggestions I'll take. Or if anyone has some ideas on how Brian can get the info he needs. I found a patch that will add the date to the message lists. Problem is, this goes against my policies. I don't like to patch binary packages beyond the normal configuration files. This gets me into a quagmire when I have to update the packages during a security update. It does seem very strange that mailman does not have the date built in. It does let you customize the templates, but leaves out the options for dates and post counts. The patch I found was from way back in 2003. They didn't even accept it back then. Makes me scratch my head when a good open source project like mailman does not accept obvious improvements. On Tue, 2005-09-06 at 14:36 -0600, Brian Vincent wrote: > On 9/2/05, Stefan Leichter <Stefan.Leichter(a)camline.com> wrote: > > Is it possible to get the timestamps back into the mailing list archive? It is > > useful e.g. for regression testing to see when patches were committed to cvs. > > Yeah, it's actually a showstopper for me too and I asked the same > thing. It's exactly why there was no WWN last and why there isn't > likely to be one this week. I'm sure mailman has some great features, > but for me the pipermail archives suck rocks. > > -Brian

Sept. 7, 2005

Re: Need ideas about ntoskrnl

by Rob Shearman

Ivan Leo Puoti wrote: > Peter Beutner wrote: > >> Yupp most of the code maybe already in ntdll. >> But imo it is quite as ugly, from a design point of view, to call ntdll >> functions from inside the ntoskrnl. >> It should be the other way around, shouldn't it? > > > Sure, you just have to convince Alexandre that it's a good idea to > move all the Nt* APIs to ntoskrnl, you're welcome to try but I think > it's something you won't s do before wine 8.0 Every time you feel like saying "you just have to convince Alexandre that it's a good idea" it should be a warning sign that what you are proposing isn't really a good idea. In this case, ntdll shouldn't be calling ntoskrnl because we aren't going to emulate the NT kernel to user apps. That is the job for ReactOS. So yes, ntoskrnl should call ntdll functions because ntoskrnl is just a user-mode client like any other app/dll. Rob

Sept. 7, 2005

Multiple defenitions of CLSID_FileProtocol

by Paul Millar

Hi, Cross-compilation is broken again. This time its CLSID_FileProtocol. The GUID is part of the standard MinGW 3.3 release. I can patch MinGW to remove its definition of this GUID, but I'm not sure this is the correct solution. What do people think? Cheers, Paul. --- i686-mingw32msvc-gcc generated.o misc.o protocol.o url.o testlist.o -o urlmon_test.exe -lurlmon -luser32 -lkernel32 -lole32 -luuid /usr/local/mingw/lib/gcc-lib/i686-mingw32msvc/3.3.3/../../../../i686-mingw32msvc/lib/libuuid.a(uuid.o):/usr/local/src/mingw/build-w32api/lib/../../w32api-3.3/lib/uuid.c (.rdata+0x1a0): multiple definition of `CLSID_FileProtocol' protocol.o:/home/paul/Production/wine-cross-source/dlls/urlmon/tests/protocol.c:63: first defined here

Sept. 7, 2005

Re: [Now ns7] Dragon ns8 problem

by Jean Magnan de Bornier

Le 06 septembre à 20:30:10 wino(a)piments.com écrit notamment: | I checked my ~/.wine/config and see the following: > | "Drivers" = "wineoss.drv" ; default for most common configurations More news: I put "alsa" as drivers + have now wine 20050830 (gentoo update of today)- everything better and faster than yesterday. Sound level appears now ok for dns; then it wants to learn to recognise my voice; I have to read two phrases, and then a longer text; in this last exercise dns gets lost after two lines of text. All the cpu is taken by wine-preloader processes and this does not appears to ever stop. There were (last time) 23 wine-preloader processes running! Would it be something like not enough space allocated to wine?? Thxs -- Jean Magnan de Bornier | Cours Victor Hugo e-mots: jean at bornier.net | 13980 Alleins France T 08 70 39 34 03 | P 06 09 17 35 87

Sept. 7, 2005

Re: Suggestions for improvement of the emulator

by Francois Gouget

On Wed, 7 Sep 2005, Alexandre Julliard wrote: > Francois Gouget <fgouget(a)free.fr> writes: > >> Yeah, maybe a very generic 'Needs review' email to wine-devel would be >> enough. It would also be the clue to the other Wine developpers: >> * that you're not going to be duplicating Alexandre's work if you >> review this patch >> * to look at the patch, dissect it to see what is wrong >> * if it is in your domain of competence and it looks good, post an >> approval message >> * to test the patch >> * and help its author get it accepted > > That should really be the default behavior, all patches need review; > there's no reason to wait until I have looked at a patch to look at > it. If you see a patch in an area that you know anything about, please > review it, don't wait to see my reaction first. Agreed. That's how it should work in an ideal world. The problem is that when reading wine-patches it is easy to look at a patch and think "I don't really know anything about this, I'll let someone more knowledgeable look into it" (and really reviewing patches takes time). Patches that get dropped deserve more effort, if only because by then we know noone else came to a definitive conclusion on them. Yet most of the patches that get dropped don't get a comment from other Wine developpers either and part of the reason is that these patches are difficult to identify. Of course clearly identifying dropped patches could also encourage developpers to only review those patches and ignore wine-patches which would be bad. It's all a tradeoff. I'm willing to accept that we currently have the best tradeoff possible. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

Sept. 7, 2005

Re: fake directx 9c instead of 9b (needed for rFactor Config)

by Christoph Frick

On Wed, Sep 07, 2005 at 10:55:50AM +0100, Oliver Stieber wrote: > > The attached patch sets the version for directx to 9C (instead of > > 9B). The rF\ Config.exe from the game rFactor (www.rfactor.net) > > needs this to work. After that change i was able to successfully run > > the config and configure the game (yet the game itself fails to > > execute by a stack-overflow in the exception handling). > The only real difference between 9C and 9B is shaders, a lot of cards > don't support 9C shaders under windows, even though the drivers are 9C > so even on windows you could consider the version to be 'faked'. > I'll take a look at getting rfactor working a bit better too, or at > least identifying the problems. i am sorry, if this is a little misleading. the "patch" only changes a stored string in the registry. this is only to convince the game, that "directx 9c" is installed. whatever the config does beside the string compare - WINE does it good enough so the config is convinced in having dx9c. it then suggests on my machine the dx7 renderer, which is due to the missing performance of my machine - i can not say, what is missing in WINE, that make the app think dx7 is appropriate. -- cu

Sept. 7, 2005

Re: include/sqltypes.h: Added SQLWCHAR typedef

by Francois Gouget

On Tue, 6 Sep 2005, Phil Krylov wrote: > ChangeLog: > > Added typedef SQLWCHAR to include/sqltypes.h. Could you also add SQLTCHAR while you're at it? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

Sept. 7, 2005

Re: fake directx 9c instead of 9b (needed for rFactor Config)

by Oliver Stieber

--- Christoph Frick <frick(a)sc-networks.de> wrote: > hi gents. > > The attached patch sets the version for directx to 9C (instead of 9B). > The rF\ Config.exe from the game rFactor (www.rfactor.net) needs this to > work. After that change i was able to successfully run the config and > configure the game (yet the game itself fails to execute by a > stack-overflow in the exception handling). > The only real difference between 9C and 9B is shaders, a lot of cards don't support 9C shaders under windows, even though the drivers are 9C so even on windows you could consider the version to be 'faked'. I'll take a look at getting rfactor working a bit better too, or at least identifying the problems. ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Sept. 7, 2005

Re: Suggestions for improvement of the emulator

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > Yeah, maybe a very generic 'Needs review' email to wine-devel would be > enough. It would also be the clue to the other Wine developpers: > * that you're not going to be duplicating Alexandre's work if you > review this patch > * to look at the patch, dissect it to see what is wrong > * if it is in your domain of competence and it looks good, post an > approval message > * to test the patch > * and help its author get it accepted That should really be the default behavior, all patches need review; there's no reason to wait until I have looked at a patch to look at it. If you see a patch in an area that you know anything about, please review it, don't wait to see my reaction first. -- Alexandre Julliard julliard(a)winehq.org

Sept. 7, 2005

Re: Suggestions for improvement of the emulator

by Francois Gouget

On Wed, 7 Sep 2005, Ivan Leo Puoti wrote: > Juan Lang wrote: >> What this misses is the most common status that causes us all to argue: >> uncomitted, because Alexandre's not sure about it. Perhaps he has a gut >> feeling that the approach is not right, but hasn't taken the time to >> identify any particular flaw. Perhaps it merits additional thought. >> Perhaps it's too big to review quickly. Perhaps he hopes the submitter >> will realize it's not up to snuff, and resubmit a better patch. > > So what? just set "Rejected, reason: tests needed" or "will review later" or > whatever. Yeah, maybe a very generic 'Needs review' email to wine-devel would be enough. It would also be the clue to the other Wine developpers: * that you're not going to be duplicating Alexandre's work if you review this patch * to look at the patch, dissect it to see what is wrong * if it is in your domain of competence and it looks good, post an approval message * to test the patch * and help its author get it accepted And the reason I'm proposing a very generic message is so Alexandre does not have to spend time to pinpoint exactly what is wrong with the patch (otherwise he could just as well send a detailed message). As Alexandre once mentioned at WineConf, patches that get 'ignored' are those he is not sure about, or that would take too long to review (e.g. because of size) so that he goes on with the smaller/obvious patches first hoping to come back to the tricky ones later. But the result is that the tricky patches get to the bottom of the pile with the new patches piling on top. So assuming these are still in his 'pending' mailbox, maybe Alexandre could send this generic 'Needs review' message for all patches that are more than one or two days old in his mailbox. Another thing he mentioned at WineConf is that it is ok to ask 'why was my patch not committed?'. Just don't do it an hour after posting the patch of course<g>, wait a day or two. I wonder if this is well documented... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

Sept. 7, 2005

Re: Suggestions for improvement of the emulator

by Alexandre Julliard

Jeremy White <jwhite(a)codeweavers.com> writes: > At the time we were discussing that, though, we didn't > have many volunteer web programmers; maybe we should > revisit that. Alexandre, would you be interested if > folks other than Jer volunteered to help build such a system? Sure, I don't really care who builds it, as long as I can use it from inside Emacs <g> -- Alexandre Julliard julliard(a)winehq.org

Sept. 7, 2005

RE: wine/dlls/shell32 shresdef.h shres.rc shfldr_u ...

by Ge van Geldorp

Michael, > I'm aware of this problem (though I didn't know about the > exact numbers). > There was a short discussion on wine-devel about it: > > http://www.winehq.org/pipermail/wine-devel/2005-August/039452.html I actually read the discussion but didn't make the connection when looking at this problem. > The problem is, that we currently can't read icons via > PrivateExtractIcons from wine's ELF dlls. I would guess that > for ReactOS, you don't need the hack'ish icon cache > pre-initialization at all, since you do have real PE dlls? Yes, you're right on both counts, we do have real PE dlls and it turns out we don't actually need the pre-init. Thanks for solving my problem :-) > As was pointed out by Alexandre, the correct fix for wine > would probably be to try to load the given dll via > LoadModule, if all other methods fail in PrivateExtractIcon. > Unfortunetaly, I don't have time to work on this at the > moment, and probably won't have for the next months. To fix the memory waste, maybe Wine could stop substituting icon with index 0 for non-existent icons in SIC_Initialize? PidlToSicIndex() will try to find the icon and when it doesn't exist will return index 0 anyway. This doesn't solve the general problem of loading resources from Wine dlls ofcourse. Gé van Geldorp.

Sept. 7, 2005

Re: urlmon resource

by Alexandre Julliard

Stefan Leichter <Stefan.Leichter(a)camLine.com> writes: > diff -urw ../wine/dlls/urlmon/Makefile.in dlls/urlmon/Makefile.in > --- ../wine/dlls/urlmon/Makefile.in 2005-09-06 19:18:47.000000000 +0200 > +++ dlls/urlmon/Makefile.in 2005-09-03 21:05:48.000000000 +0200 > @@ -16,7 +15,8 @@ > umstream.c \ > urlmon_main.c > > -RC_SRCS = rsrc.rc > +RC_SRCS = rsrc.rc \ > + version.rc You shouldn't add multiple resource files, mingw unfortunately doesn't support that. Simply #include version.rc from the main file. -- Alexandre Julliard julliard(a)winehq.org

Sept. 7, 2005

Re: add proper support for native NT drivers and programs to the build system

by Alexandre Julliard

Ivan Leo Puoti <ivanleo(a)gmail.com> writes: > ntosknrl? And who's talking about ntoskrnl? This is an attempt to add > generic support for native nt applications, it's not a ntoskrnl specific > thing, and not all native nt apps do their own exception handling. I > certainly understand very few if any people will ever use winebuild on a > native nt app, but that doesn't sound like a good enough reason to not > have support for them. Native NT apps don't need to export stubs. -- Alexandre Julliard julliard(a)winehq.org

Sept. 7, 2005

Re: wine/dlls/shell32 shresdef.h shres.rc shfldr_u ...

by Michael Jung

Hi Ge, On Wednesday 07 September 2005 01:05, you wrote: > I'm working on importing the changes between Wine-20050725 and > Wine-20050830 into ReactOS. This also includes your patch below. > I'm not sure if you realized it, but shell32 now wastes a lot of memory. > The problem is the initialization of the icon cache. Previously, icons with > indexes 1-39 would be loaded. Since IDI_SHELL_MY_DOCUMENTS has such a high > number, now icons with indexes 1-235 are loaded. Most of those ofcourse > don't exist and will be replaced with index 1, but they still take up a lot > of space in the ImageList bitmaps. I've found that, for ReactOS running on > a 32bpp display, memory usage of shell32 increased by 17Mb. This may in > part be a problem in ReactOS (it's much higher than I expected), but even > for Wine the increase in mem usage should be considerable. The ImageLists > get expanded to 494 entries, taking up 494 (entries) * 2 (color + mask) * > 32 (sizex) * 32 (sizey) * 4 (32bpp) = 4Mb per ImageList. We're keeping 2 > ImageLists, plus 2 16*16 ImageLists, all in all we're talking about 10Mb > minimum. And this for every process that loads shell32. I'm aware of this problem (though I didn't know about the exact numbers). There was a short discussion on wine-devel about it: http://www.winehq.org/pipermail/wine-devel/2005-August/039452.html The problem is, that we currently can't read icons via PrivateExtractIcons from wine's ELF dlls. I would guess that for ReactOS, you don't need the hack'ish icon cache pre-initialization at all, since you do have real PE dlls? > For the moment I'm limiting the ReactOS icon cache to the lower 39 entries, > but I think we need to figure out a way to include the My Documents icon > without wasting so much space. As was pointed out by Alexandre, the correct fix for wine would probably be to try to load the given dll via LoadModule, if all other methods fail in PrivateExtractIcon. Unfortunetaly, I don't have time to work on this at the moment, and probably won't have for the next months. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Sept. 7, 2005

Re: Suggestions for improvement of the emulator

by Alexandre Julliard

Hiji <hijinio(a)yahoo.com> writes: > As a user, I've been particularly happy about how Wine > has progressed. However, what is of GRAVE concern to > me is when patches that fix serious bugs aren't > applied; specifically, bug 3148. Even the patch > submitter had to plead with this alias for someone to > listen because no one was paying attention to the > patch. Yet, to date, the patch has either not been > applied nor the bug been fixed. Simple, yet silly, > bugs like the beforementioned one can keep users from > taking advantage of newer versions of Wine because > they prefer to stay with older versions that don't > have the bug(s). That patch was applied 2 weeks ago. -- Alexandre Julliard julliard(a)winehq.org

Sept. 7, 2005

Re: Suggestions for improvement of the emulator

by MediaHost (TM)

Troy Rollo wrote: >What is needed is a system that >records all patches, together with their current status (NEW, APPLIED, >REJECTED (with reasons), and whatever other status), informs the submitter of >any change, and does not allow for a patch merely to be forgotten. > > Absolutely! Bugzilla can make this process better (so not perfect). However all would be very transparent and manageable for the maintainer(s). I think, there is some serious food for thought here.... >It may be that Bugzilla could be coaxed into this role, although I suspect >it's not particularly well adapted to this core task without some >customisation. > > > > > Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org <http://www.startcom.org/> MediaHost^(TM) at www.mediahost.org <http://www.mediahost.org/> Skype: startcom <callto://startcom/> Phone: +1.213.341.0390 Import StartCom Public CA <http://cert.startcom.org/index.php?app=109>

Sept. 7, 2005

Object manager case sensitivity issue

by Vitaliy Margolen

I want to make sure that this problem is well understood. Also to make it clear that Wine differs from windows in this really important aspect. For more details, you can refer to the following thread: http://www.winehq.org/hypermail/wine-devel/2005/04/0426.html It needs to be fixed at least on the server level (I have sent a patch for one of the possible solutions). Then we can get ntdll to follow the suite. For a test see attached program. You should be able to run it on windows with administrative privileges. As you can see, this is something very dangerous yet perfectly legal, at least on win2k sp4. -- Best regards, Vitaliy

Sept. 7, 2005

Re: Need ideas about ntoskrnl

by Ivan Leo Puoti

Peter Beutner wrote: > Yupp most of the code maybe already in ntdll. > But imo it is quite as ugly, from a design point of view, to call ntdll > functions from inside the ntoskrnl. > It should be the other way around, shouldn't it? Sure, you just have to convince Alexandre that it's a good idea to move all the Nt* APIs to ntoskrnl, you're welcome to try but I think it's something you won't s do before wine 8.0 Ivan

Sept. 7, 2005

Strange problem with writing files from wine

by Pavel Troller

Hi! I have problems with writing files from wine (today's CVS). Typical example is word95, which always writes something like: Cannot access folder "F:\filename.doc ": unaccessible or protected by password (in my local language, so it may be inaccurate). There is a small problem with this strange indentation (that the second double quote is on a next line, but it is not fatal. More fatal is that this dialog even occurs and the file cannot be written. I've created a tracefile with +file and I think I've found the problem. At the moment of attempt to write (in this example, F:\brumbal.doc), there appears: trace:file:CreateFileW L"\\\\.\\F:" GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L"\\\\.\\F:",0x7fc8975c,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"\\\\.\\F:" 520 0x7fc89508 (nil)) trace:file:get_dos_device L"F:" -> "/dev/hdb1" warn:file:CreateFileW Unable to create file L"\\\\.\\F:" (status c0000022) trace:file:CreateFileW returning 0xffffffff trace:file:RtlDosPathNameToNtPathName_U (L"F:\\",0x7fc89744,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"F:\\" 520 0x7fc89508 (nil)) trace:file:wine_nt_to_unix_file_name L"\\??\\F:\\" -> "/home/patrol/.wine/dosdevices/f:/" trace:file:GetFileAttributesW L"F:\\brumbal.doc\r\n" trace:file:RtlDosPathNameToNtPathName_U (L"F:\\brumbal.doc\r\n",0x7fc8aae4,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"F:\\brumbal.doc\r\n" 520 0x7fc8a8b0 (nil)) trace:file:CreateFileW L"\\\\.\\F:" GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L"\\\\.\\F:",0x7fc8975c,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"\\\\.\\F:" 520 0x7fc89508 (nil)) trace:file:get_dos_device L"F:" -> "/dev/hdb1" warn:file:CreateFileW Unable to create file L"\\\\.\\F:" (status c0000022) trace:file:CreateFileW returning 0xffffffff trace:file:RtlDosPathNameToNtPathName_U (L"F:\\",0x7fc89744,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"F:\\" 520 0x7fc89508 (nil)) trace:file:wine_nt_to_unix_file_name L"\\??\\F:\\" -> "/home/patrol/.wine/dosdevices/f:/" patrol(a)arcus:/opt/samba-dir/Program Files/Microsoft Office/Office$ Why the hell wine is trying to access /dev/hdb1 ? Yes, my home directory is on it, but I think that such a form of access is not good :-). In my .wine/dosdevices, there is clearly a line lrwxrwxrwx 1 patrol users 12 Sep 7 06:50 f: -> /home/patrol Or am I misinterpreting the log and the failure is caused by something else ? Otherwise wine is working near to perfect now. With regards, Pavel Troller

Sept. 7, 2005

Re: Suggestions for improvement of the emulator

by Ivan Leo Puoti

Juan Lang wrote: > What this misses is the most common status that causes us all to argue: > uncomitted, because Alexandre's not sure about it. Perhaps he has a gut > feeling that the approach is not right, but hasn't taken the time to > identify any particular flaw. Perhaps it merits additional thought. > Perhaps it's too big to review quickly. Perhaps he hopes the submitter > will realize it's not up to snuff, and resubmit a better patch. So what? just set "Rejected, reason: tests needed" or "will review later" or whatever. Ivan.

Sept. 7, 2005

Re: Need ideas about ntoskrnl

by Peter Beutner

Alexandre Julliard schrieb: > Peter Beutner <p.beutner(a)gmx.net> writes: > > >>Any reasons given? > > Stability is the obvious reason. And also of course the fact that we > have most of the code we need in ntdll already and none of it in > wineserver. > Yupp most of the code maybe already in ntdll. But imo it is quite as ugly, from a design point of view, to call ntdll functions from inside the ntoskrnl. It should be the other way around, shouldn't it?

Sept. 7, 2005

Re: Suggestions for improvement of the emulator

by Ivan Leo Puoti

> This of course points to another problem with the existing system - if a patch > has been rejected, it should be a necessary consequence that the submitter is > informed with reasons - they shouldn't have to be chasing up Alexandre to > find out if the patch was rejected or merely missed (which happens often). > This is not to criticise Alexandre, but to point out that systems need to be > put in place to help him manage these things. Just taking patches of the > mailing list is not a sufficient mechanism. What is needed is a system that > records all patches, together with their current status (NEW, APPLIED, > REJECTED (with reasons), and whatever other status), informs the submitter of > any change, and does not allow for a patch merely to be forgotten. I've always thought that sort of thing should be done and would be cool, maybe the guys working on appdb could try and come up with something?

Sept. 6, 2005