August 2013 - Wine-Devel - list.winehq.org

Re: Sequences in a loop

by Michael Stefaniuc

On 08/30/2013 02:33 PM, matyapiro31 wrote: > I found many wine sources use not a pointer,but a sequence . > for example: > krnl386.exe16/dma.c: > for(i=0,p=(char*)DMA_CurrentBaseAddress[channel];i<ret*size;i++) > msdaps/usrmarshal.c: for(prop = 0; prop < > rgPropertySets[prop_set].cProperties; prop++) > I know in some cases to use sequences are wiser way than pointers, > but so many of them are used in loops. > Should I change them? Optimizations should be primary for the human reader of the code. Compilers nowadays do a far better job at micro-optimization than humans. bye michael

Aug. 30, 2013

Re: Sequences in a loop

by Nikolay Sivov

On 8/30/2013 16:33, matyapiro31 wrote: > I found many wine sources use not a pointer,but a sequence . > for example: > krnl386.exe16/dma.c: > for(i=0,p=(char*)DMA_CurrentBaseAddress[channel];i<ret*size;i++) > msdaps/usrmarshal.c: for(prop = 0; prop < > rgPropertySets[prop_set].cProperties; prop++) > I know in some cases to use sequences are wiser way than pointers, > but so many of them are used in loops. I guess by sequences you mean arrays? > Should I change them? > Change them to what? And what will it solve?

Aug. 30, 2013

Re: Help to create a server request

by Bruno Jesus

On Thu, Aug 29, 2013 at 10:38 PM, Charles Davis <cdavis5x(a)gmail.com> wrote: > To add a new request to the server, you first add a definition to server/protocol.def . This file is processed by the make_requests tool, which generates a bunch of other files from it. The syntax of the server protocol definition file is somewhat like Objective-C (if you've ever used or seen that). A typical server request definition looks like this: > > @REQ(request_name) > /* input parameters go here */ > int input; > obj_handle_t handle; /* don't use Windows types */ > @REPLY > /* output values go here */ > int output; > @END Thanks for the information, before sending the email I tried making the DECL_HANDLER and used with SERVER_START_REQ but I was not aware of the server/protocol.def so it was not working. > There's lots of examples throughout Wine of this in action, especially in lower-level DLLs like ntdll and kernel32; I encourage you to look at them. (That's how I figured all this out, after all.) If you have any more questions (and not just because you were too lazy to even look ;), feel free to ask. > > Chip Thank you again, I guess now I can do it correctly. Basically it's the opposite of the create_socket message. http://source.winehq.org/source/server/protocol.def#L1131 Regards, Bruno

Aug. 30, 2013

Re: oleaut32: Add ICreateTypeInfo2::SetVarName implementation

by Nikolay Sivov

On 8/30/2013 16:28, Piotr Caban wrote: > --- > dlls/oleaut32/tests/typelib.c | 13 +++++++++++-- > dlls/oleaut32/typelib.c | 13 +++++++++++-- > 2 files changed, 22 insertions(+), 4 deletions(-) > > > > ITypeInfoImpl *This = info_impl_from_ICreateTypeInfo2(iface); > - FIXME("%p %u %s - stub\n", This, index, wine_dbgstr_w(name)); > - return E_NOTIMPL; > + > + FIXME("%p %u %s\n", This, index, wine_dbgstr_w(name)); > + It probably should be TRACE.

Aug. 30, 2013

Sequences in a loop

by matyapiro31

I found many wine sources use not a pointer,but a sequence . for example: krnl386.exe16/dma.c: for(i=0,p=(char*)DMA_CurrentBaseAddress[channel];i<ret*size;i++) msdaps/usrmarshal.c: for(prop = 0; prop < rgPropertySets[prop_set].cProperties; prop++) I know in some cases to use sequences are wiser way than pointers, but so many of them are used in loops. Should I change them?

Aug. 30, 2013

Re: ntdll: Store full line status register in the internal structure, not just the TIOCSER_TEMT bit. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> >> > Printing complete lsr value in the log may help with diagnosing >> >> > test failures on Alexandre's machine. >> >> >> >> I don't see how, since TIOCSER_TEMT is the only defined bit. Do you >> >> actually have a driver that returns other status? >> > >> > I don't, but maybe yours does. The only way to check that is to store >> > and print the whole LSR value. >> >> Or you could check the kernel source and see what TIOCSERGETLSR does... > > Of course I did check the kernel source, and looked around in various > mailing lists, which made me think that your kernel may set UART_LSR_TEMT > instead... If you find a place in the kernel that does this, it's a bug. And no, my kernel returns TIOCSER_TEMT, like everybody else's. -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2013

Re: ntdll: Store full line status register in the internal structure, not just the TIOCSER_TEMT bit. Take 2.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > >> > Printing complete lsr value in the log may help with diagnosing > >> > test failures on Alexandre's machine. > >> > >> I don't see how, since TIOCSER_TEMT is the only defined bit. Do you > >> actually have a driver that returns other status? > > > > I don't, but maybe yours does. The only way to check that is to store > > and print the whole LSR value. > > Or you could check the kernel source and see what TIOCSERGETLSR does... Of course I did check the kernel source, and looked around in various mailing lists, which made me think that your kernel may set UART_LSR_TEMT instead... -- Dmitry.

Aug. 30, 2013

Re: ntdll: Store full line status register in the internal structure, not just the TIOCSER_TEMT bit. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> > Printing complete lsr value in the log may help with diagnosing >> > test failures on Alexandre's machine. >> >> I don't see how, since TIOCSER_TEMT is the only defined bit. Do you >> actually have a driver that returns other status? > > I don't, but maybe yours does. The only way to check that is to store > and print the whole LSR value. Or you could check the kernel source and see what TIOCSERGETLSR does... > Do you happen to have something connected to COM-port (perhaps mouse?) > which may explain test failures. No. -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2013

Re: ntdll: Store full line status register in the internal structure, not just the TIOCSER_TEMT bit. Take 2.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > > Printing complete lsr value in the log may help with diagnosing > > test failures on Alexandre's machine. > > I don't see how, since TIOCSER_TEMT is the only defined bit. Do you > actually have a driver that returns other status? I don't, but maybe yours does. The only way to check that is to store and print the whole LSR value. Do you happen to have something connected to COM-port (perhaps mouse?) which may explain test failures. -- Dmitry.

Aug. 30, 2013

Re: ntdll: Store full line status register in the internal structure, not just the TIOCSER_TEMT bit. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Printing complete lsr value in the log may help with diagnosing > test failures on Alexandre's machine. I don't see how, since TIOCSER_TEMT is the only defined bit. Do you actually have a driver that returns other status? -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2013