Re: wrc/parser.y
Yes, the '-L' option is very useful when you are compiling 'real' win32-developed code that has just been checked out from a version control system that is case insensitive for file names onto your disk published as an SMB share. Also, certain compiler suites seem to do case insensitive filename matching by default, just for backward compatibility reasons AFAICT. :) So, reworking the option to mean 'includes are case-insensitive' would probably be a good idea. Do we have any volunteers? Albert. Francois Gouget wrote: > > On Mon, 11 Sep 2000, Jeremy White wrote: > > > In make_filename() converts the filename to lowercase, > > with the comment: > > /* Convert to lower case. Seems to be reasonable to do */ > > > > And yet, it seems to me to be unreasonable to do so > > (I have a case of including res/Toolbar.bmp that fails). > >I found a '-L' option that disables this behavior. I guess the idea > would be to systematically use it as part of the wrc flags. I certainly > do. >Now, is this lowercasing functionality really needed in wrc? > Especially in its current form: why should we suppose that the filename > has been lowercased? I guess I would much prefer to see this as a > 'includes are case-insensitive' option. >So is it really needed? When wrc is used outside of Wine? > > -- > Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ > RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt > IP over Avian Carriers with Quality of Service -- Albert den Haan, Lead Developer @ Linux Port Team . Corel Corporation [EMAIL PROTECTED] x 5318 -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
Re: Generating patches from commit logs
/com/esolutions/mdl/dbaccess/AbstractUpdater.java > 1.8 +4 -2 > evolve-client/com/esolutions/mdl/dbaccess/ClientUpdater.java > 1.9 +88 -125 > evolve-client/com/esolutions/mdl/logger/CreateLog_XML.java > 1.4 +7 -7 evolve-client/com/esolutions/mdl/logger/LogRecord.java > 1.7 +23 -20 evolve-client/com/esolutions/mdl/logger/UpdateLog.java > > > Now, my mailer may have wrapped some lines, but you > get the idea... > > My questions are: > -- do you guys agree that it would be cool to have > such a thing for the Wine repository > -- if so, what would it take to implement these > features in our repository > > -- > Dimi. -- Albert den Haan, Lead Developer @ Linux Port Team . Corel Corporation [EMAIL PROTECTED] x 5318 -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
Re: Remaning Dlls
We (Corel) ducked this issue by installing our .so's and .dll's to nonstandard
directories to we couldn't trample a wine-hq installation if
on existed (or arrived later).
This has the joyous side effect of hiding the version skew between the corelwine's
released with WPO2000 and DRAW.
Check out our DRAW and Paint launching shell script (/usr/bin/* files are symlinks to
it) for where we prefix LD_LIBRARY_PATH to point to the proper library directory.
This allowed us to stick with the cannonical names (I hate to waste your work so
far!:) and co-exist with other wine installations.
Albert.
> Michael Cardenas wrote:
>
> Hello again.
>
> I'm working on renaming our versions of the wine libs, so that the corel and
>deneba installations do not break each other. My question is, what is the right way
>to do this?
>
> I have been working for a week on changing shell32.dll to cv7shell32.dl, or
>really changing libshell32.so to libcv7shell23.so
>
> I did it by doing the following:
> 1. changing the directory name from shell32 to cv7shell32
> 2. modifying the following files to refer to cv7shell32
> /wine/Makefile.in
> /wine/dlls/Makefile.in
> /wine/dlls/cv7shell32/Makefile.in
> /wine/dlls/cv7shell32/shell32.spec
> /wine/configure
> (applicationDir)/.winerc
> 3. changing all attempts to LoadLibrary("shell32.dll") to
>LoadLibrary("cv7shell32.dll")
>
> but it still didn't work! Not only did the library not get loaded, but other
>libraries also did not load after changing the name of the lib.
>
> I suspect this is going to be a problem for anyone else who is going to make
>winelib applications. I think it's so common that we should have a configure option
>for it.
Our "configure option" is to build the libraries into an out-of-the-way place. Look
at the existing --prefix option of configure. IIRC we used
--prefix=/usr/lib/corel/wine-$application. In the
future we will use --prefix=/opt/corel instead to match the latest version of the file
system standard.
Another potential gotcha is the location and name of the .winerc file and the .wine
directory. Alexandre seems to have some ideas on how to evolve Wine-hq beyond the
current two environment variable
approach (WINEPREFIX and WINE_INI) to have the .winerc reside *in* the .wine directory
so one environment variable can indicate what configuration to use.
I hope that any evolution could include a two location approach so that we can have a
master winerc file somewhere visible to all that users could override in their .wine
directories if they wanted.
I might end up coding this RSN before Alexandre gets it right in a way that will be
hard for us to migrate to :)
> What are your thoughts or suggestions on this? Any help would be greatly
>appreciated.
>
> Thank You,
> Michael Cardenas
> Deneba Software
Let's work together on this one too!
--
Albert den Haan, Lead Developer @ Linux Port Team . Corel Corporation
[EMAIL PROTECTED]
--
The address in the headers is not the poster's real email address. Do not send
private mail to the poster using your mailer's "reply" feature. CC's of mail
to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]".
The poster's email address is "[EMAIL PROTECTED]".
Possible typo in server/registry.c
>From my meager understanding of this patch some inline constants were moved into >constant arrays. But 'H','A','R','D','W','A','R','E','P','R','O','F','I',' seems to have warped into HardwardProfiles Is this a typing error or really supposed to be this way? Albert. -- Albert den Haan, Lead Developer @ Linux Port Team . Corel Corporation [EMAIL PROTECTED] x 5318 Index: server/registry.c === RCS file: /home/wine/wine/server/registry.c,v retrieving revision 1.21 diff -u -w -r1.21 registry.c --- server/registry.c 2000/08/26 04:40:07 1.21 +++ server/registry.c 2000/08/28 15:33:38 @@ -85,7 +85,7 @@ "Machine", /* HKEY_LOCAL_MACHINE */ "User", /* HKEY_USERS */ "PerfData", /* HKEY_PERFORMANCE_DATA */ -"Machine\\System\\CurrentControlSet\\HardwardProfiles\\Current", /* HKEY_CURRENT_CONFIG */ +"Machine\\System\\CurrentControlSet\\HardwareProfiles\\Current", /* +HKEY_CURRENT_CONFIG */ "DynData"/* HKEY_DYN_DATA */ }; -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
Re: Code page stuff is broken
Dmitry Timoshkov wrote: > Of course, I can :-). ExtTextOutA at wine/objects/text.c takes non-unicode > text and translates it to unicode using wrong code page. That's all. > The used code page will be always wrong, if currently selected font will have > another code page rather then current ANSI code page. Theoretically, the system > could have fonts with three different code pages: ANSI, OEM, MAC. I have even more > in addition to the mentioned ones: iso8859-1, iso8859-5, koi8-r, symbol. In my case > ANSI = 1251, OEM = 866, MAC = 10007. So, the question: Can the fonts with the > different code pages easy break everything?! Oh yes! Try using a symbol font like "-adobe-symbol-medium-r-normal--14-140-75-75-p-85-adobe-fontspecific" and scanning GetTextExtentPoint calls through it from FirstChar to LastChar. WordPerfect likes to do this every time the user selects a new font and wine crashes in X11DRV_GetTextExtentPoint on a pointer lookup of the "translated" character encoding determined by MultiByteToWideChar. I figure the following fixme is a symptom of my problem: fixme:string:MultiByteToWideChar MB_COMPOSITE not supported and here is the code in graphics/x11drv/text.c that is abused by the "mapping": 413 x += pfo->fs->per_char ? 414pfo->fs->per_char[str[i] - pfo->fs->min_char_or_byte2].attributes : 415pfo->fs->min_bounds.attributes; > >Maybe the problem is that we should always try to use the right font > >charset for the current codepage unless specified explicitly? Would a > >patch like this improve the situation? > > Unfortunately, the problem persist. Same here. Do we properly track if the X font says its encoding is fontspecific? (this is new stuff for me..) -- Albert den Haan, Lead Developer @ Linux Port Team . Corel Corporation [EMAIL PROTECTED] x 5318 -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
Critical section tracking tool.
This Wine critical section tracking patch is based on a patch Jeremy White (of
CodeWeavers) wrote for the Corel branch back in February. I have warped and extended
if for the current WineHq head
revision.
The WineHQ head revision seems to use a LOT more critsects than the current Corel
branch I had to boost the number of statically allocated slots by 100 to track
WordPerfect properly.
I stuck a few of the RegisterDebugptr() calls in somewhat arbitrary places when I
could not find a call to InitializeCriticalSection() for some critsects (e.g.
X11Drv!). They seem to be the right
places for now.
The original patch still exists in the Corel branch because it is not doing us any
harm. I'm copying this message to .devel because critsect developers my find this as
useful as we did.
Albert.
Changelog:
Albert den Haan <[EMAIL PROTECTED]>
Jeremy White
Record and display additional information related
to critical sections. It should help track down the cause of
critical section deadlocks.
--
Albert den Haan, Lead Developer @ Linux Port Team . Corel Corporation
[EMAIL PROTECTED] x 5318
CritSectDebugAid.patch
documentation/patches.sgml (was: Re: Dinput Mouse)
Someday we will actually write the contents for the wine/documentation/patches.sgml file and this question will be easier to answer :) Here is some draft content for the file that I would add if only I felt I were competent in SGML: Amend away folks! Patch Format Your patch should include: * a description of what was wrong and what is now better (and now broken :). * your contact information ( Name|Handle and e-mail ) * the patch in "diff -u" format (it happens...) "cvs diff -u" works great for the common case where a file is edited. However, if you add or remove a file cvs diff will not report that correctly so make sure you explicitly take care of this rare case. For additions: mention that you have some new files and include them as either separate attachments or by appending "diff -Nu"s of them to any "cvs diff -u" output you may have. For removals, list the files. Quality Assurance = (Or, "How do I get Alexandre to apply my patch quickly so I can build on it and it will not go stale?") Make sure your patch applies to the current CVS head revisions. If a bunch of patches are commited to CVS that may affect whether your patch will apply cleanly then verify that your patch does apply! Cvs update is your friend! Save yourself some embarasment and run your patched code against more than just your current test example. Experience will tell you how much effort to apply here. Albert. "Dimitrie O. Paun" wrote: > > From: "Tod Schmidt" <[EMAIL PROTECTED]> > > > And as a second thought what is the best way to generate patches for this > list, is this okay? > > Unified diff (cvs diff -u) is preferred. Just add > > diff -u > > to your ~/.cvsrc file. > > -- > Dimi. -- Albert den Haan, Lead Developer @ Linux Port Team . Corel Corporation [EMAIL PROTECTED] x 5318 -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
Re: RFC: New wine command line option nneded
Uwe Bonnes wrote: > > Hallo, > > my last message: > Re: Don't double quote in build_commandline (fwd) > was meant as a RFC and layed out how I think the command line should > be handled. > > In short, it means that I need a mean to know if wine was started by > Createprocess() with an argv Array created by the starting windows > executable or by the Unix user from the commandline where much more > checking and changing on the delivered arguments has to be done. > > Is this acceptable? > > Any idea for the name? -- argvchecked? --wine-called? > > Anyway: the user shouldn't need that option, only the processing after > Createprocess() should add it and the processing after main() should > act accordingly. > > Bye > > Uwe Bonnes[EMAIL PROTECTED] > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > - Tel. 06151 162516 Fax. 06151 164321 -- For WordPerfect Office 2000 and CorelDRAW we found that we had enough other preconditions to set up that we used a launching script to invoke wine instead of enhancing Wine much to handle these cases. However, I don't know how much Createprocess() stuff is happening in those applications. It seems to work however often it happens :) We have encountered this tension between allowing the user to specify Unix style paths vs. DOS drive mapped paths. I want to get away from it as soon as possible because it is a *mess*. Yes, most of our applications are crippled from birth into understanding only DOS names, but forcing users to figure out drive letters for their UNIX file structures is not a friendly thing to do. How far away are we from detecting and mapping SMB share names[1] from the command line? I am not looking forward to typing in those verbatim: 'Was it filesrv\\albertd or "\\filesrv\albertd" or "SMB://filesrv/albertd"?' That said, maybe "--mapped-to-dos-already" is what you want for the option name? Albert. [1] what is the name for the "\\*\*" notation again? -- Albert den Haan, Lead Developer @ Linux Port Team . Corel Corporation [EMAIL PROTECTED] x 5318 -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
Re: Regression testing and winapi_test
Patrik Stridvall wrote: > > > Hello Patrick: > > > > You recently wrote on wine-devle about your "condensing-ware" > > winapi_test project. > > Yes. I have being otherwise occupied again, so I haven't worked > much on it lately. It works but it it currently such a gross hack > that I haven't released it yet. It works to some extent though. That's life... > > Is there room in this thing for arbitrary regression tests > > too? > > Yes, it is generalized. What should be tested is totally separate > from the generation of the actual test application, which in turn > is separate from the analysis of the test. > > I currently only have an all pointer (NULL, NOACCESS, READWRITE, > READWRITE) test, but writting more tests is easy. I'll have to look at the code to see what you mean... :) > > We are working my way through the semi-annual Corel > > mega merge and would like some way of verifying that the bugs > > we (Corel and > > WineHQ) have fixed stay fixed. > > OK. Then you need to test between different versions of Wine for > which support is planned but not yet implemented. The only things > that is currently implemented is testing between builtin and native. > > It shouldn't be that hard to do, except for the problem is having more > than one version of Wine installed at the same time since I run the > both tests in parallell. > > Hmm. I guess I could do some tricks with LD_LIBRARY_PATH. Of course > Corel Wine's (libwine.so) is not binary compatible with the current > version of Wine so that won't work either. We are working to change this (we are trying to merge after all) > Hmm again. What we could do is compile the generate WineLib application > once for Corel Wine and once for the current Wine. This means that the > libwine.so and friends must reside in different directory or something. > Perhaps static linking is the answer. > > Wait a minute. What does the Corel Linux distribution do? > IIRC is possible to have both Corel Wine and Wine installed > at the same time. Or is that just a gross hack that is Corel > Office specific? We have munged the configure scripts to install our versions of wine whereever we want so a generic install will not be smashed installing a Corel application. Some people we know would be unhappy about that sort of thing... In fact we chose to have a separate version of wine per application because we could not assure that the new version of wine for CorelDRAW! would work well with the previous WordPerfect Office release. There is room for sharing a version of WINE between applications, but we have some work to do before we will get to that point. > I will see if I find time to make a prerelease of winapi_test > later today. At least something useful currently works, > eventhough it still is a gross hack (slow and bloated). I have seen the post, I will look at it RSN. Albert. -- Albert den Haan, Lead Developer @ Linux Port Team . Corel Corporation [EMAIL PROTECTED] x 5318 -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
Regression testing and winapi_test
Hello Patrick: You recently wrote on wine-devle about your "condensing-ware" winapi_test project. Is there room in this thing for arbitrary regression tests too? We are working my way through the semi-annual Corel mega merge and would like some way of verifying that the bugs we (Corel and WineHQ) have fixed stay fixed. Albert. Patrik Stridvall wrote: > > I have finally found time working on my "vapourware" > project winapi_test. It will be released soon :-). > > However I have run into some problems which, eventhough > I have been able to work around it, should be fixed. > > winapi_test is a WineLib application and if I in Perl do: > > open(IN_NATIVE, "winapi_test --dll $module1632=n -- --module=$module 2>&1 > |"); > open(IN_BUILTIN, "winapi_test --dll $module1632=b -- --module=$module 2>&1 > |"); > > the second winapi_test will fail and say that the wineserver is already > running. > However if I delay the second open until the first open produces any output > indicating that the wineserver must be running the second winapi_test will > work > and they will both run simultaneous without any problem. > > So given the what happens and reading the source code I think it is > clear that it is a race in the starting of the wineserver. > > However I'm not sure how to fix it. Please advise (or please fix it :-). -- Albert den Haan, Lead Developer @ Linux Port Team . Corel Corporation [EMAIL PROTECTED] x 5318 -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
Re: [Q] compiling mfc application with winelib
Many, many moons ago (Last summer?) I wrote the documentation to do this for the single (dll|.a) linkage setup we had then. In summary it had a new .so and winestub file that used a globally declared C++ object (in the .so) to call the MAIN_WineLib_Init(sp?) function in its constructor. We then made sure to link the .so file as the last object on the gcc command line because the global objects are constructed first for that .so. This worked. We were not proud of it but we couldn't find an alternative that would happen before the globally declared objects in the main program (and its statically linked libraries e.g. MFC) would start calling WIN32 functions in their constructors. Has a better solution for this problem been found? I can dredge up the patch again from an old CVS repository if it is still wanted but I suspect it is way out of date... Albert. Andreas Mohr wrote: > > On Tue, May 30, 2000 at 08:39:24AM -0700, Damyan Ognyanoff wrote: > > [...] > > I sugest you to write your app as a .so lib and to > > write a small loader. which can perform additional > > LoadLibrary'c in it's WinMain routine to load MFC and > > your app. > > > > I follow this techique and manage to run a program > > that use a MFC. > Cool, fine, good, [whatever]. > > Could you please begin to write some sort of Winelib HOWTO to be added > to the Wine documentation/ dir ? > Or somebody else maybe... > > We definitely need this now that Winelib is starting to become > A Useful Thing (tm). > > Andreas Mohr -- Albert den Haan, Lead Developer @ Linux Port Team . Corel Corporation [EMAIL PROTECTED] x 5318 -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
Re: PrgWin95: Extern and #pragma/#line/#error support
I just caught up with this discussion after taking some time off for
packaging Corel's next opus. I agree with the idea that trival
piplineing a preprocessor into wrc will not leave enough information for
totally accurate error messages.
However: If the resource compiler understood the "#line
" directives dumped inline by the preprocessor then
the line numbers would be accurate (or at least as accurate as gcc's :)
Intra line locations are always a problem however tightly you integrate
the preprocessor to the syntax checker/interpreter because the
preprocessor _changes_ the line (this is the whole point after all :)
and an arbitrary decision must be made which of the various generations
of the line should be displayed.
The source text is trivially available as source (given the line
number), and the compiler has the result of the preprocessing. The
nested macro substitutions are useless in a practical sense and hard to
store and retrieve anyway. Yes, code analysis tools sometimes do track
all of these intermediate calculations (usually not to the limits I have
implied) but we are not writing a code analysis too (yet).
I too say its past time to rip out the cpp stuff in wrc to make its
grammar smaller and much less complicated. However
#pragma/#line/#error support must be added as part of this.
At part of this work I suggest that we add --pedantic option to whine
when the resource compiler notices that it has C or C++ code in its
input. Declaring prototypes and structures without "#ifndef RC_INVOKED"
guard lines is sloppy coding and forces the tool to be kludged to
explicitly ignore such code. We had mondo trouble with C++ extensions
to the C grammar (and MS extensions to that) when we tried native
compilation and it could have been avoided with a bit of discipline.
Thank you :)
Albert.
Patrik Stridvall wrote:
>
> > > > Fortunately, standard cpp
> > > > seems to be enough, but if we were to require GNU cpp, what
> > > > would be the (real) problem???
> > >
> > > It is not a real problem but I prefer to minmize the depencies
> > > whenever possible. You have heard the story about
> > > "The straw that broke the {ass,donkey,mule}'s back", haven't you?
> >
> > OK, I did not say it explicitly, but the discussion was a matter of
> > principle only since standard cpp works. I agree with you
> > about unnecessary
> > deps. But to my mind, if a tools helps wine be better
> > (cleaner, faster,
> > etc), I opt to use it rather than complain about the
> > dependency. I was just
> > curios about your stand on this matter.
>
> Well, there is not only the matter of a dependency.
> Even though one important thing about Unix is
> "plumbing" a lot of simple tools, it is not always
> goods to do so.
>
> In this case with cpp and wrc, plumbing them together
> makes the error messages more cryptic which is not
> good.
>
> > > Anyway, I have do some experimentation and I found out that
> > > this simple patch implements a pre wrc call to the C preprocessor.
> > > Works with both Solaris C/CPP and GNU C/CPP.
> >
> > That's good news -- let's use that then and make wrc smaller,
> > and faster.
>
> I am not sure that stripping out the preprocessing code is a good idea.
> I see it more as temporary solution until wrc has implemented better
> preprocessor handling. As I said plumbing two tools together
> often gives more cryptic error messages. That is the reason
> why many C compilers and code analysis tools handles preprocessor
> directive by itself rather than using an external tool.
> IMHO wrc should do so as well.
>
> The patch is more a proof of concept, I am not suggesting
> that is should be applied, eventhough Alexandre is of course
> welcome to do so if he so whishes.
--
Albert den Haan, Lead Developer @ Linux Port Team . Corel Corporation
[EMAIL PROTECTED]
--
Corel has something new for you! Subscribe to our e-newsletter and
learn what's new and happening at Corel! Subscribe at
http://www.corel.com/newsletter
--
The address in the headers is not the poster's real email address. Do not send
private mail to the poster using your mailer's "reply" feature. CC's of mail
to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]".
The poster's email address is "[EMAIL PROTECTED]".
Re: fake builtin DLL file open
Err I hate to break some assumptions here but there is one spectacular difference between Wine's Registry and a Windows Registry. Wine's registry is stored per user Windows registry is stored per machine. The following example will show some of the ramifications of this accident of Wine's current implementation. A common setup in schools (elementary through university level) is a computer lab where people can log on to any machine and their home directory is mounted from a file server. In this situation the machine name in the registry should _not_ be constant because they may be logged in to machine foo one hour and bar the next. This suggests that the registry storage could be split up yet further to handle machine specific and static entries. GACK. The .winerc file (or our per Corel application version) suffers from the same problems because mount points are not reuired to be common across machines or even distributions :( Albert. Andreas Mohr wrote: > > On Wed, Mar 01, 2000 at 05:20:53PM -0800, Alexandre Julliard wrote: > > Andreas Mohr <[EMAIL PROTECTED]> writes: > > > > > Well, just what I said: > > > E.g. query the host name. > > > I just saw before that the registry automatically queries the host name > > > and saves it (upon every startup !). > > > > Well, yes, that's exactly the right thing to do. Were you suggesting > > to get the host name once and save it in the registry forever? That > > would be pretty broken IMO. > Exactly. > Just as on Windows. > You know that little part where Windows setup asks for the computer name ? > That's where it gets stored *once*. > And as we have SetComputerNameA, we should store it once, too, I think. > > Or maybe not ? > What do you think ? > > Well, at least SetComputerNameA has to store it in the registry, too > (it doesn't). > And GetComputerNameA has to retrieve the registry value, not call > gethostname(). > > Andreas Mohr -- Albert den Haan, Lead Developer @ Linux Port Team . Corel Corporation [EMAIL PROTECTED] x 5318 -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
