Search Results

Search found 68 results on 3 pages for 'winmain'.

Page 1/3 | 1 2 3  | Next Page >

  • WinMain not called before main (C/C++ Program Entry Point Issue)

    - by BT
    I was under the impression that this code #include <windows.h> #include <stdio.h> int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) { printf("WinMain\n"); return 0; } int main() { printf("main\n"); return 0; } would output WinMain, but of course nothing ever works how you expects. Anyways, could somebody please tell me how to get this program to run WinMain first (I do have a reason for using both). I'm running windows 7 with mingw if that helps anything.

    Read the article

  • c++ use of winmain()

    - by Jack
    Hi, I just started learning programming for windows in c++. I had this crazy image, that win32 programming is based on calling windows functions and sending parameters to and from them. Like, when you want to create window, you call some win32 function that handles windows GUI and say "Hi, please, create me new window, 100 x 100 px, with two buttons", and that GUI function says "Hi, no problem, when something happends, like user clicks one button, I will change this variable xy located in this location". So, I thought that it will be very similiar to console programming. But the very first instruction surprised me. I always thought that every program executes main() function first. So, when I launch app, windows stores some parameters on top of stack and run that application. So I assumed that initializing main() is just a c++ way to tell the compiler where the first instruction should be. But in win32 programming, there is function called winmain() which starts first. So I am little confused. I thought it´s rule that compiler must have main() to start with, that main just defines where ti start, like some start point identifier. So, please, why is there winmain() function instead of main()? When I thought that C++ programming is as logical as assembler, it confuses me once again.

    Read the article

  • c++ use of winmain()

    - by Jack
    Hi, I just started learning programming for windows in c++. I had this crazy image, that win32 programming is based on calling windows functions and sending parameters to and from them. Like, when you want to create window, you call some win32 function that handles windows GUI and say "Hi, please, create me new window, 100 x 100 px, with two buttons", and that GUI function says "Hi, no problem, when something happends, like user clicks one button, I will change this variable xy located in this location". So, I thought that it will be very similiar to console programming. But the very first instruction surprised me. I always thought that every program executes main() function first. So, when I launch app, windows stores some parameters on top of stack and run that application. So I assumed that initializing main() is just a c++ way to tell the compiler where the first instruction should be. But in win32 programming, there is function called winmain() which starts first. So I am little confused. I thought it´s rule that compiler must have main() to start with, that main just defines where ti start, like some start point identifier. So, please, why is there winmain() function instead of main()? When I thought that C++ programming is as logical as assembler, it confuses me once again.

    Read the article

  • why doesn't winmain set the errorlevel?

    - by Brian R. Bondy
    int APIENTRY _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow) { MessageBox(NULL, _T("This should return 90 no?"), _T("OK"), MB_OK); return 90; } Why does the above program correctly display the message box, but does not set the error level? I compile this program to the name a.exe. Then from command prompt I type: c:\> a.exe (message box is displayed, I press ok) c:\> echo %ERRORLEVEL% 0 I get the same results if I do exit(90); right before the return. It still says 0. I also tried to start the program via CreateProcess and obtain the result with GetExitCodeProcess but it also returns 0 to me. I did error checking to ensure it was all started correctly. I originally seen this problem in a more complex program. But made this simple program to verify the problem. Results are the same, both programs that have WinMain return 0 always. I tried both x64, x86 and unicode and MBCS compiling options. All give 0 as an error level/status code.

    Read the article

  • How to disable WinMain entry point for a MFC application?

    - by Sorin Sbarnea
    I understand that is not possible to have applications with multiple entry points under Windows. I have a MFC application and I added code for making it running as a service (main() entry point and other required stuff) but it looks that Windows will always run the WinMain() from MFC instead of my main. The question is how can I disable the WinMain() from MFC in order to be able to run my own main(). Probably the same problem would apply if you want to run the same application as a console application. What do I have to change in project properties in order to build it as a console application (main instead of WinMain)? Is commenting my CWinApp the only solution?

    Read the article

  • Difference between WinMain and wWinMain

    - by Sherwood Hu
    The only difference is that Winmain takes char* for lpCmdLine parameter, while wWinMain takes wchar_t*. On Windows XP, if an application entry is WinMain, does Windows convert the command line from Unicode to Ansi and pass to the application? If the command line parameter must be in Unicode (for example, Unicode file name, conversion will cause some characters missing), does that mean that I must use wWinMain as the entry function?

    Read the article

  • How do I use the Enum value from a class in another part of code?

    - by ChiggenWingz
    Coming from a C# background from a night course at a local college, I've sort of started my way in C++. Having a lot pain getting use to the syntax. I'm also still very green when it comes to coding techniques. From my WinMain function, I want to be able to access a variable which is using an enum I declared in another class. (inside core.h) class Core { public: enum GAME_MODE { INIT, MENUS, GAMEPLAY }; GAME_MODE gameMode; Core(); ~Core(); ...OtherFunctions(); }; (inside main.cpp) Core core; int WINAPI WinMain(...) { ... startup code here... core.gameMode = Core.GAME_MODE.INIT; ...etc... } Basically I want to set that gameMode to the enum value of Init or something like that from my WinMain function. I want to also be able to read it from other areas. I get the error... expected primary-expression before '.' token If I try to use core.gameMode = Core::GAME_MODE.INIT;, then I get the same error. I'm not fussed about best practices, as I'm just trying to get the basic understanding of passing around variables in C++ between files. I'll be making sure variables are protected and neatly tucked away later on once I am use to the flexibility of the syntax. If I remember correctly, C# allowed me to use Enums from other classes, and all I had to do was something like Core.ENUMNAME.ENUMVALUE. I hope what I'm wanting to do is clear :\ As I have no idea what a lot of the correct terminology is.

    Read the article

  • Override an IOCTL Handler in PQOAL

    - by Kate Moss' Big Fan
    When porting or creating a BSP to a new platform, we often need to make change to OEMIoControl or HAL IOCTL handler for more specific. Since Microsoft introduced PQOAL in CE 5.0 and more and more BSP today leverages PQOAL to simplify the OAL, we no longer define the OEMIoControl directly. It is somehow analogous to migrate from pure Windows SDK to MFC; people starts to define those MFC handlers and forgot the WinMain and the big message loop. If you ever take a look at the interface between OAL and Kernel, PUBLIC\COMMON\OAK\INC\oemglobal.h, the pfnOEMIoctl is still there just as the entry point of Windows Program is WinMain since day one. (For those may argue about pfnOEMIoctl is not OEMIoControl, I will encourage you to dig into PRIVATE\WINCEOS\COREOS\NK\OEMMAIN\oemglobal.c which initialized pfnOEMIoctl to OEMIoControl. The interface is just to split OAL and Kernel which no longer linked to one executable file in CE 6, all of the function signature is still identical) So let's trace into PQOAL to realize how it implements OEMIoControl and how can we override an IOCTL handler we interest. First thing to know is the entry point (just as finding the WinMain in MFC), OEMIoControl is defined in PLATFORM\COMMON\SRC\COMMON\IOCTL\ioctl.c. Basically, it does nothing special but scan a pre-defined IOCTL table, g_oalIoCtlTable, and then execute the handler. (The highlight part) Other than that is just for error handling and the use of critical section to serialize the function. BOOL OEMIoControl(     DWORD code, VOID *pInBuffer, DWORD inSize, VOID *pOutBuffer, DWORD outSize,     DWORD *pOutSize ) {     BOOL rc = FALSE;     UINT32 i; ...     // Search the IOCTL table for the requested code.     for (i = 0; g_oalIoCtlTable[i].pfnHandler != NULL; i++) {         if (g_oalIoCtlTable[i].code == code) break;     }     // Indicate unsupported code     if (g_oalIoCtlTable[i].pfnHandler == NULL) {         NKSetLastError(ERROR_NOT_SUPPORTED);         OALMSG(OAL_IOCTL, (             L"OEMIoControl: Unsupported Code 0x%x - device 0x%04x func %d\r\n",             code, code >> 16, (code >> 2)&0x0FFF         ));         goto cleanUp;     }            // Take critical section if required (after postinit & no flag)     if (         g_ioctlState.postInit &&         (g_oalIoCtlTable[i].flags & OAL_IOCTL_FLAG_NOCS) == 0     ) {         // Take critical section                    EnterCriticalSection(&g_ioctlState.cs);     }     // Execute the handler     rc = g_oalIoCtlTable[i].pfnHandler(         code, pInBuffer, inSize, pOutBuffer, outSize, pOutSize     );     // Release critical section if it was taken above     if (         g_ioctlState.postInit &&         (g_oalIoCtlTable[i].flags & OAL_IOCTL_FLAG_NOCS) == 0     ) {         // Release critical section                    LeaveCriticalSection(&g_ioctlState.cs);     } cleanUp:     OALMSG(OAL_IOCTL&&OAL_FUNC, (L"-OEMIoControl(rc = %d)\r\n", rc ));     return rc; }   Where is the g_oalIoCtlTable? It is defined in your BSP. Let's use DeviceEmulator BSP as an example. The PLATFORM\DEVICEEMULATOR\SRC\OAL\OALLIB\ioctl.c defines the table as const OAL_IOCTL_HANDLER g_oalIoCtlTable[] = { #include "ioctl_tab.h" }; And that leads to PLATFORM\DEVICEEMULATOR\SRC\INC\ioctl_tab.h which defined some of IOCTL handler but others are defined in oal_ioctl_tab.h which is under PLATFORM\COMMON\SRC\INC\. Finally, we got the full table body! (Just like tracing MFC, always jumping back and forth). The format of table is very straight forward, IOCTL code, Flags and Handler Function // IOCTL CODE,                          Flags   Handler Function //------------------------------------------------------------------------------ { IOCTL_HAL_INITREGISTRY,                   0,  OALIoCtlHalInitRegistry     }, { IOCTL_HAL_INIT_RTC,                       0,  OALIoCtlHalInitRTC          }, { IOCTL_HAL_REBOOT,                         0,  OALIoCtlHalReboot           }, The PQOAL scans through the table until it find a matched IOCTL code, then invokes the handler function. Since it scans the table from the top which means if we define TWO handler with same IOCTL code, the first one is always invoked with no exception. Now back to the PLATFORM\DEVICEEMULATOR\SRC\INC\ioctl_tab.h, with the following table { IOCTL_HAL_INITREGISTRY,                   0,  OALIoCtlDeviceEmulatorHalInitRegistry     }, ... #include <oal_ioctl_tab.h> Note the IOCTL_HAL_INITREGISTRY handler are defined in both BSP's local ioctl_tab.h and the common oal_ioctl_tab.h, but due to BSP's local handler comes before "#include <oal_ioctl_tab.h>" so we know the OALIoCtlDeviceEmulatorHalInitRegistry always get called. In this example, the DeviceEmulator BSP overrides the IOCTL_HAL_INITREGISTRY handler from OALIoCtlHalInitRegistry to OALIoCtlDeviceEmulatorHalInitRegistry by manipulating the g_oalIoCtlTable table. (In some point of view, it is similar to message map in MFC) Please be aware, when you override an IOCTL handler in PQOAL, you may want to clone the original implementation to your BSP and change to meet your need. It is recommended and save you the redundant works but remember to rename the handler function (Just like the DeviceEmulator it changes the name of OALIoCtlHalInitRegistry to OALIoCtlDeviceEmulatorHalInitRegistry). If you don't change the name, linker may not be happy (due to name conflict) and the more important is by using different handler name, you could always redirect the handler back to original one. (It is like the concept of OOP that calling a function in base class; still not so clear? I am goinf to show you soon!) The OALIoCtlDeviceEmulatorHalInitRegistry setups DeviceEmulator specific registry settings and in the end, if everything goes well, it calls the OALIoCtlHalInitRegistry (PLATFORM\COMMON\SRC\COMMON\IOCTL\reginit.c) to do the rest.     if(fOk) {         fOk = OALIoCtlHalInitRegistry(code, pInpBuffer, inpSize, pOutBuffer,             outSize, pOutSize);     } Now you got the picture, whenever you want to override an IOCTL hadnler that is implemented in PQOAL just Clone the handler function to your BSP as a template. Simple name change for the handler function, and a name change in the IOCTL table header file that maps the IOCTL with the function Implement your IOCTL handler and whenever you need to redirect it back just calling the original handler function. It is the standard way of implementing a custom IOCTL and most Microsoft developers prefer. The mapping of IOCTL routine to IOCTL code is platform specific - you control the header file that does that mapping.

    Read the article

  • Silverlight for Windows Embedded Tutorial (step 5 and a bit of Windows Phone 7)

    - by Valter Minute
    If you haven’t spent the last week in the middle of the Sahara desert or traveling on a sled in the north pole area you should have heard something about the launch of Windows Phone 7 Series (or Windows Phone Series 7, or Windows Series Phone 7 or something like that). Even if you are in the middle of the desert or somewhere around the north pole you may have been reached by the news, since it seems that WP7S (using the full name will kill my available bandwidth!) is generating a lot of buzz in the development and IT communities. One of the most important aspects of this new platform is that it will be programmed using a new set of tools and frameworks, completely different from the ones used on older releases of Windows Mobile (or SmartPhone, or PocketPC or whatever…). WP7S applications can be developed using Silverlight or XNA. If you want to learn something more about WP7S development you can download the preview of Charles Petzold’s book about it: http://www.charlespetzold.com/phone/index.html Charles Petzold is also the author of “Programming Windows”, the first book I ever read about programming on Windows (it was Windows 3.0 at that time!). The fact that even I was able to learn how to develop Windows application is a proof of the quality of Petzold’s work. This book is up to his standards and the 150pages preview is already rich in technical contents without being boring or complicated to understand. I may be able to become a Windows Phone developer thanks to mr. Petzold. Mr. Petzold uses some nice samples to introduce the basic concepts of Silverlight development on WP7S. On this new platform you’ll use managed code to develop your application, so those samples can’t be ported on Windows CE R3 as they are, but I would like to take one of the first samples (called “SilverlightTapHello1”) and adapt it to Silverlight for Windows Embedded to show that even plain old native code can be used to develop “cool” user interfaces! The sample shows the standard WP7S title header and a textbox with an hello world message inside it. When the user touches the textbox, it will change its color. When the user touches the background (Grid) behind it, its default color (plain old White) will be restored. Let’s see how we can implement the same features on our embedded device! I took the XAML code of the sample (you can download the book samples here: http://download.microsoft.com/download/1/D/B/1DB49641-3956-41F1-BAFA-A021673C709E/CodeSamples_DRAFTPreview_ProgrammingWindowsPhone7Series.zip) and changed it a little bit to remove references to WP7S or managed runtime. If you compare the resulting files you will see that I was able to keep all the resources inside the App.xaml files and the structure of  MainPage.XAML almost intact. This is the Silverlight for Windows Embedded version of MainPage.XAML: <UserControl x:Class="SilverlightTapHello1.MainPage" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:phoneNavigation="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone.Controls.Navigation" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" mc:Ignorable="d" d:DesignWidth="480" d:DesignHeight="800" FontFamily="{StaticResource PhoneFontFamilyNormal}" FontSize="{StaticResource PhoneFontSizeNormal}" Foreground="{StaticResource PhoneForegroundBrush}" Width="640" Height="480">   <Grid x:Name="LayoutRoot" Background="{StaticResource PhoneBackgroundBrush}"> <Grid.RowDefinitions> <RowDefinition Height="Auto"/> <RowDefinition Height="*"/> </Grid.RowDefinitions>   <!--TitleGrid is the name of the application and page title--> <Grid x:Name="TitleGrid" Grid.Row="0"> <TextBlock Text="SILVERLIGHT TAP HELLO #1" x:Name="textBlockPageTitle" Style="{StaticResource PhoneTextPageTitle1Style}"/> <TextBlock Text="main page" x:Name="textBlockListTitle" Style="{StaticResource PhoneTextPageTitle2Style}"/> </Grid>   <!--ContentGrid is empty. Place new content here--> <Grid x:Name="ContentGrid" Grid.Row="1" MouseLeftButtonDown="ContentGrid_MouseButtonDown" Background="{StaticResource PhoneBackgroundBrush}"> <TextBlock x:Name="TextBlock" Text="Hello, Silverlight for Windows Embedded!" HorizontalAlignment="Center" VerticalAlignment="Center" /> </Grid> </Grid> </UserControl> If you compare it to the WP7S sample (not reported here to avoid any copyright issue) you’ll notice that I had to replace the original phoneNavigation:PhoneApplicationPage with UserControl as the root node. This make sense because there is not support for phone applications on CE 6. I also had to specify width and height of my main page (on the WP7S device this will be adjusted by the OS) and I had to replace the multi-touch event handler with the MouseLeftButtonDown event (no multitouch support for Windows CE R3, still). I also changed the hello message, of course. I used XAML2CPP to generate the boring part of our application and then added the initialization code to WinMain: int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow) { if (!XamlRuntimeInitialize()) return -1;   HRESULT retcode;   IXRApplicationPtr app; if (FAILED(retcode=GetXRApplicationInstance(&app))) return -1; XRXamlSource dictsrc;   dictsrc.SetResource(hInstance,TEXT("XAML"),IDR_XAML_App);   if (FAILED(retcode=app->LoadResourceDictionary(&dictsrc,NULL))) return -1;   MainPage page;   if (FAILED(page.Init(hInstance,app))) return -1;   UINT exitcode;   if (FAILED(page.GetVisualHost()->StartDialog(&exitcode))) return -1;   return exitcode; }   You may have noticed that there is something different from the previous samples. I added the code to load a resource dictionary. Resources are an important feature of XAML that allows you to define some values that could be replaced inside any XAML file loaded by the runtime. You can use resources to define custom styles for your fonts, backgrounds, controls etc. and to support internationalization, by providing different strings for different languages. The rest of our WinMain isn’t that different. It creates an instances of our MainPage object and displays it. The MainPage class implements an event handler for the MouseLeftButtonDown event of the ContentGrid: class MainPage : public TMainPage<MainPage> { public:   HRESULT ContentGrid_MouseButtonDown(IXRDependencyObject* source,XRMouseButtonEventArgs* args) { HRESULT retcode; IXRSolidColorBrushPtr brush; IXRApplicationPtr app;   if (FAILED(retcode=GetXRApplicationInstance(&app))) return retcode;   if (FAILED(retcode=app->CreateObject(IID_IXRSolidColorBrush,&brush))) return retcode;   COLORREF color=RGBA(0xff,0xff,0xff,0xff);   if (args->pOriginalSource==TextBlock) color=RGBA(rand()&0xFF,rand()&0xFF,rand()&0xFF,0xFF);   if (FAILED(retcode=brush->SetColor(color))) return retcode;   if (FAILED(retcode=TextBlock->SetForeground(brush))) return retcode; return S_OK; } }; As you can see this event is generated when a used clicks inside the grid or inside one of the objects it contains. Since our TextBlock is inside the grid, we don’t need to provide an event handler for its MouseLeftButtonDown event. We can just use the pOriginalSource member of the event arguments to check if the event was generated inside the textblock. If the event was generated inside the grid we create a white brush,if it’s inside the textblock we create some randomly colored brush. Notice that we need to use the RGBA macro to create colors, specifying also a transparency value for them. If we use the RGB macro the resulting color will have its Alpha channel set to zero and will be transparent. Using the SetForeground method we can change the color of our control. You can compare this to the managed code that you can find at page 40-41 of Petzold’s preview book and you’ll see that the native version isn’t much more complex than the managed one. As usual you can download the full code of the sample here: http://cid-9b7b0aefe3514dc5.skydrive.live.com/self.aspx/.Public/SilverlightTapHello1.zip And remember to pre-order Charles Petzold’s “Programming Windows Phone 7 series”, I bet it will be a best-seller! Technorati Tags: Silverlight for Windows Embedded,Windows CE

    Read the article

  • Windows 7 Sysprep Default User

    - by Demonwolf
    I seem to be having a problem with implementing my sysprep. I have been playing with Windows 7, WAIK, Server 2008 R2 and various other things. I managed to create a WIM with everything I need installed and I have worked out the autounattend.xml. I now have a Windows 7 64-bit complete unattended install from a USB device. It has all my programs, setting and everything done except one thing - the default profile set up 100% correctly. I have created a mostly set up default profile. I booted into audit mode, customized the Administrator account (mostly anyway) and then used sysprep with an unattend.xml file containing the copyprofile=true command. The file was set up with the WSIM and does not contain any extra info. This all works wonderfully. I recreated the WIM and all was good. I then decided to move the default location of the visible stuff in the user profile (Documents, Music, Pictures etc.) without changing the location of Appdata or other hidden folders. This is where things went a little... wrong. I went to the user folder (generally has the User name) with all the other folders in it. I right clicked on My Documents, found the location tab and changed it to M:\Documents. Now if I run sysprep /generalize /oobe /reboot /unattend:unattend.xml it starts the generalise... then spits out a fatal error and goes no further. The setuperr.log contains the following errors: 2011-08-18 23:21:43, Error [0x0f0043] SYSPRP WinMain:The sysprep dialog box returned FALSE 2011-08-18 23:31:57, Error [0x0f0082] SYSPRP LaunchDll:Failure occurred while executing 'C:\Windows\System32\slc.dll,SLReArmWindows', returned error code -1073425657 2011-08-18 23:31:57, Error [0x0f0070] SYSPRP RunExternalDlls:An error occurred while running registry sysprep DLLs, halting sysprep execution. dwRet = -1073425657 2011-08-18 23:31:57, Error [0x0f00a8] SYSPRP WinMain:Hit failure while processing sysprep generalize internal providers; hr = 0xc004d307 Does anyone have any ideas how I can redirect My Documents and other items in a user file to a second drive in the default profile so it affects each person logging in?

    Read the article

  • How to create a console application that does not terminate?

    - by John
    Hello, In C++,a console application can have a message handler in its Winmain procedure.Like this: int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { HWND hwnd; MSG msg; #ifdef _DEBUG CreateConsole("Title"); #endif hwnd = CreateDialog(hInstance, MAKEINTRESOURCE(IDD_DIALOG1), NULL, DlgProc); PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE); while(msg.message != WM_QUIT) { if(PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) { if(IsDialogMessage(hwnd, &msg)) continue; TranslateMessage(&msg); DispatchMessage(&msg); } } return 0; } This makes the process not close until the console window has received WM_QUIT message. I don't know how to do something similar in delphi. My need is not for exactly a message handler, but a lightweight "trick" to make the console application work like a GUI application using threads. So that, for example, two Indy TCP servers could be handled without the console application terminating the process. My question: How could this be accomplished?

    Read the article

  • How to encapsulate a WinAPI application into a C++ class

    - by Semen Semenych
    There is a simple WinAPI application. All it does currently is this: register a window class register a tray icon with a menu create a value in the registry in order to autostart and finally, it checks if it's unique using a mutex As I'm used to writing code mainly in C++, and no MFC is allowed, I'm forced to encapsulate this into C++ classes somehow. So far I've come up with such a design: there is a class that represents the application it keeps all the wndclass, hinstance, etc variables, where the hinstance is passed as a constructor parameter as well as the icmdshow and others (see WinMain prototype) it has functions for registering the window class, tray icon, reigstry information it encapsulates the message loop in a function In WinMain, the following is done: Application app(hInstance, szCmdLIne, iCmdShow); return app.exec(); and the constructor does the following: registerClass(); registerTray(); registerAutostart(); So far so good. Now the question is : how do I create the window procedure (must be static, as it's a c-style pointer to a function) AND keep track of what the application object is, that is, keep a pointer to an Application around. The main question is : is this how it's usually done? Am I complicating things too much? Is it fine to pass hInstance as a parameter to the Application constructor? And where's the WndProc? Maybe WndProc should be outside of class and the Application pointer be global? Then WndProc invokes Application methods in response to various events.

    Read the article

  • Game Timer In C++

    - by user1870398
    I need to be able to find out how many milliseconds since that last update. Is there any way I can find it out with time rather then a thread that counts like I did below? #include <iostream> #include<windows.h> #include<time.h> #include<process.h> using namespace std; int Timer = 0; int LastTimer = 0; bool End = false; void Update(int Ticks) { } void UpdateTimer() { while (true) { LastTimer = Timer; Timer++; Sleep(1); if (End) break; } } int WINAPI WinMain(HINSTANCE par1, HINSTANCE par2, LPSTR par3, int par4) { _beginthread(UpdateTimer, 0, NULL); while(true) { if (Timer == 1000) Timer = 0; Update(Timer - LastTimer); } }

    Read the article

  • Wine installation on 12.04 LTS

    - by Dale
    Installed wine from the Software Center and kept getting errors when trying to load windows programs. Uninstalled and did the apt-get installation of the latest version (1.5.7) Ran Wine configuration and get a "Failed to connect to the mount manager, the drive configuration cannot be edited" If i try to install a program it immediately goes to "Internal error" Any Ideas or possible solutions would be appreciated. Thanks Dale Ran winecfg and got the following: getting server_pid from lock 2457 wine: cannot get pid from lock (lock isn't locked) err:process:start_wineboot failed to start wineboot, err 1359 p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory getting server_pid from lock 2457 wine: cannot get pid from lock (lock isn't locked) err:winecfg:WinMain failed to restart 64-bit L"C:\windows\system32\winecfg.exe", err 1359 getting server_pid from lock 2457 wine: cannot get pid from lock (lock isn't locked)

    Read the article

  • Error compiling Win32 API GUI code with MinGW

    - by Eric Larsen
    Hey guys, this is my first post. I'm just getting started with win32 API programming in C++ and I'm having trouble compiling the winnie tutorial (http://www.relisoft.com/win32/winnie.html) with MinGW. My input and output: C:\Users\Eric\Projects g++ winnie.cpp -o winnie.exe /mingw/lib/libmingw32.a(main.o):main.c:(.text+0xd2): undefined reference to 'WinMain@16' collect2: ld returned 1 exit status Any help would be very much appreciated.

    Read the article

  • using LARGE_INTEGER gives me back error error C2679: '=' binary no operator found which takes a right-hand operand

    - by rekotc
    i have the following code: QueryPerformanceCounter(&timeStart); winMain::render(); //do stuff QueryPerformanceCounter(&timeEnd); numCounts = ( timeEnd.QuadPart - timeStart.QuadPart); All the 3 variables are declared as LARGE_INTEGER, the code should work since im following a book example, but i get: error C2679: '=' binary no operator found which takes a right-hand operand of type LONGLONG it might be '_LARGE_INTEGER &_LARGE_INTEGER::operator =(const _LARGE_INTEGER &)' 1 durante la ricerca di corrispondenza con l'elenco di argomenti '(LARGE_INTEGER, LONGLONG)'

    Read the article

1 2 3  | Next Page >