Hi folks,
I need some help to figure out how the following
realloc functions behave:
GlobalReAlloc
LocalReAlloc
Local32ReAlloc16
NetApiBufferReallocate
SysReAllocStringLen
So, I need to know:
-- do they allocate memory when a NULL is passed in?
-- do they free memory
On November 24, 2003 11:44 pm, Alexandre Julliard wrote:
> What you really want is implement the INIFileMapping mechanism in the
> profile functions.
Any more info on this stuff other than this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/writeprivateprofiles
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> I'd just get rid of all *Profile* calls from Wine, and just deal
> with the registry. If we need to support it, we can just merge
> system.ini into the registry at startup as transient values (can
> we do that?), and special case system.ini in the P
On Fri, 21 Nov 2003, Dimitrie O. Paun wrote:
[...]
> ./dlls/shell32/shell32_main.c:hargv=GlobalReAlloc(hargv, size, 0);
This one is needed because the caller is going to free the allocated
memory using GlobalFree:
> Allocate in a single lump, the string array, and the strings that go
--- Shachar Shemesh <[EMAIL PROTECTED]> wrote:
> If anyone can help me shed more light on this, I would be most
> grateful.
I dont know if you've seen this or not. Maybe it will be of some help.
http://libunicows.sourceforge.net/
Thanks
Steven
__
Do you Yahoo!?
Hans Leidekker <[EMAIL PROTECTED]> writes:
> Changelog:
> - Export more functions by name.
This will break the import libraries. Why do you want to do that?
--
Alexandre Julliard
[EMAIL PROTECTED]
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> Some tracing leads me to suspect (I have not done enough research to
> determine yet) that it accesses the PE header of kernel32 directly. It
> appears that unicows.dll enountered the exact same problem we have vis
> a vis GetProcAddress, and have happ
Alexandre Julliard wrote:
Shachar Shemesh <[EMAIL PROTECTED]> writes:
It seems that I won't be able to use the forwarding inside the spec
file. I'm not sure exactly why that is, but I think the unicows.lib
link time library tries to load stuff by doing "GetModuleHandle", and
then fetching rela
On Mon, 2003-11-24 at 20:38, Alexandre Julliard wrote:
> > Btw, why don't we use -Wa,--noexecstack ?
>
> It doesn't help with prelink AFAICT.
Is it really too late to get some kind of hook into prelink to stop it
interfering with Wine? It seems daft that we need such a big hack when
surely a flag
Ivan Gyurdiev <[EMAIL PROTECTED]> writes:
> I have no clue what the FAR macro does, but wouldn't it be better to
> just rename the wine FAR macro to something different if you dont want
> it to conflict w/ the other FAR macro?
It's a Windows thing, we can't change it.
--
Alexandre Julliard
[EMA
Marcus Meissner <[EMAIL PROTECTED]> writes:
> So ld.so really wants to get 20xMB memory but fails.
>
> -> Not good on low memory machines.
Hmmm I would have expected it to overcommit that memory. Do you have
memory limits set?
> Btw, why don't we use -Wa,--noexecstack ?
It doesn't help with pre
On November 24, 2003 03:00 pm, Eric Pouech wrote:
> the only part that bugs me is that we may use twice the same device if
> it's present both in system.ini and registry. I didn't test how MS
> behaves regarding this, but this may cause some issues.
What about we cross this bridge when we get ther
On November 24, 2003 03:14 pm, Alexandre Julliard wrote:
> The heap test really belongs in kernel, there's no reason to explicitly
> test the Rtl*Heap functions, the Heap* ones do the same thing.
Fine, here it is again:
ChangeLog
RtlHeapReAllocate() should not allocate memory.
Add small tes
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> Good point, sorry about that, I was being lazy. To force people
> to do the dyn load, we shouldn't import ntdll, no?
It won't help, Win95 has heap functions in ntdll, even though they
don't do anything. The heap test really belongs in kernel, there
Hi,
On SuSE 8.2, i586 glibc, loader/wine-* crash due to the 256 MB static array
in main().
The test machine has just 64MB RAM and 200MB swap.
If I start decreasing the array it works, up to 201MB.
$ /lib/ld-linux.so.2 ./wine-kthread
./wine-kthread: error while loading shared libraries: ./wine-k
"Pierre d'Herbemont" <[EMAIL PROTECTED]> writes:
> Here is my second try for a replacement of the _end symbol. I think
> that since there is no support of it we need a kind of emulation
> function, which I thought should be located in the wine_port lib. So I
> add a mach-o.c port file, with the ne
Vincent Béron <[EMAIL PROTECTED]> writes:
> Attached is the patch I propose, although I'm not sure if Alexandre
> likes it.
Sure, that's OK. A slightly cleaner way would be to make sure we
include ssl.h before any Windows header, but your solution is
perfectly acceptable.
--
Alexandre Julliard
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> It seems that I won't be able to use the forwarding inside the spec
> file. I'm not sure exactly why that is, but I think the unicows.lib
> link time library tries to load stuff by doing "GetModuleHandle", and
> then fetching relative values from that
Ferenc Wagner <[EMAIL PROTECTED]> writes:
> What about this:
>
> makename="$BINDIR/`dirname $test`/Makefile.in"
> [...]
> sed -n '/^CTESTS =/,/[^\]$/{s/^CTESTS
> =//;s/\\$//;s/\([0-9a-zA-Z_]*\)\.c/"\1",/g;p;}' $makename
>
> that is, extracting the subtest names from the corres
Dimitrie O. Paun wrote:
On November 22, 2003 03:18 am, Eric Pouech wrote:
This will break any native Win9x driver configuration.
OK, here it is again, this time around with system.ini support
still in here. Hope this one is acceptable.
the only part that bugs me is that we may use twice the same
Mike Hearn <[EMAIL PROTECTED]> writes:
> See if you can get a +font trace when synchronous mode is switched on
> (see the config file), and a backtrace. That might help figure out
> what the problem is.
I got the synchronous mode and +font done in the following file:
http://home.prium.net:
Hi,
On Mon, Nov 24, 2003 at 12:10:20PM -0500, Dimitrie O. Paun wrote:
> On November 22, 2003 03:02 am, Eric Pouech wrote:
> > I won't have too much time to look at this in details right now, so if
> > someone wants to jump in, I'll be happy to give him (her ?) a hand.
>
> To be honest,
> My inter
Dimitrie O. Paun wrote:
On November 21, 2003 03:21 pm, Eric Pouech wrote:
this will not compile on Win9x. You have to take care of:
Good point, sorry about that, I was being lazy. To force people
to do the dyn load, we shouldn't import ntdll, no?
correct. Otherwise, on 9x, you'll get an error at
On November 24, 2003 02:49 am, Marcus Meissner wrote:
> This is the generic fallback PPD file which can be used LPR style printing,
> where we do not get access to a PPD easily.
OK, but then it doesn't belong in documentation.
dlls/wineps perhaps?
--
Dimi.
Hi list,
Here is a quick update.
It seems that I won't be able to use the forwarding inside the spec
file. I'm not sure exactly why that is, but I think the unicows.lib link
time library tries to load stuff by doing "GetModuleHandle", and then
fetching relative values from that place. Is there
> "Troy" == Troy Rollo <[EMAIL PROTECTED]> writes:
Troy> On Mon, 24 Nov 2003 09:02, Uwe Bonnes wrote:
>> Can anybody look at that problem?
Troy> I submitted a patch for this in September, but it never got
Troy> included.
Resubmitt the patch.
Looking at the other code pathes
On November 22, 2003 03:18 am, Eric Pouech wrote:
>
> This will break any native Win9x driver configuration.
OK, here it is again, this time around with system.ini support
still in here. Hope this one is acceptable.
ChangeLog
Move the system.ini/[drivers32] section to the registry.
Index: do
On Mon, Nov 24, 2003 at 02:32:49AM -0500, Dimitrie O. Paun wrote:
>
> I can't help but feel that this file does not belong in the
> Wine tree, but in the print system packages (cups, etc.).
>
> cvs rm -f documentation/samples/generic.ppd
>
> ChangeLog
> Remove generic.ppd, it does not belong
On November 21, 2003 03:21 pm, Eric Pouech wrote:
> this will not compile on Win9x. You have to take care of:
Good point, sorry about that, I was being lazy. To force people
to do the dyn load, we shouldn't import ntdll, no?
ChangeLog
RtlHeapReAllocate() should not allocate memory.
Add smal
29 matches
Mail list logo