Status ToDo's

[Tom]

Anyone have any comments, or something they believe I should add
before I send the patch?

Tom

[Dmitry Timoshkov]

"Tom"  wrote:
> National Language Support
>
> a.. We currently lack a way to model heirachical resources like
> those required by calendar information (each locale has a varaible
> number of calendars, with different attributes). This is a show
> stopper for completing the NLS Api (Get/EnumCalendarInfo etc). 
>   b.. Our text output needs to substitute fonts on the fly when
> characters to be printed cannot be represented in the current font.

Despite the obvious typos (heirachical vs. hierarchical, varaible vs.
variable) where that both did come from? Any evidence of the both
statements?

[Tom]

Dmitry Timoshkov wrote:
> "Tom"  wrote:
> > National Language Support
> >
> > a.. We currently lack a way to model heirachical resources like
> > those required by calendar information (each locale has a varaible
> > number of calendars, with different attributes). This is a show
> > stopper for completing the NLS Api (Get/EnumCalendarInfo etc). 
> >  b.. Our text output needs to substitute fonts on the fly when
> > characters to be printed cannot be represented in the current font.
>
> Despite the obvious typos (heirachical vs. hierarchical, varaible vs.
> variable) where that both did come from? Any evidence of the both
> statements?

So, you contend these statements are false?

Tom

[Dmitry Timoshkov]

"Tom"  wrote:
> > > National Language Support
> > >
> > > a.. We currently lack a way to model heirachical resources like
> > > those required by calendar information (each locale has a varaible
> > > number of calendars, with different attributes). This is a show
> > > stopper for completing the NLS Api (Get/EnumCalendarInfo etc). 
> > >  b.. Our text output needs to substitute fonts on the fly when
> > > characters to be printed cannot be represented in the current font.
> >
> > Despite the obvious typos (heirachical vs. hierarchical, varaible vs.
> > variable) where that both did come from? Any evidence of the both
> > statements?
>
> So, you contend these statements are false?

I'm not sure. Just wanted to check with a person offered that
statements. Perhaps there is an app or a test case proving them.
There is a good chance that I'm missing something.

[Gregory M. Turner]

On Friday 26 December 2003 06:27 am, Tom wrote:
> Anyone have any comments, or something they believe I should add
> before I send the patch?
>
> Tom

----
Kernel32

Split 16/32 function, finish moving stuff into ntdll (review FS & device 
support)
Implement non-local named pipes and mailslots over SMB
Implement SMB over Netbios
[...]
RPCRT4

Implment the undocumented "NT Ports" API (aka "LPC") used by native NT
Fill out the matrix of per-type /Oi marshalling API's.
Some real RPC tests,although there are some tests of some peripheral rpcrt4 
API's -- no actual RPC's are tested.
Implement /Oicf "stubless" marshalling
Implement full stub/proxy support for widl
Invent, propose, and evangelize some solution to the Samba-vs-wine TCP/IP RPC 
port-grabbing problem.
Get Wine's DCOM to use wine's RPC as appropriate.
Fix the wire protocol
----

If nonlocal named-pipes over SMB is to go into kernel, then it no longer falls 
upon rpcrt4 dev's to invent a solution to Samba-vs-wine... I guess this 
burden falls on the shoulders of Juan Lang now?  What say you, Juan?

Also, as a sort of subset of the wire-protocol task, you may want to add 
"Implement the OXID resolver and other ORPC peccadilloes".

Finally, Implement is misspelled above.  (The misspelling is probably 
cut-and-pasted from me :()

[Juan Lang]

--- "Gregory M. Turner" 
wrote:
> If nonlocal named-pipes over SMB is to go into
> kernel, then it no longer falls 
> upon rpcrt4 dev's to invent a solution to
> Samba-vs-wine... I guess this 
> burden falls on the shoulders of Juan Lang now? 
> What say you, Juan?

Agreed.  I'm not sure how much of an issue the
Samba-vs-wine port thing is anyway.  It prevents you
from acting as a NetBIOS server, which in turn
prevents you from being an RPC server, and also I
imagine would prevent you from implementing RPC
callbacks (and other fun things like DCOM connection
points).  But RPC clients should work without issue
once non-local named pipes work.

--Juan

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

[Shachar Shemesh]

Tom wrote:
> Anyone have any comments, or something they believe I should add
> before I send the patch?
>
> Tom
>   National Language Support
>
> * Better support of Chinese, Korean, Japanese...(currently in works)

Better support of BiDi - Arabic, Hebrew...

Shachar

[Eric Pouech]

> [DirectSound]
> - Hardware accelerated direct sound capture driver support using the Windows CE2 HAL API
> - 3D buffer support in software is present but incomplete.
> - 3D buffer hardware support
> - Sound effects on buffers
> - Capture effects
> - Full duplex support is stubbed out but not functional.
> - DX9 support for new PCM formats (24/32 bit and float samples) and for more than 2 channels is not present.

I'd add also:
- no longer use the hack in Wine sound drivers to map the DSound driver 
interface to an existing WinMM driver (will likely require a real 
installation scheme for MM drivers)
>   Winedbg
>
> * Make winedbg use dbghelp DLL
> * Speed up PDB support

- implement support for latest MSC formats
>   Native Programs
>
> * Winhelp: fix invocation thru WinHelp

- lots of macros are still missing
>   Tools
>
> * Wine installation process should install and configure wine
> * Perform Windows' reboot operations automatically when required
> * Winemaker fixes
> * Run C regression tests on Windows with MSVC
> * Work on WRC as it does not find system headers

* wineconsole: add configuration bar + resizing capabilities

A+