Anyone have any comments, or something they believe I should add before I send the patch? Tom
"Tom" <twickline(a)skybest.com> 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? -- Dmitry.
Dmitry Timoshkov wrote:
"Tom" <twickline(a)skybest.com> 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
"Tom" <twickline(a)skybest.com> 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. -- Dmitry.
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 :() -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
--- "Gregory M. Turner" <gmturner007(a)ameritech.net> 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/
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 -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
> [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+ -- Eric Pouech
participants (6)
-
Dmitry Timoshkov -
Eric Pouech -
Gregory M. Turner -
Juan Lang -
Shachar Shemesh -
Tom