I tested it (code to copy a file below, file was > 4
GB) and it works.
I'm using Gentoo 2006.0, Linux 2.6.15.1, ReiserFS 3
and wine 0.9.15.
Can you find out whether the broken code is using
KERNEL32, NTDLL, MSVCRT streams or MSVCRT POSIX-style
open()/read() etc.?
#include <windows.h>
#include <stdio.h>
int main(int argc, char **argv)
{
HANDLE inputFile = INVALID_HANDLE_VALUE, outputFile =
INVALID_HANDLE_VALUE;
const int bufferSize = 8*1024;
char buffer[bufferSize];
DWORD bytesRead;
BOOL ok;
if (argc < 3)
{
fprintf(stderr, "Usage: %s source destination\n",
argv[0]);
return 1;
}
inputFile = CreateFile(argv[1], GENERIC_READ,
FILE_SHARE_READ, NULL,
OPEN_EXISTING, 0, NULL);
if (inputFile == INVALID_HANDLE_VALUE)
{
fprintf(stderr, "Error opening %s\n", argv[1]);
goto done;
}
outputFile = CreateFile(argv[2], GENERIC_WRITE, 0,
NULL,
CREATE_ALWAYS, 0, NULL);
if (outputFile == INVALID_HANDLE_VALUE)
{
fprintf(stderr, "Error opening %s\n", argv[2]);
goto done;
}
ok = ReadFile(inputFile, buffer, bufferSize,
&bytesRead, NULL);
if (!ok)
{
fprintf(stderr, "Error reading file\n");
goto done;
}
while (bytesRead > 0)
{
DWORD bytesWritten = 0, bytesWrittenNow;
do
{
ok = WriteFile(outputFile, buffer, bytesRead,
&bytesWrittenNow,
NULL);
if (!ok)
{
fprintf(stderr, "Error writing file\n");
goto done;
}
bytesWritten += bytesWrittenNow;
} while (bytesWritten < bytesRead);
ok = ReadFile(inputFile, buffer, bufferSize,
&bytesRead, NULL);
if (!ok)
{
fprintf(stderr, "Error reading file\n");
goto done;
}
};
done:
if (inputFile != INVALID_HANDLE_VALUE)
CloseHandle(inputFile);
if (outputFile != INVALID_HANDLE_VALUE)
CloseHandle(outputFile);
return 0;
}
--- John Willis <jswillis93105(a)verizon.net> wrote:
> Damjan,
>
> Linux kernel: 2.4.21-20.ELsmp
> Filesystem: ext3
>
> Thanks for looking into this for me,
>
> John
>
> ----- Original Message -----
> From: "Damjan Jovanovic" <dj015(a)yahoo.com>
> To: "John Willis" <jswillis93105(a)verizon.net>;
> <wine-devel(a)winehq.org>
> Sent: Sunday, June 25, 2006 11:31 PM
> Subject: Re: Very large files
>
>
> >
> >
> > --- John Willis <jswillis93105(a)verizon.net> wrote:
> >
> >> Howdy,
> >>
> >> I have a large VS 6.0 C++ program and I'm running
> it
> >> under WINE under Redhat Linux.
> >> Everything works fine, but it doesn't handle file
> >> sizes greater than 4gb like it can running
> >> directly under Windows XP.
> >> I've tweaked everything that I can find that
> seems
> >> to deal with file sizes.
> >
> > How do you access the file? With stdio streams
> > (fopen(), fread(), ...), MSVCRT's open()/read(),
> or
> > with KERNEL32's CreateFile(), ReadFile(), ... ?
> >
> >> Is there a problem with WINE itself handling very
> >> large file sizes?
> >
> > Which version of the Linux kernel and which
> filesystem
> > are you using?
> >
> > I'll run some tests at home and see whether it
> works
> > for me.
> >
> >> Thanks in advance,
> >> John>
> >>
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Wow, thats a pretty neat idea.
A few comments.
We should do something to the values in $_REQUEST so they can't be used after
this function is called.
We should error if there are variables that don't fit the format we expect. We
can't have anything getting past this filter by default or we'll be opening
holes in the filtering without any kind of notification. We'll also want to
know if we've missed anything during our changes.
Html keyword should probably be 'sh' instead of 'sH' so the lower case
characters prefixed on a variable are what represents the variables type.
This would be more consistent with what we have.
Filtering all variables might let us support allowing magic quotes although
given the widespread rejection of the magic quotes feature it seems silly to
do so. I wouldn't be surprised if the switch was removed from php entirely
in the near future.
Chris
On Tuesday 27 June 2006 4:56 am, Jonathan Ernst wrote:
> Please apply the (harmless) errorpage patch first.
>
> As my prevous approach was refused, I decided to improve the current
> makeClean approach.
>
> This patch automatically fills the $aClean array when we'll start using
> variable names like iVersionId, etc. This let's us check/clean up
> everything in a single place and do the error handling there.
>
> You'll notice that I cleanly handle the magic_quote_gpc case as well. I
> know that people with magic_quote_gpc will get an error message thanks
> to Chris patch, but I still hope we can revert his patch in the future
> because I don't like forcing people to change their php config.
>
> Changelog:
> - automatic variable cleanup function
>
> Files changed:
> - CODING_STANDARD
> - include/incl.php
> - include/util.php
"Maarten Lankhorst" <M.B.Lankhorst(a)gmail.com> wrote:
> +static HINSTANCE ghInst = NULL;
> +
> +BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
> +{
> + TRACE("(0x%p, %ld, %p)\n", hinstDLL, fdwReason, lpvReserved);
> +
> + switch (fdwReason) {
> + case DLL_WINE_PREATTACH:
> + return FALSE; /* prefer native version */
> + case DLL_PROCESS_ATTACH:
> + ghInst = NULL;
> + break;
You meant to make it 'ghInst = hinstDLL;', right?
I'd suggest to get rid of ghInst altogether until there is a real need for it.
--
Dmitry.
Hi Lukazs, I'm afraid this still isn't ready for inclusion:
diff -u -r1.3 Makefile.in
--- dlls/mswsock/Makefile.in 9 May 2005 14:42:33 -0000 1.3
+++ dlls/mswsock/Makefile.in 27 Jun 2006 23:13:09 -0000
@@ -4,13 +4,16 @@
VPATH = @srcdir@
MODULE = mswsock.dll
IMPORTLIB = libmswsock.$(IMPLIBEXT)
-IMPORTS = ws2_32 iphlpapi kernel32
+IMPORTS = ws2_32 kernel32
+
This change looks fine, but it could, and therefore should, be sent as a separate patch.
/***********************************************************************
- * TransmitFile (MSWSOCK.@)
+ * WSAAddressToStringW (MSWSOCK.@)
*
- * This function is used to transmit a file over socket.
+ * Transmit file via socket. Header / Footer data is also supported.
*
- * TODO
- * This function is currently implemented as a stub.
+ * PARAMS
+ * hSocket [I] Socket for sending the data. Not handle.
+ * hFile [I] file to transmit.
+ * nNumberOfBytesToWrite [I] How much data to write. Optional
+ * nNumberOfBytesPerSend [I] Maximum length of single packet (usefull for communication protocols)
+ * lpOverlapped [I/O] used for overlapped operations
+ * lpTransmitBuffers [I] data to send as header/tail usefull for communication protocols)
Same here. This looks good, but perhaps send this as a documentation patch.
Lining up the text better would be nice too.
+ if(!nNumberOfBytesToWrite)
+ nNumberOfBytesToWrite = -1; /* should be OK */
Why wouldn't it be? The comment doesn't tell me anything, so make it say what it means, or omit it.
+ if(!dwRetVal)
+ {
+ WSASetLastError(WSAEACCES);
+ goto e_exit;
Are you sure WSAEACCES should be set on any ReadFile error? I suspect ReadFile already sets
the last error, so a goto e_exit should be sufficient.
+ }
+ if(dwFlags & TF_DISCONNECT)
+
+ok_exit:
+ if(lpOverlapped)
+ lpOverlapped->Internal = dwTotalBytesSent; /* FIXME */
The first if is missing a then block.
Fix what? The comment needs to be clear about what needs to be fixed.
In the tests patch,
+/** #define RUN_BIG_FILE_TEST /**/
Eck. That's ugly. At least my editor complains about the nested comment.
Just omit dead code from your patch.
+#ifndef SAFE_RELEASE
Why do you need the ifndef protection? It's not going to be defined anywhere else, so just define it.
+#define SAFE_RELEASE(x) {if(x) {free(x); x=NULL;}}
If you must use multi-statement macros, please use something like:
do { ... } while 0
instead. Note the lack of closing semicolon. See e.g. http://c-faq.com/cpp/multistmt.html
+#define SAFE_HRELEASE(x) {if(x!=INVALID_HANDLE_VALUE) {CloseHandle(x); x=INVALID_HANDLE_VALUE;}}
What does that help? CloseHandle already handles invalid handles. Please just use that instead.
+ HANDLE hFOutput = INVALID_HANDLE_VALUE;
+ int i = 0;
+ int size = 0;
+ DWORD written = 0;
+ DWORD filesize = 0;
+ BOOL nBoolRetval = FALSE;
What's the reason for aligning the variable declarations and initializations just so?
It looks like you just used your editor to replace tabs with spaces, without paying attention
to indentation. We accept all sorts of styles in wine code--but please pick one style.
--Juan
tkho(a)ucla.edu wrote:
>+typedef struct {
>+ /* ----------- MENUITEMINFO Stuff ----------- */
>+ UINT fType; /* Item type. */
>+ UINT fState; /* Item state. */
>+ UINT_PTR wID; /* Item id. */
>+ HMENU hSubMenu; /* Pop-up menu. */
>+ HBITMAP hCheckBit; /* Bitmap when checked. */
>+ HBITMAP hUnCheckBit; /* Bitmap when unchecked. */
>+ LPWSTR text; /* Item text. */
>+ ULONG_PTR dwItemData; /* Application defined. */
>+ LPWSTR dwTypeData; /* depends on fMask */
>+ HBITMAP hbmpItem; /* bitmap */
>+ /* ----------- Wine stuff ----------- */
>+ RECT rect; /* Item area (relative to menu window) */
>+ UINT xTab; /* X position of text after Tab */
>+ SIZE bmpsize; /* size needed for the HBMMENU_CALLBACK
>+ * bitmap */
>+} MENUITEM;
>+
>+/* Popup menu structure */
>+typedef struct {
>+ WORD wFlags; /* Menu flags (MF_POPUP, MF_SYSMENU) */
>+ WORD wMagic; /* Magic number */
>+ WORD Width; /* Width of the whole menu */
>+ WORD Height; /* Height of the whole menu */
>+ UINT nItems; /* Number of items in the menu */
>+ HWND hWnd; /* Window containing the menu */
>+ MENUITEM *items; /* Array of menu items */
>+ UINT FocusedItem; /* Currently focused item */
>+ HWND hwndOwner; /* window receiving the messages for ownerdraw */
>+ BOOL bTimeToHide; /* Request hiding when receiving a second click in the top-level menu item */
>+ BOOL bScrolling; /* Scroll arrows are active */
>+ UINT nScrollPos; /* Current scroll position */
>+ UINT nTotalHeight; /* Total height of menu items inside menu */
>+ /* ------------ MENUINFO members ------ */
>+ DWORD dwStyle; /* Extended menu style */
>+ UINT cyMax; /* max height of the whole menu, 0 is screen height */
>+ HBRUSH hbrBack; /* brush for menu background */
>+ DWORD dwContextHelpID;
>+ DWORD dwMenuData; /* application defined value */
>+ HMENU hSysMenuOwner; /* Handle to the dummy sys menu holder */
>+ SIZE maxBmpSize; /* Maximum size of the bitmap items */
>+} POPUPMENU, *LPPOPUPMENU;
>
Hi Thomas,
This needs to be cleaned up a lot more before it will be accepted.
For a start, the members of this structure need to be cleaned up. Some
of the members of the POPUPMENU structure are for keeping track of the
menu while it's in use (bTimeToHide, bScrolling, nScrollPos,
FocusedItem), so these could be kept on the client side. Also,
everything needs to be converted to wineserver types.
It should become clear what needs to change as menu item handling is
moved into the server, so I would urge you to work on that and then
rework these patches.
Thanks,
--
Rob Shearman
Hello All,
My name is Jonathan Clark, and I work with a team on a project that has
some similarities with Wine. The project is called Thinstall
(http://thinstall.com), and on first glance similarities may not be
apparent. Thinstall allows Win32 applications to run (on Windows) from a
network share or usb flash drive with zero install. It isn't meant to allow
applications to run cross platform like wine, but it is similar in that it
replaces the Windows loader for loading EXEs & DLLs, doing things like
mapping, imports, and thread/process management. It also replaces ~400
Win32 api functions in order to allow applications to run instantly in a
sandbox so they don't need to touch the local filesystem or registry. Our
approach is all in user mode so that applications can run under any login
account without needing admin rights or drivers. Thinstall packages the
entire application into a single EXE file and then tacks on it's runtime
(300k on disk) so apps can be distributed and run as a single file that
doesn't need to decompress to disk.
The challenges in creating Thinstall are many of the same ones that Wine
faces, achieving a high degree of compatibility in replacement functions
means you need to be good at debugging and understanding the internals of
Windows. Since most code can be run by multiple threads, it is also
important to understand thread safety and have a lot of experience working
through these types of issues.
Thinstall is now about 6 years old and we are coming up on a version 3.0
release. Thinstall is a commercial product and everyone works full time
with funding coming from our customers. Recently we've done fairly well
financially and have the opportunity to try to take the product and company
to the next level by hiring a couple of senior engineers. This brings me to
why I'm posting here..
If you are experienced with Windows internals, have experience
reimplementing Win32 APIs, and you are interested in some contract or
full-time work please let me know. We are located in San Francisco,
California (awesome town) and ideally I'd like to work with people locally.
We can help with a move if needed. Otherwise, if you are outside of the USA
- we could talk about doing something remotely.
I hope to hear from you.
Best Regards,
Jonathan Clark
P.S. As background info, I used to be heavily in the linux space when I
co-founded a video game company "Crack dot com" which made the linux port of
Doom & Quake as well as developed the original titles Abuse and Golgotha. I
have been aware of wine for a long long time and I'm impressed by the
quality of work by all the developers and how far it has come.
P.S.S. I subscribed in digest mode so if you reply to the list, keep in mind
I won't see it until tomorrow.
William Knopp writes:
> What's the story with wine on intel os x?
A few people, including Codeweavers, are working on it.
More would be welcome. There is no politics keeping
people away, as far as I know. If you run into any developer
who says that politics is keeping him or her from
submitting patches to wine-patches, please let me know.
- Dan
Chris Morgan wrote:
> Yes, having quotes around limit values breaks sql queries. I'll
> incorporate this into the injection change patch.
>
> I'm curious as to why the rest of the patch is the same though. It
> will conflict when the other sql patch is applied.
>
What other sql patch? How will it conflict? I have broken your large patch up in
order to test it, since you refused to do it yourself. This is the portion of
the patch that I tested. I had to modify it a bit like I said but the rest is
yours and you get the credit.
What do you plan on doing with this patch? Are you planning to wait until I have
tested all various parts of your big patch and then apply it all at once?
--
Tony Lambregts
