You need import the definitions in user32: C:\tcc>tiny_impdef.exe c:\WINDOWS\system32\user32.dll
C:\tcc>move user32.def lib\ ¿Sobrescribir C:\tcc\lib\user32.def? (Sí/No/Todos): s C:\tcc> Now you need user -l for link tcc.exe source.c -luser32 2013/7/21 <[email protected]> > Thank you Jared, > > That makes sense. (As I recall, early versions of Windows were written in > Pascal, which, after conversion to C, resulted in "reversed" function > argument order on calling stacks, etc., to maintain compatibility with > older code.) > > Thanks for taking the time to respond. > > 07/21/13 17:36:39, Jared Maddox <[email protected]>: > > 20.07.2013 5:37, [email protected] ?????: > > I'm new to TCC, using version 0.9.26 under Windows XP Home 32-bit SP3. > > I would like to use the text on the Windows clipboard, so I wrote a > > small test program that #includes <windows.h>, and calls > > OpenClipboard(NULL), GetClipboardData(CF_TEXT), and CloseClipboard(), > > in that order. I ran it with the command line "tcc.exe test.c", and > > got the following error messages: > > > > tcc: error: undefined symbol '_OpenClipboard@4' > > tcc: error: undefined symbol '_GetClipboardData@4' > > tcc: error: undefined symbol '_CloseClipboard@0' > > > > I believe these error messages are generated by TCC's linker. The > > clipboard functions are in user32.dll. > > > > Please tell me what these messages mean, especially the "@n" parts, > > The most important part of your question has already been answered, > but I'll handle this part. > > Yes, these will be linker errors. The Windows API uses functions that > aren't quite defined like normal C functions. Both the object-file > level names and the way that you call these functions are different. I > think the function type is "stdcall", or something of the sort, but > you'll also see it referenced as "pascal" in some cases (note: I don't > think it's pascal, it's just that it's almost the pascal style, so > some people have gotten confused). The @ symbol is used to divide the > primary part of the name from a size description, which if I remember > correctly specifies the size of the argument list. > > In some ways this is a nuisance, since it means that any Windows > compiler needs to either include it's own version of the Windows > headers, or support Microsoft's version, but in this case it's > actually somewhat convenient. The fact that the functions look > distinctively unlike other C functions is enough to let you know that > the missing functions are part of the Windows API (because everyone > else mostly uses standard C functions), instantly letting you know > that: > 1) The function declaration was compiled correctly, > 2) It's a linker error, and > 3) That it can be fixed by linking to the correct Windows component. > > _______________________________________________ > Tinycc-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > > > _______________________________________________ > Tinycc-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > >
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
