Shouldn't the LARGE_UNICODE_STRING be used there instead?
WBR,
Aleksey.
On May 22, 2010, at 5:05 AM, tkreuzer(a)svn.reactos.org wrote:
> Author: tkreuzer
> Date: Sat May 22 03:05:31 2010
> New Revision: 47295
>
> URL: http://svn.reactos.org/svn/reactos?rev=47295&view=rev
> Log:
> [WIN32K / USER32]
> Convert the window text string from UNICODE_STRING to LARGE_STRING
> and fix NtUserCreateWindowEx parameters. We currently still pass
> UNICODE only LARGE_STRINGs, as the rest of the code in win32k
> expects this.
> Fixes display of large text windows, like the winzip license.
> See issue #2900 for more details.
>
> Modified:
> trunk/reactos/dll/win32/user32/windows/window.c
> trunk/reactos/include/reactos/win32k/ntuser.h
> trunk/reactos/subsystems/win32/win32k/include/window.h
> trunk/reactos/subsystems/win32/win32k/ntuser/desktop.c
> trunk/reactos/subsystems/win32/win32k/ntuser/message.c
> trunk/reactos/subsystems/win32/win32k/ntuser/painting.c
> trunk/reactos/subsystems/win32/win32k/ntuser/window.c
Hi Michael,
there is no need to hardcode the messagebox output language to english.
In the resource files a string exists for what you're doing:
IDS_FINISHEDFIND (probably already loaded into a string in the code
somewhere).
Thanks,
Gregor
"Jan Blomqvist Kinander" <jan.blomqvist(a)reactos.org> wrote:
> Opening many sessions in windows is really bad idea ... for kernel stuff and another csrss, smss problems ... terminal server blue screen, black screen, printers, etc ... so i have an idea for a workaround ...
>
> Is open a session using createwinstation api ... in that session, create multiples desktops, using createdesktop api, in each desktop will be secure shell replacement, ejecuted using x user credentials (runas) ... the printing is gonna be universal virtual printers that receive the buffer from the win32, and send the emf or pdf to the client ...
>
Hi Jan & Gonzalo,
I'm no expert in this particular area, but don't You think it would be
more logical
to give each remote a winstation, and not just a desktop on a shared
winstation ?
Best Regards
// Love
Hi Developers, I have been aproached by a certain Gonzalo from Colombia, he claims to be a developer who wants to make a Terminal Server Clone, I enclose the mail he sent me, please have a look at it and answer him.
Yours Sincerely,
Jaix Bly
>>>
Hey Jaix, i'm Gonzalo from Colombia (South America) tecnologia(a)slmsistemas.net
I'm a coder, i develop more than 500 utils and apps for terminal server and citrix .... i have a product called Galeon that is a "clon" of terminal server with shell replacement, full duplex sound, universal printer driver, etc ...
I want to develop a Open Source Terminal Server based in something like VNC and OpenVPN
Opening many sessions in windows is really bad idea ... for kernel stuff and another csrss, smss problems ... terminal server blue screen, black screen, printers, etc ... so i have an idea for a workaround ...
Is open a session using createwinstation api ... in that session, create multiples desktops, using createdesktop api, in each desktop will be secure shell replacement, ejecuted using x user credentials (runas) ... the printing is gonna be universal virtual printers that receive the buffer from the win32, and send the emf or pdf to the client ...
Using Virtual Channels is a pain in the ass ... because they all travel using only one tcp socket ... (really bad idea) so, problems with video, audio, performance, etc ...i think we can use openvpn to connect to only one port (443 to ssl vpn) and after the vpn is connected, we can open many socket (each service) between the client and the server desktop ... so we can send printing, sound, video, etc ...
I have many things already developed ... createwinstation, createdesktop, impersonate users, universal printer, openvpn implementation .. etc ... but i need help in other areas, like the video grabber in the desktop (maybe a modified vnc) i can make a printscreen of each desktop, and send the jpg ... and is working, but is a really bad idea ...
This product can merge with ReactOS .. and be the ReactOS terminal server ...
https://sourceforge.net/projects/oswts/
What do you think?
Do you receive this mail?
Thanks,
Gonzalo.
--
Cordialmente:
Ing. Gonzalo Araujo C
MCSE, MCSA, MCSD, ITIL, CISSP, C|EH, LPI
Desarrollo SLM Sistemas Ltda
desarrollo(a)slmsistemas.com
tecnologia(a)slmsistemas.net
http://www.slmsistemas.com
Colombia - Guatemala - Chile - Venezuela
<<<
Hello! I already have almost latest trunk build of ReactOS installed.
Now I want to try
modifying some sources, but recompiling whole system takes about 8 hours
on my
very slow PC. How can I recompile only modified part of the system?
I am using RosBE for Linux version 1.5.
Hello,
as you all know we have quite a lot of regressions recently, and
recently they only add up to one another causing annoyances of
testers and developers. There is a strong need to change this
situation as soon as possible, otherwise the project's future is
undetermined.
I want to propose a step-by-step approach. Our brave testing team has
created a good overview of the most important regressions and bugs we
have so far: http://www.reactos.org/wiki/Buglist .
Now, very important(!):
For the first step I would like ALL developers to drop their current
ReactOS-related work, including all work in branches or wherever else
and focus ONLY on fixing regressions from that list. The goal is to
fix all confirmed regressions that have been introduced, starting
from the most recent and going down to the most ancient. All possible
ways to remove a regression could be used: starting from a proper fix
and finishing with a total revert or commenting out even good code.
Process coordination: feel free to commit proper fixes right away,
however as for reverts, I, and/or comittee of our core devs, would
like to have a final say on whether something should be reverted.
I repeat, all other non-regression related commits to the official
ReactOS SVN repository are forbidden, even to branches. The only
exception may be developers whose access is restricted to branches
only.
Thank you for understanding,
Aleksey Bragin.