Am 16.06.2010 11:37, schrieb Alexandre Julliard:
Markus Amsler writes:
+ * Windows checks the following conditions before emulating an ATL thunk:
+ * - DEP policy allows emulating
+ * - thunk has memory type MEM_PRIVATE and is readable
+ * - jmp func is executable
+ * - thunk
not a problem. But the situation is different in the context of a signal
handler because of the limited set of async-signal-safe functions.
Regards,
Markus
smime.p7s
Description: S/MIME Cryptographic Signature
are for complete async-signal-safety.
> You'll have to come up with something that prints the same
This will not happen at the moment because of conflicting expectations.
> or don't touch it.
I assume that the involved implementation details will be reconsidered some day
this
value could be larger than registry may tell.
For that reason I ask if someone could run the attached testcase in an
native environment and could tell me if he can see a difference between
the result and the registry.
Thanks in advance.
Markus
--- a/dlls/msacm32/tests/msacm.c
+++ b/dlls/ms
According to Stefans suggestion I have implemented a test for the string
copies into the identifier structure. Test is designed to fail to give
me a hint what is going on. Hopefully someone can post the results of a
test run in native environment.
Thank you
diff --git a/dlls/ddraw/tests/ddrawmodes
Thanks to Dimitry I have changed the test. Maybe someone could check if
the attached one works in native while it fails in my Wine environment.
Thanks a lot in advance.
Markus
diff --git a/dlls/ddraw/tests/visual.c b/dlls/ddraw/tests/visual.c
index 450d231..650f4ba 100644
--- a/dlls/ddraw/tests
Am Montag, den 12.10.2009, 02:01 +0900 schrieb Dmitry Timoshkov:
> I have compiled the test alone and it fails here:
>
> ddrawmodes.c:37: Test failed: DDDEVICEIDENTIFIER2 too large (misaligned)
>
> It's natural that the structure is 8-byte aligned since it has a
> 64-bit member (LARGE_INTEGER). d
Am Sonntag, den 11.10.2009, 18:04 +0200 schrieb Stefan Dösinger:
> Am 11.10.2009 um 17:44 schrieb Markus Stockhausen:
>
> >
> >
> Did you compile this test with MSVC and the Microsoft headers on
> Windows?
>
I'm sorry but I have no Windows environment. Only Linux/GCC.
Am Sonntag, den 11.10.2009, 17:15 +0200 schrieb Stefan Dösinger:
> Does a pragma pack fix the issue? If yes, then that's probably the
> correct fix.
>
> Its probably worth writing a test that allocates e.g. a char data[64],
> then passes this to GetDeviceIdentifier, fill it with non-zero data,
Am Sonntag, den 11.10.2009, 13:18 +0200 schrieb Markus Stockhausen:
> Then I'm somehow in trouble. How can one explain the following
> error: Application calls IDirectDraw GetDeviceIdentifier of
> DDRAW7 but only reserves memory with sizeof(DDEVICEIDENTIFIER)
>
. How can one explain the following
error: Application calls IDirectDraw GetDeviceIdentifier of
DDRAW7 but only reserves memory with sizeof(DDEVICEIDENTIFIER)
instead of sizeof(DDEVICEIDENTIFIER2) bytes. Wine returns the
required structure but with the contents of dwWHQLLevel
stack contents are overwritten.
Markus
Am Sonntag, den 11.10.2009, 12:40 +0200 schrieb Markus Stockhausen:
> Hi,
>
> as I did not find anything in the Wiki maybe a stupid question: If I
> want an application to use DDRAW4 functions in Wine instead of DDRAW7,
> how can I accomplish that?
>
> Thanks in advanc
Hi,
as I did not find anything in the Wiki maybe a stupid question: If I
want an application to use DDRAW4 functions in Wine instead of DDRAW7,
how can I accomplish that?
Thanks in advance.
Markus
Am Freitag, den 09.10.2009, 15:44 +0200 schrieb Alexandre Julliard:
> If the test case is based on observing internal behavior that's not
> acceptable either. Even if someone else fixes it, the test would force
> the fixer to replicate internal details.
>
Hi,
I can see all of your concerns and t
use
of the just freed small memory portion can occur.
Markus
Am Freitag, den 09.10.2009, 14:15 +0200 schrieb Paul Vriens:
> If that sz99 (or now sz128) came from "looking at internal behaviour",
> I'm not sure if that would raise some eyebrows.
>
As I said "looking at internal behaviour" are debugging messages in the
IMalloc routines of ifs.c. Simply som
Am Freitag, den 09.10.2009, 13:43 +0200 schrieb Paul Vriens:
> Hi Markus,
>
> Isn't there a way that you can change the tests to show this number (in
> some kind of loop by creating a larger second string on the go)?
>
It simply boils down to this one and only testcase.
ort: This will ensure that oleaut will
allocate new memory instead of reusing its caches.
Markus
Am Freitag, den 09.10.2009, 09:56 +0200 schrieb Paul Vriens:
> On 10/09/2009 09:38 AM, Markus Stockhausen wrote:
> > Am Freitag, den 09.10.2009, 00:27 -0700 schrieb Dan Kegel:
> >> Hi Markus,
> >> Wine development is driven by test cases checked in to the
> >>
Am Freitag, den 09.10.2009, 00:27 -0700 schrieb Dan Kegel:
> Hi Markus,
> Wine development is driven by test cases checked in to the
> Wine source tree. Please extend the test cases in
> dlls/oleaut32/tests to verify that oleaut32 is caching BSTRs
> properly, and make sure that
> You should not be looking at the internal behavior of native, only at
> the external behavior as observed through test cases.
>
Hm,
I know, that
testcase
-> windows oleaut
-> wine ifs.c IMalloc logging
is quite strange testing. Sadly this was the only way to explore the
reason for not
Am Donnerstag, den 08.10.2009, 18:26 +0400 schrieb Nikolay Sivov:
> Markus Stockhausen wrote:
> > Hi,
> >
> > the last week I took some time to implement the first try of BSTR
> > caching in oleaut.c. On the one hand this will fix a bug, on the other
> > hand Wi
Additionally it reduces the time for Dealloc/Alloc Cycles of BSTR memory
in best cases by about 50%.
Best regards.
Markus
the task of how to write a testcase
for this change.
Thanks for your help.
Markus
--- git/dlls/oleaut32/oleaut.c 2009-09-23 18:24:47.0 +0200
+++ wine/dlls/oleaut32/oleaut.c 2009-10-08 14:13:13.0 +0200
@@ -39,8 +39,6 @@
WINE_DEFAULT_DEBUG_CHANNEL(ole);
-static BOOL BST
a testcase and hope it shows the expected behaviour - at
least it fails in my Wine git. Hopefully we can collect the results of
all Windows versions (including 7).
Markus
--- git/dlls/oleaut32/tests/vartest.c 2009-09-20 18:07:17.0 +0200
+++ wine/dlls/oleaut32/tests/vartest.c 2009-10-02 13:4
course this behaviour is far away from the oleaut implementation and
will consume some more CPU cycles.
Thanks for your feedback in inadvance.
Markus
Am Dienstag, den 29.09.2009, 15:10 +0200 schrieb Paul Vriens:
> On 09/29/2009 03:01 PM, Markus Stockhausen wrote:
> >
> >
> > ----
> >
> >
> Hi Markus,
>
> Please stick to the
Am Dienstag, den 29.09.2009, 13:42 +0200 schrieb Paul Vriens:
> Hi Markus,
>
> On fully up-to-date Windows XP Professional SP3:
>
> dsurface.c:1262: Test failed: backbuffer surface has dwBackBufferCount==0
>
>
Thanks to Jeff and Paul for your cross checks. The result make
ace.c:1264: Test failed: backbuffer surface has
dwBackBufferCount==2
Thanks for your help in advance.
Markus
--- git/dlls/ddraw/tests/dsurface.c 2009-09-20 18:07:17.0 +0200
+++ wine/dlls/ddraw/tests/dsurface.c 2009-09-29 13:11:47.0 +0200
@@ -1154,9 +1154,9 @@
HRESU
Am Freitag, den 18.09.2009, 14:09 +0200 schrieb Paul Vriens:
> On 09/18/2009 01:42 PM, Markus Stockhausen wrote:
> > Hi,
> >
> > as I was encouraged to resent the patch from last week in git format I
> > hope it will be better this
Am Freitag, den 18.09.2009, 14:20 +0400 schrieb Nikolay Sivov:
> Markus Stockhausen wrote:
> > Hi,
> >
> > attached you will find a new testcase that checks for differences
> > between Wine and Windows when handling reference counters for nested
> > stora
Hi,
as I'm still working on a resolution to bug #9575 I have digged into
several directions. My current opinion is that IStorage_CreateStorage
for some unkown reason increments the reference pointer of the
associated IStorage object. In native Windows this is not the case.
My 37th try in writing
Am Samstag, den 12.09.2009, 16:50 +0200 schrieb Paul Vriens:
> On 09/12/2009 04:13 PM, Markus Stockhausen wrote:
> > Am Samstag, den 12.09.2009, 15:52 +0200 schrieb Markus Stockhausen:
> >> Hi,
> >>
> >> hopefully the right explanation for the error can be fo
Am Samstag, den 12.09.2009, 15:52 +0200 schrieb Markus Stockhausen:
> Hi,
>
> hopefully the right explanation for the error can be found here
> http://bugs.winehq.org/show_bug.cgi?id=9575 . Once again I need someone
> with a Windows machine who can provide the following:
>
penStorage( 'testfile.txt', ... , ppstgOpen2 );
I expect *ppstgOpen2 not to be NULL in Windows while being NULL under
Wine.
Best regards.
Markus
Sorry for the the wrong feedback.
As I have limited possibilites creating executables on Windows I relied
on Thomas executable for the tests. Maybe you can post a corrected
version.
It is not my intention to confuse someone. Im just trying to narrow down
my initial analysis. The last write access
Am Samstag, den 12.09.2009, 01:39 +0200 schrieb Thomas Trummer:
> Actually, forget about the password and give the file without
> extension a .exe extension...
>
> 2009/9/12 Thomas Trummer
> pw: wine
>
> 2009/9/
( 'testfile.txt', ..., dwShareMode = 0, ...)
Return the result of second call. I expect it to be a valid handle on
Windows whereas Wine will return an invalid handle.
Thanks in advance.
Markus
( 'testfile.txt', ..., dwShareMode = 0, ...)
Return the result of second call. I expect it to be a valid handle on
Windows whereas Wine will return an invalid handle.
Thanks in advance.
Markus
Am Freitag, den 11.09.2009, 09:04 +0200 schrieb Paul Vriens:
> Hi Markus,
>
> One I see is a style issue with the if statement. There shouldn't be a
> space after the opening and before the closing bracket.
>
> Another thing (style again) is that maybe it's nicer t
Am Freitag, den 11.09.2009, 01:56 +0400 schrieb Nikolay Sivov:
> Just correct your patch (as you mentioned before), include simple
> testcase and resend.
> So nothing to wait for.
>
> Basic test shows it doesn't crash on Windows and doesn't change last
> error - I already
> check this on XP and
be made.
> >
> > Roderick
> >
> > On Thu, Sep 10, 2009 at 10:56 PM, Markus Stockhausen
> > wrote:
> >
> >> Hi,
> >>
> >> http://bugs.winehq.org/show_bug.cgi?id=18041 reveals a bug where
> >> GdiAlphaBlend will crash in Teamv
framebuffer but that fails with
> libGL error: drmMap of framebuffer failed (Cannot allocate memory)
Markus
On Monday 12 January 2009 11:50:27 Vitaliy Margolen wrote:
> Markus wrote:
> > +V_VT(&v) = VT_BOOL; V_BOOL(&v) = get_ddraw_acceleration();
> > +IDxDiagContainerImpl_AddProp( pDisplayAdapterSubCont,
> > b3DAccelerationEnabled, &v ); +VariantClear(&v)
native dll would determine that
b3DAccelerationExists was supposed to be false. The only result I got in that
regard was that by setting caps->DevCaps to 0, a human readable warning about
missing D3d9+ hardware acceleration would be added to szNotesLocalized.
Does anyone have an idea on what else could be the basis for this flag?
--
Markus
On Tuesday 06 January 2009 03:58:27 Detlef Riekenberg wrote:
> On Mo, 2009-01-05 at 22:10 -0500, Markus wrote:
> > can anyone tell me where to find information about the
> > b3DAccelerationExists and b3DAccelerationEnabled properties in the
> > display container returned by
properties
returned by that dll.
Thanks,
--
Markus
diagn.
That might be a good idea as it would simplify dxdiagn development by offering
a GUI showing the retrieved values and those still missing.
--
Markus
> of fixing dxdiagn so that wic's demo starts.
If my patch above is accepted, only the two b3D properties remain to be
implemented and then WiC should start fine. I don't think that is big enough
of a project.
--
Markus
properties to the dll, at least as stubs. Without them,
there doesn't seem to be that much to retrieve and display with dxdiag.exe
Markus
On Sunday 28 December 2008 00:28:56 Dan Kegel wrote:
> Hi Markus,
> what's the status of dxdiagn these days? I see a number
> of games t
euristic doesn't help, but it won't
worsen matters either.
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
Apps written in 1996
are never ever designed to run on WinXP. It's a matter of being
conservative enough.
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
Am 20.12.2008 um 13:42 schrieb Dan Kegel:
> I updated http://wiki.winehq.org/Wine64 with a list
> of some win64 apps. There are lots more than I
> expected.
Well, Catia comes with a 64-bit flavour as well, like probably any
serious CAD or FEA package.
already installed along other
apps on a drive_c.
BTW, how would you interact between different Windows apps running on
different versions of Wine?
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
ne-devel or wine-patch?
wine-patches is for patches only, -devel is where discussions should go.
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
fortunately, they are in the uncommon ICNS format. Here's a
procedure to convert them to the PNG format:
<http://slaptijack.com/graphics-design/converting-mac-os-x-icon-files-
to-png/>
I have the "sips" tool mentioned there installed, so it's likely part
o
Am 14.11.2008 um 15:11 schrieb James Mckenzie:
> Markus:
>
> I don't think that Wine will build on MacOS 9 or earlier anymore.
>
> James McKenzie
You might remember a very similar request, just over six weeks ago:
<http://article.gmane.org/gmane.comp.emulators.wine.deve
Am 14.11.2008 um 10:15 schrieb Kai Blin:
> On Friday 14 November 2008 09:53:03 Markus Hitter wrote:
>> Am 14.11.2008 um 00:15 schrieb Austin English:
>>> Howdy,
>>>
>>> The OS list in bugzilla is a bit excessive. [...]
>>> Mac System 7
>>>
Am 14.11.2008 um 00:15 schrieb Austin English:
> Howdy,
>
> The OS list in bugzilla is a bit excessive. [...]
> Mac System 7
> Mac System 7.5
> Mac System 7.6.1
> Mac System 8.0
> Mac System 8.5
> Mac System 8.6
> Mac System 9.x
You could merge them to
ould signal the thread not the process. Have a look at [1]. That patch
once fixed all my dos input issues, although I haven't looked at this
stuff for quite some time.
I'm not sure you have the same problem, just a possible hint.
Markus
[1] http://www.winehq.org/pipermail/wine-patches/2004-November/013645.html
ith the taskbar your John Gilmore has. Unless I miss
something, there's no need to give it them, either.
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
Sorry to have no more encouraging comments.
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
de to binary
> Objective-C code?
While the above is correct, modern Cocoa, in opposite to it's
precedessor NeXTstep/OpenStep, is based on Quartz and CoreFoundation,
both of which are plain C APIs. There's no need for neither Carbon
nor Cocoa nor Objective-C to get some basic graphics to t
While on the topic, please remove Mac OS up to 10.3 from the list of
operating systems. Mac OS X 10.4.x was the first publicly available
Macintosh OS running on Intel processors, so there won't ever be
anybody running Wine on e.g. MacOS 9.
MarKus
- - - - - - - - - - - - - - - - - - -
t done today)
A reasonable 99% shortcut would probably be to parse C: only. This
should be sufficient for almost all users, especially the clueless
ones, on Wine as well as on Windows.
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
even in generic gdb?
If yes, where would I put these files or how would I load their
tables into the debugger?
Thanks,
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
linedocs/gdb_5.html
My tries to break not into the preloader, but the actual Windows
application weren't successful so far, gdb's console appears to lock
up somehow when setting follow-fork-mode & friends.
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
int()?
Short of better suggestions, I'd try to make debugger launching
independent from Peb->BeingDebugged (server/kernel should know
better), try to get rid of the interrupt in DbgBreakPoint() and/or
make debugger autolaunching optional (at compile time).
What
ALL, result);
This should ease log reading as well.
MarKus
Am 27.08.2008 um 11:27 schrieb Nikolay Sivov:
> Markus Hitter wrote:
>> if (!attr || !attr->ObjectName) return STATUS_INVALID_PARAMETER;
> Shouldn't this be splitted? It isn't safe to rely on evaluation order.
> Or is it a default compiler setting for us?
You know,
Am 27.08.2008 um 11:40 schrieb Dmitry Timoshkov:
> We all are in the same boat.
Next time, please try to speak up earlier and more clearly. Four
reviews, three patch reworks were done and about 20 messages were
written, just to find out _any_ change is not welcome.
Mar
Am 27.08.2008 um 10:14 schrieb Dmitry Timoshkov:
> "Markus Hitter" <[EMAIL PROTECTED]> wrote:
>
>> Providing the file handle allows to map
>> read/write requests to the corresponding file name.
>
> As pointed out by Alexander, you can use an appropr
the Wine development
> process.
I'd avoid recommending longer patch series.
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
t; +else
> +TRACE("returning 0x%08x\n", io->u.Status);
> return io->u.Status;
>
> Since the return is done regardless if the status, why do you trace a
> different value depending on the status?
Because *handle is val
k of it.
From e24b273d367aee0f200a0f57ddcceeac2396bf54 Mon Sep 17 00:00:00 2001
From: Markus Hitter <[EMAIL PROTECTED]>
Date: Tue, 26 Aug 2008 00:48:53 +0200
Subject: [PATCH] Fix a possible NULL dereferencing.
Spotted by James Hawkins, the variable at risk is "attr".
---
dlls/ntdll/file.c | 12 +++-
1 fi
Am 25.08.2008 um 17:58 schrieb James Hawkins:
> On Mon, Aug 25, 2008 at 3:12 AM, Markus Hitter <[EMAIL PROTECTED]>
> wrote:
>>
>> Am 25.08.2008 um 01:31 schrieb James Hawkins:
>>
>>> 2008/8/24 Markus Hitter <[EMAIL PROTECTED]>:
>&g
Am 25.08.2008 um 01:31 schrieb James Hawkins:
> 2008/8/24 Markus Hitter <[EMAIL PROTECTED]>:
>>
>
> +if (!attr || !attr->ObjectName)
> +{
> +TRACE("returning STATUS_INVALID_PARAMETER\n");
> +return STATUS_INVALID_PARAMETER;
>
;m perfectly fine if Wine people consider this process as
being effective. There's no law enforcing Wine to accept what I've sent.
> [...] or ask the community or Alexandre what the problem is.
Correct. Communication is a plus.
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
don't care to be asked more than once". Thanks to
Michael for reviewing my lines.
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
some day,
wether they were considered obsolete (they're small) or wether they
are considered as wrong in some way. Worsely, there's no obvious way
to learn how to do better as I followed the patch sending HowTo
closely already.
I'll try again in a few weeks, a
hed through unnoticed.
Good thing is, with patchwatcher we have a tool for listing open
patches now, allowing to monitor their status. At least I hope so.
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
on Mac OS X.
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
onsible for failures)
installing apps with/in Wine. Even if they allow it or help fixing
Wine bugs, this will always be a small but important niche.
my $0.02
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
ke this would be better
(pseudo-code):
if (WinVer <= XP) {
ok((!ret && [...]),
"Expected [...]);
} else {
ok((ret && [...]),
"Expected [...]);
}
Likely a often asked question, but I couldn't find hints about the
answer yet.
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
tf() statements into the
source, finding me unable to repeat the numbers seen in the tiny
backtrace above. bytesToRead obviously never has the value 0x800 (=
2048).
So my question is: How would I go and debug such an issue? Is it even
possible to set breakpoints, to get meaningful backtra
the 32-bit Linux libs installed for Wine
> to use,
> however.
I'm hunting for a few of the differences between "should" and "does"
and try to catch them with test cases. See bug #10490.
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
o add them, but it doesn't make a
difference.
I guess I'll have to set up a virtual machine running the real thing.
There are so many levels of abstraction (64-bit Ubuntu -> 32-bit app,
Linux environment -> Windows libraries, Linux build platform ->
Windows binari
Am 17.07.2008 um 00:56 schrieb Chris Robinson:
> On Wednesday 16 July 2008 03:38:37 pm Markus Hitter wrote:
>> maybe I'm just missing the obvious, but I can't get my small one-file
>> app to link. As I've just built Wine from scratch on this box,
>> every
could imagine, but
no joy. Any ideas, somebody?
Thanks,
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
d elsewhere didn't work for me.
HTH,
MarKus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
nually
improving and we expect to support even more applications in the future.
Overall, about one in four tested applications work well as of Wine 1.0. See
the Wine FAQ (http://wiki.winehq.org) for more info."
--
Markus
to depend on many factors. If I move the
camera around, it appears to freeze earlier than just letting the game run
(e.g. a replay of a match). But once the patch is excluded, the game no
longer freezes.
If more info is needed, please specify how I can obtain it.
--
Markus
ttom>top condition at least resolves this
error. However, whether that is correctly emulating D3D behavior, I don't
know.
--
Markus
D3DSurfaceImpl_ModifyLocation
(0x4e8fdf0)->(SFLAG_INDRAWABLE, TRUE)
trace:d3d_surface:IWineD3DBaseSurfaceImpl_GetContainer (This 0x4e8fdf0, riid
{34d01b10-6f30-11d9-c687-00046142c14f}, ppContainer 0x1a9dbc0)
Let me know if more info is needed.
--
Markus
t;>>
GL_INVALID_VALUE (0x501) from glDrawPixels @ surface.c / 1061
If I use d3d9_31.dll instead, the shaders are compiled and the game starts but
the water is again looking like a low-end fallback.
Any ideas on this?
Regards,
--
Markus
in Wine? The native library appears to not
fool the game sufficiently enough to start without an error. Using plain Wine
(no native dxdiag dll) leads to the error in line 44725 of the logfile in the
report.
Thanks.
--
Markus
f the shells I'm aware of allow to
tweak argv[0]. The hearth of a custom launcher would be an execve()
system call, see "man execve" on what it does.
Markus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
tem also comes with these both directories by default...
So I think my patch is closer to the real...
Anyway thanks for your time
Markus
uld include creation of "spool" and "spool/drivers" into this as
well?
Thanks for everybodies time
Markus
So it's really ok to create a patch with only the patch as text without any
attachment?
Markus
"Juan Lang" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> I usually use the archives for viewing patches, sometimes the patches
>> are archived sepa
1 - 100 of 194 matches
Mail list logo
